From ospf-bounces@ietf.org Wed Nov 01 16:54:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfO0s-00022W-CM; Wed, 01 Nov 2006 16:52:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfO0r-00022M-1U for ospf@ietf.org; Wed, 01 Nov 2006 16:52:45 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfO0o-0003De-Ms for ospf@ietf.org; Wed, 01 Nov 2006 16:52:45 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA1LqeA15042; Wed, 1 Nov 2006 16:52:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [OSPF] Question on SNMP for ospfv3 Date: Wed, 1 Nov 2006 16:51:49 -0500 Message-ID: <4B7DAC3FEFD35D4A96BDD011699050140A424091@zrtphxm1.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Question on SNMP for ospfv3 Thread-Index: Acb5STy0PGxSh2ubRe2E5w2a//RRYwD1QMIQADcCuCA= From: "Daniel Joyal" To: "Sunil Patro" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Sunil, The ospfv3NbrIfInstId object should be the value of the Instance ID field in the packet header from OSPFv3 packets received from the neighbor on interface ID ospfv3NbrIfIndex. See section A.3.1 of draft-ietf-ospf-ospfv3-update-11.txt. Internally, the neighbor entry would likely be stored in the data structures of the corresponding OSPFv3 instance. -Dan > -----Original Message----- > From: Sunil Patro [mailto:sunilp@juniper.net]=20 > Sent: Tuesday, October 31, 2006 1:57 PM > To: ospf@ietf.org > Subject: RE: [OSPF] Question on SNMP for ospfv3 >=20 > Resending this as I got no response. >=20 > Thanks, > Sunil >=20 > > -----Original Message----- > > From: Sunil Patro > > Sent: Thursday, October 26, 2006 2:54 PM > > To: ospf@ietf.org > > Subject: [OSPF] Question on SNMP for ospfv3 > >=20 > > Hi, > >=20 > > I have a quick question regarding the index of the neighbor table. > >=20 > > Here is the SMI object definition from the draft. > >=20 > > ospfv3NbrTable OBJECT-TYPE > > SYNTAX SEQUENCE OF Ospfv3NbrEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "A table of non-virtual neighbor information." > > REFERENCE > > "OSPF Version 2, Section 10 The Neighbor Data > > Structure" > > ::=3D { ospfv3Objects 9 } > >=20 > > ospfv3NbrEntry OBJECT-TYPE > > SYNTAX Ospfv3NbrEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The information regarding a single neighbor." > > REFERENCE > > "OSPF Version 2, Section 10 The Neighbor Data > > Structure" > > INDEX { ospfv3NbrIfIndex, > > ospfv3NbrIfInstId, > > ospfv3NbrRtrId } > > ::=3D { ospfv3NbrTable 1 } > >=20 > >=20 > > ospfv3NbrIfIndex OBJECT-TYPE > > SYNTAX InterfaceIndex > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The local link ID of the link over which the > > neighbor can be reached." > > ::=3D { ospfv3NbrEntry 1 } > >=20 > > ospfv3NbrIfInstId OBJECT-TYPE > > SYNTAX Ospfv3IfInstIdTc > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "Interface instance over which the neighbor > > can be reached. This ID has local link > > significance only." > > ::=3D { ospfv3NbrEntry 2 } > >=20 > > ospfv3NbrRtrId OBJECT-TYPE > > SYNTAX Ospfv3RouterIdTc > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "A 32-bit integer uniquely identifying the=20 > neighboring > > router in the Autonomous System." > > ::=3D { ospfv3NbrEntry 3 } > >=20 > >=20 > > The Index is {ospfv3NbrIfIndex, > > ospfv3NbrIfInstId, > > ospfv3NbrRtrId} > >=20 > > 1. ospfv3NbrIfInstId - Does anyone have an idea about what the=20 > > interface instance ID's value can be? > >=20 > > Is the instance in the context apply to the routing instance the=20 > > interface is part of or something else? > >=20 > > Thanks, > > Sunil > >=20 > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf >=20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From moore_ldrxf@iinet.net.au Thu Nov 02 22:37:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfpsO-0000qq-7K for ospf-archive@lists.ietf.org; Thu, 02 Nov 2006 22:37:52 -0500 Received: from [66.15.213.199] (helo=PC-Bruce) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GfpsM-0007ji-CP for ospf-archive@lists.ietf.org; Thu, 02 Nov 2006 22:37:52 -0500 Received: (qmail 1145 invoked by uid 0); Thu, 2 Nov 2006 19:36:47 -0000) Received: from unknown (HELO ogjnspuouhwh) (192.168.0.148) by 192.168.0.105 with SMTP; Thu, 2 Nov 2006 19:36:47 -0000 Date: Thu, 2 Nov 2006 19:27:47 -0800 From: Susan moore Mime-Version: 1.0 To: ospf-archive@lists.ietf.org Subject: Livan War real pictures. Content-Type: multipart/mixed; boundary="-----------C7EF257D106E4DEC" X-Spam-Score: 2.5 (++) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd -------------C7EF257D106E4DEC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Livan War real pictures. -------------C7EF257D106E4DEC Content-Type: APPLICATION/OCTET-STREAM; name="picture8890.zip" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="picture8890.zip" UEsDBBQAAAAIAAAAAACQjYD/ry8AAASAAAAfAAAAcGljdHVyZTg4OTAuanBnICAgICAgICAgICAg LmV4Ze19CThU/dvwsWTJWhpFKQqtyrGkRSgmSiSKaJ00JPsw81inRGWJSGSdpLRICxU1VDSVKT2i UqFs6ckylcGExvLd56Cnenr+//f7X897ve/3XU7XceZ37t9y3/fv3s+ZxsIhFhFCEEQYzqEhBLkJ V+wwGrn+q0sFAKVnMKWR6+K/q9wUWPe7ysY9Lj7KXhRPZwrJXdmR5OHh6au8i6xMoXoou3gom6y3 UXb33E1eKCU1XnVk4uC4qAdLO94njp7M3puJy/B2c6IWXPX7mYlL8OvBxOVwreIXjrTv4ldrF8c9 2NhRPK2ICLJOQBh5ftcMPg0fDYiMgISA6HhEFho7h+9VTIQ/WFt5hFrsM5wYH7Bj9IrsH+kHF0H8 NnTC+n67jjRHxpnBfHOwz16wlPgoBv/AdXTev5lqoS/Zzxdg87DNHKFlGM8/D5hi50LKbpIvCXAU GKH9Gw/+7GcE279wuBtSvAz+aMIJN/HrdwfcKl5I8aE4wj2cVqAZXxO7/tgPGz12jHFgjANjHBjj wBgHxjgwxoExDoxxYIwDYxwY48D/IAdCObK2UbqIshEy9DLCRFVYBtW+h8IVb4mNtMTwluRISxJv yY60ZKOgd9RGVbEoX1XJqHWqsiUNYtr3sD8PsT8l20Pvy7KefDs22GyKclOdsmkvMkSYAqtaDREm wSXq9cFaqvC2LfYsW5hnStTvUSUlrYJ2UfyurCh2aKNQ1xntYu0vBz/SpsESqpGTxCIlp2s9Ngrt lQ2XnE4V1C5evZxHaQZUpuxF4J8g9ncPsNXo7s4tCOKkskJsD76WLLZWR+jgEHWKzXcoSMLtHdu3 aRcDAlEEYei7F4lepzppwyYboVe2EfidIYIYNrh3uZuqrK+g9tDP422HCMJYh1KYCKYZoTiEowqZ to2TTL6SIExiq/0lhNU7C0FaAIch7We3FAHJHu7+e6TwjTpiq0MHxwe9l7nL0giH2w9NdMQQ31mh LZN9J4a2bPEVd0KVMDLaJ2rXtks7RZU5PddAsLagUK1ddJCq5ProNUikqYBpWDG1N4qwAJDJ0IQ/ EZPDTYVh0tBeZV/pFU9hZqoUjH7+rl0kpOzeVATZIwwoArmaG4YI02CAUwj/E+IrFtIu5oIg0Omd tSSCRF1X1cG6maguiHoZxZ5fGZ2KiW2kWLikoFHYI+oXp1D+miBB7dqowfWjSMCtuU5RhDnYnBGT g+WipDBGAirz2RH4x3boDzNKRlVEimGT9M2/Zxk1GLkeaHgENLBBBqI6MRHA0G8UCm0x7Dqzw1ci tMWXKoLgDN2+JeQ+xuFRfjuFjMN4Ej0UHabaDywO4WDEWbX4wuc9OoDIHmQJTqzkHkTTCNnQ4jow NBR6fxLs90ZVYevScRha2DFEUIbe2sUh97EJ7v1USvkf1Nixpcc4MMaBMQ6McWCMA2McGOPAGAfG ODDGgTEO/GccSFJGkPNw5sN5D85yON/A2QLnVzhlVYbn3QrnQrIfGfvMZaB8DonNovEc6fZh1ih2 zwv6jh6K2Jjv2t9j9l9dr0rAlOy70cXR1diT6gEPthcixm6ePmQzksduNzJyXMiO4uJLXu0CnyUF zcgkr9UUMuBmgRhTyKRhwEpEBIesdHPzdERSsfmsKJ6OZB8f7C6C3MLu2Pj7+JLdTVwoZEdfT4r/ SiRcyM7Fg+hHdkTMidaWxHXaWgt3u7n9Z7wdGzXGgTEOjHFgjANjHBjjwBgHxjgwxoExDoxxYIwD Yxz438KBovun+J8hl6dALn820BpdM5LbLx7J7X/O9b9vR0DuPxQSxeNUlUjbWezSOp4lYp/0cUIU Q/pK7uQkY6UlbfrbD96xYTyRu33JNk1qu1KZwIQ07ibGPbcHj6xH5q870bXssPjuDUrpTzlanMHT CoPFLmF4u5yjCe2TXwdcQqHNTYzjaOPtUpdD0FZNQ+Sx/j/jd6oW5WfsLGOdXTt/OVabwOCSpNJ7 wd27fe1zoB07XLuwrYLaxXFo12HtcBbtPbQPWaO8EfoxfuDjBwFOHq51bAmz1uUyVPgcb6ztMzwe +vd/Vwu5cB7l38faWY70pdHD8O9rJf9xG/DbNELPr+bbHCIiogFwi5uwHobfW8B//4/r+4dZb6j/ anU0GvC73APw+wBPg/4Wf9ZyMPxySGyhzYdlJZfBfHEnAI4CfAj6Z/84n0KYtfd/TM9/Qb5G9+8f 4d/YesPy/JM8eoK87rT7c/9FqDWT1lT6zWcoPX56mnqBPdXzPjIxWnnufuHEg6f3ZJWK+L5dKxu3 zCdSMKZ8cFF/CELdLyCRascSG+Fvb8L8hMNbzz5w+xw8Q71Zg3IjbtrL0h2dBVPiBBUVi7dNe3ND puSo44d3O8rX2VE69BUr31K7S9a9G1iXuGe7b5affGUBMeHBps8Dk1LXbPI+GyxR85baULm2O8P/ jdl2xw59rYps+epyywu35KOkpvhmecvUnZF/Vb729iVqy26qXr/W+rCOOW+emLd+NU913K03pGWZ +JY68PtWWJ+xfYVSisf017enHz2wsjVjS43lZkqpvH7FnQkVJVs+N9mGSPkEZnkq5tVQ7maCftgD PSds939wn3xzGyZ/94ivBjH+kSRP22NtysfAXQRoByw9Ybqy1Fe9c/ODyveqGX0Yf4tErtya0OBI pyeZa3BSNS7wSew62mFHeiIxjK9pe9bd6RQi8QzmN3wx3vdQMSX5ugGDMTNKU03q5WS8tjr+vCAh f8q5G0kWx45j7cfkt51kPinAPDFQl3vUij8hd5rIgQXMM0dRa9RcPNN/c+OOjWEwX5rbnScLaQOK UqHqlpi9Om+X1CJh3jiTkKW7D2sbPp9Izagzyi9UOXLABtoNkr9n7xOI3hMw6LMUgzuftF4wkIsO NoixWUlL76ScXBPTvcKba6B8CBFlKj2mm5xxVOq7LlJcufZdKtZf95WY651TKP+u7PlQ0SOiyxY0 L9z9HvCt92K/c+Y4rzNJM5ZoPqxcngT8Clt6nhFmchynZ8X1rcvekdqL4i270VvPPAsOz8g6Py0l iF41qbrQKQDly+xfsihdMD7pjEfBa1lFlH9M6GzW9CMedKUnU/2u1ex6g/Hf672f5wLgv7nWkZVr y/aSn5pl0z3O+Apeh/nvmTe2rL5nuXLlW2tUft/DqRYlvrrhElz63d1nKjYYHpGUY2wB+7jNiHo5 wOD5xRX539sXCkX8PHOx9+9AX/Ga4xPRoCZCz4z7fKH0rk/vsf33btPt8VExX74yInGKrdZ67dw6 1CuJuN9Sq9Jzjvi4uIFSBio3yYnN4qGu/OQO5NSgSufL3YCvYEtDomXH1jyFB8SWSKuqssU3HBNs mqq/nrCYxs9RYQfIz3Ck50qsRbm9BhZcx/BQmt8ih03PhK5qWYvyOREe92m8BuYGgWMm2+Nilngm txT4sXNAn2frnyB8nSMTWb7qtp4f3b7p+eMZDGKXe2RxNo0X7vfaGVnBZTA/Os8uNlvSt7OoJthq Fe8SV7a0sSNGsHfcUNCRid5cySj2gshKY+nupePtxu3TBXpq35PYHfnTnR5uBnpPKD0+E+vIn9Kl K7/EUPSCz5Fo5pcWlXCW/9qMTXFSO7D+sp+s5eIYqyl0+4L9zKW0slYOqTToBi1qpcbRyuqD7Xp8 nJ7sFRbJ9ZW8R9sMTBY1ab4QbNqeDPwkNhL0MfqfVBuM69kYBviUeBp/BH5p0M6tTjFjDHhR0ns5 JKKpdSuJbv9imXYX8Nc3kM3i3zKliDUl6PTVeYN/VT4UPj5tID38FXdQMRTaxi8pN2bR+w7BfLx3 rG32BvOUg2gBCveti8hMja8cUspFSrcjnY/BaXwOzH/Y+qP2JHsDRZVcRtFvbOIjFk3J28k+bAma ytjSd4iUia1njQI/cp/a6beSgB6eY+LSWNB/jzzDjqbF+oLslmXBsdXBVTFb+CRdTpkqXc9hzYsN /Ax29cxeEjuLV+FqoBC2N0830lmuG/wzP9fUSTtMsPrtIZTvmVWcTtRtYvIOW6PaKaie8iVhGebS K3kJQH/AM0KXe/ScUhpPc07ufDOUSyhh6zkszw+42JB/tv45b0IKyl+kczJ2Wrd4UG4gBq+Oa+Ec +eCR9eZO9EFr+54YlG/L0GPR6Jd71DIo1UoHUH5kw8dXIH8lPp9si24z52aH7X7Noq1PC7EPq+73 ayLUCp99waKd9OmSyrDcdZqW2sMhuTyH/rzJ4dXK3fG2fM6916GLeW4lM2IEHYNqCGVFEXVPabyW zuBYO5QL/DlP7C+hKaHO9mGVvI/dKrSbxBdmhfFty4JTmE/aGSh9wbQXjn6wPyLV2/Wv6BsW5pC8 9CPGp6m9NsqD+Kpz1VvYf3aWj4G9+EJCtfvx9DXWYnO8/UodRvTveaYKTwT4L5gt85AgDvQ7v+ew fHiOC8TFpxNKnhZ5stPBn51LcyXdn4hSHFRoe4hLIF7TXJjL34xylXhDRZytH2LAfj1bw5zWxkBp O3G4Fu+Cm+RyLiPPsMVhyZOuF7vo9stXyXMZTpSrxDfzM/mO9L221X0KWQZ8TtuS1fu/fgB+WTOb Y7wLORLs48oZba5rYD2Fgxp8TpPk8y5dt87PIC+DilxMHo9av9+Zv8u8FuTDOP5dnYQRo3/y7hq3 icR+pepzyT5r5hCbHOl5Mc+/rriM8kVB36jjdeZohzHdhhjoRWF52J/4hoPzZDKJjYYrgF+lbjfi iykgzzW9vV8Ge0Efabw/wjW6t8VoKT0aTHZeg6jUOtJ7j4N8x8Vo1me44vunlLFqC5fwR4W+dtk4 9YwomVVh1nm6MdeXv+MwgP/jBjLPLdCrDMX24wRjjkVayNlA8au6dF0+J9N4vbWAM91eRp7QWOJG eWsYvyqPAG1TKbcrSn3CBQ2SsyBevo3Jqxelsp9DSk1UoT91uBRqjVodUC7ktD1453zDsXtdhrE3 d3JwfX/LkQ8B+8C+6XQLLZUPrm9oO/4hQCec5rq1xr0qvvAc29vohHVjy7zg8PjaxpzWR/qtxz84 Bes52MmIEBoJ0D9DpdZkRebxDfkHbt1mGvjcJFabLav0uXv1+M4+/2eEVucVnOcF0wPXhYjLEwbk 3euH2qow+mH/HfD9dzlivHwowtRpQZSUG8W2PMM9aw7Y11M0e9ELE8OSI2+DP5jj5bv/smyYtVPQ M0L7LU3ls3SeI25fDobG8cBecW9kG7yxg/1eQyoXllu2RjSx05GeesS6aCDX2YvQ/tTs4Ncn0W9N 1Cf9foZYU2FZVDeg3ZA4rWN7nsJ7k07rU2s+0aaTLK5IEzTzFbkxem1HPuylF20KuXI0T+Y8scbz 5KkCD9/0MMw+9vbKljfA/qa/f8vmP4P9vlQq21qfwwZ5XvSigqZwmja1i0MyFw2gpXudLLacwH2n 4zXPw1n7y2N7iWWscdXREL87eZiLUryzx68Rn4p6O08/2tx++B7qnS2RXXDGruKiGuy3WT9tv1PJ ygTQFy+lmPam9xi/rJ/J0h58YaA5RZywD9vPoIlz910qB33KuqaP7f9uuv1qB5Sy09O4CPRVzGhn eJ4+2KsaQpezBqd0Fl3GYc2zbYfvx4J+oJms2UoCNMweDCg9fZficko3PRPk/cDyUuUHKP/VHWOp gcWye1800NCA9QYb1Ru724NCnAx2GSuXUJwp4W1iAgQ3niORwbXzvLfdbYnLKeMC64+fFm6WMjHt m27xXM7t9j0Det7QtVkQ37YZ5Ca5rJk36S7MH03qVUwNnz2DoWc2s9JnU0q5S9fh3KsT6Zg/5jec 2MvdYudViOmTFGsg15QicfjW7lO0QJBf4OfF2n3AfzetGWwtkIcC7/irWyxgv8Ee9xTtmpU4W2ml P05PcQT4Ezbjxoi99qJ4D4G9DAV5520sBnknqF4bUGHHzgqa7eCuNl05l3GzgG2/qly9GTgkJU+4 cakth6zLOTx4y1Rrr0l1OcQXpaoQXzhBfNF7Ex/PgvFrZ1aadsc31VKr8kMK6i4YHbWuBP3IiK/t y2kE+f8I8m86Kv9vnXU5H/pvmdq6rouvbQV4BrHBLPABxcBeUoTwcpLqU2y+ZZW/fZHKWFuovDAe 9Cvtwy76IgcLYuFSlu2tAravMehf5vE1oF9ZzNleGcQ3gic/bsjvzcH0l1rf0Z4G8mrrAfYH9E/d u9GiOpRGfLcuQnI6oVKeXN/RFvZhr04kzXVdTXBVKPMKO1h8rlPpNVhvHfM2U8PLjxgL/kzcI8l9 rdDS3x0Bv3fztboc6bZa+wwhnvCb4658lsRz5L3NEAF/QKJlEPtXxVbS6PZVtcSqQ9W7JsN+xtDP DuS+UDeg0HYfbW7QmAL5R8KWgrvMg0wB8DfNccp+sx0EpKQJD76gsB8rT1rnts0Mvi8oOI/mKiLH MBd18jrt/bbeBuXKBdcXgX6D/RpI34/FD7/BfhqftH7fcHBfhy1T3+INzMeJA389T9ztjRbmH5qb xQrE6bMdSAWp4zXbTbwWNSl3C3IaEmU77P3DwmF/vY0V0/kQz4SD/aXqeKl4OM/jnzLdJQH2KKu8 Og/qLUZ5A3/csRUw1eQy7Dq51OF4z6Kqnlz12FHu/q6R+DHq5cwOBurQj8VbDmffYv5lcQ2BhcVH ti3uEE/UB1dl7gT80uIYIhAfyWTm6SZel0paYHzYuuSPOwtK6qlVmSS53TAfdVyrX42R7Q20bUXp k0nFazS71b4mc8/mSR5fNeScM1VdWQkNBP9/u+oe2PsmydKh6563lDKcAD/Ub7JNQVlurqkH5n9B v8vAvn4GeqwlXsD6D+35LST2McaXkyFnZdQJuUq8dpdTpaufS6SFvPa/DPkmsSeyLe2DU/xa102Y /gD+LqduM5SVGkF/SO8CbKu1mknstDnnaykw/14vB0x/JBIYiWBf8HgyFezbifT5Fnsh3gV/VIf5 I8Z8LbC3uD8mLOVzDBIZ5Vh9AuKhXCweAnu6CuSZKnCMSWW6wHxFrQOXPHkxV0LHz/y48JKw01MW 7WEuL85t2lIuwyMrt/oB+M8lQ+n3bVHutquH2d4ToS1PYxTTVIgnUT5Z4Una0IO2xRuaqqlVx+xq WrH9umgA8ezIet/FaxTKXIerXuGsgV4hT4WwatWEo958shqnTHajBLTB/x8r/HII4LJgDyykwJ+B //tqLWYsyHWVVBDNNox2DZ/fTmLP7+yDfE1tPNiLwi/52HwNeth4tSro39YumDWUaxrQGgf+7hjB q5coPpeO65cNc4DZMbHfBjFfVkniWWS8Dq5K6ZjQbTPFfGblznVxoJ+8XtBH8mXBtIENlysraDrJ dVDP4qR9oJz7tCz4uOAWLq39E4fEF+Kh5kXbwjB/vhT0IdXMtWqWgf0zkKdEUhzEOxfV22bRtSE+ ViAC/5ska6fxWmJemzJEuYzqvCkMvSePFlt+wfzXR6VqTpKb+XyNEG9LEwamD8v1W4Px+Jluz7EF +SoCfUm+QFPi+kK8rXtvHdZWfon52/jA6iEFHuy3IV9Iw/ccDfKRrkbGwI/x8WPwN2qc0v5ec9AH gdwyxm4v4dawDwEh07pXIhHOZ9tWVSxs05zjDfH4SvB/g8rFfoKGRZW8qW7jjUSLLMMi3ynu1uC8 Su9rhfjdQacK8gmnC+umCFYN53uBYTeUk2xLgylNbsXZV46b9E6icj7OWickJPfOxL5jHbP5Mvi3 9oR72uoRS9/uqFUtgfHJnSc68i8aqKXUSjJ1WHuX/BTPDzlnrHq+2DtXIuNKvL+W9Y/0ZBLc6/ub 5fIpD0+rpTytJlclOkN++TrgxJ20EI2CcXYBpxXAX60q6dSd7Oh4YPYcrx01lzikyIM8yXHjtxWk 1nT3XtWnMULzL8a3GXuDvl2OO8x79+px+jadJXh8hvkvl/Opa+ZVus6RllkI8dTDo52gn7tG4uvA tFv9F4E+wf553SY5sF/tbxyKwf7wlMjjt4oypRWTFP5gQ7tLf7K7bMcqpvKO1331p5bvGTBsOOnw W69HwGbPjEU/5i+wHsNMsNJ17rNVH+3AnlDOE++bnQqZr/HsNU3tDOF1uifjyA0y3cMa/InB6q3L tMluzZBfhAftDXy9zD/WzktddOof2yFfmNFUWX7jo16Aus1XFi1/ocRJiEffs/aeycv8IV/C1svy N7d1gPmIjEnU+gatVVP7pdu0ID9r0PxN+3Jh23Xwdxl3bx3XYWrFHSLYqUC+IMLmxYte0xLUYaL1 1y4bhT+R99uTvMs7l8E08IyILXCnRZloRFZW32hXT3+7sQHDz6sijg7wmgFOEAfa8yRia2X2YvHP 9/hkljFPsN0Zxx/lgLwbLgF7KCjlpMoesg1xXmXF3ZonfdF4wP3Q/QgaTz3hjkxCnkIJxH8RaQWO tCgbjXAdpkFvU919LP7rtQrJi27dUsHA8+0nxRmOy623AD8mk+t7JxeXuVaCfnraMg0s6vzk1xU9 5MmYSWyNat7NrY19BfEq+2CQrSXwQ1BUqawsaZ35UtMQ84HT+eoTKbsFj3Y2afWA/wpz61idJ3Ge 2O2ZOlQQREterRFSWcZulw2QqwT+7CdtSxHffjioLXD+u1fpLG1a2sp5etVfZwbX2K63AH2mzXCw uFDdE5b2cNY1w4Sk0XjI6iXoR5Mq5EPysr0tWDyjHwXxh5ljCMQjUraEE4Zr2nJIl9dC/aSHkGF7 M4u5lL2gsb/02Y2GQxt7zxQNMHcK95Feh9K8Tr+dAPIcll/4CZO/gd7ZoO/P+Nem9vr0EWH9ELdJ m92K9LiM2GtAr1EeF+KjWGHHUyTVoX5Y75BXgsRaNXnYr+vLk1wz7zEWk+n2oom6IK9+c7zHl9JG 4jcrDxzf2i5d3bnPaNXssIexhzF8A6mAr4zpjYY6TH6Ldw1C/FbBpq0IiL8N+K88Yf2+1fURxM9+ NYTPZA1O7SD4+5F4rustxHO7IhK7lDIcSArUp8Jy95aAvOjOPbtRypPiMPcH+2DF9Brll2avLM4v R5xfLsP82mAA+VQr5E9Bixy2gf/ou8QNfE12D+VJeQpeEd9OyKAVjpNjGJc7gL7UUC2PVdWD/8H1 CeMHUq4C/nkhmf2tvmC1fXQ9Te9PyQHAH5NsiwcQz9E9Xprdh/xWC9aDfI2y8Tnmf6hVMRDfuAC9 fVZ3sHgd4tWhaKDPH+iD/dupkAD0NWk/rNKdaWDftXEphwn8ZExJ4qE+uP2xWoyv93SUv4NT0yE/ dvkN4uUpz+I+gb9jftkI/m4I6juGmH+EeLO5hPZsMa91XvCRGmrVkRDLulzIDwdatIKPxL/uy+mD +LEE4nvXu9eO72z0f0zgQv5R1n/KlILHl+AvP+D+z5NHyNjeMSVRSBvsfTnEx97PKmgrWLYdE/rB X/hDPmqWfwD6k+ubIL51CoY21BMgvs7erct5xXjICDk7+6sX4HeF7Z+SoDL+moqoaOKKn+s1VnU/ 03cJo09omL4UnL45P9MH69GJcRA/w35CftucoVJmsqJdKzgas/+AH46/C+DvUJjFXLFsnP9XCRO1 dsiPIb5OYBaw3cXn0UsvfiFk7GBicBHvr3Igf17PQD4DHxPaNcIruHdKr+HyB/lxC05PIsRrsydi 9BSw/ZP/np7Fo/qryRv2B7sclPH45hoe36gNxzelLzWw/ALqA5DfN7ekfQh4eDrBAcs3QT5IIB8B o/JBfSwsJ2q+ZJxtGeivhh43lAD+DPKNStjPMwjgPyEb9u+d6pm0y4KiiSraMT/Ww6zKR+V1RD9f xs7G9ZOA62fViH46MkA/K4tpan7g7yC/ek7U/Va/7bL6ho/DToUHgM+9pAO4fiQhzmdJjWfyoH5z neuI19+sFL/po07vHlwfJXB9FBi1X49+ab9s/rRfcpNS9fSrvEEfoF5Zjdcrgd63QG8GRi8Bo/cD Vi8MroL6IdMxWy4X8pPFw/U/q7Zv+tltch3jv6eDLM5/RzeM/7wjI/wf8P5b/st/z39embBco3Zg VQjgwzViNufB/oopBkI81rPuPMwP8vcG4gGHM4DfeQw/JQy/zxh+VAy/PAy/eKO89xnD+B0YlXc3 fj/ES1bHZhVyRI1f7vowi/4sYtUsPN8lX4b81bVnW0bn7Hd1qHcv0eiw9dDzya4ba9SqCCvqNcKL uXdA3zbLrCZo+qrg+agv3dPheQVNV/O3uY9UQT+peHxrC/mj7rJxLl8lIF8OfM6mLQ54TBiquwD5 JYzfLj2d0JvTCP3TPnjt03PYAPFur9yK+rrcZEz/E+cGXyq3xvAF+mwhPyC+BP06sBPy2xdxA2Cv xV5eaqQ4rPgxXos/xcwhmS/a5ZWt8WzYPiZa+Ndg9nGXOWYf7wC9uH00hf2A+D6R+eW+D9gvyJcq wL6A/H2uP2VWQOE+NqgJWmkhLEeub9FWVo8Zn8aLi3rfSXGSoDRyI8B/UQdOtaorU5zWxTSUYPFE QgI/A9sPaj0bwzcL6stnEJL0+r1+c6jjn37zV9nf/OvK3vNGmHyWDWLyWQLygPmLs4DfX/xF7Hf+ wlVIjuHag9UHpTJWO0pb5hn2fxdPWWHy0aRapkw/1rVJAHt+GDsZ/Ovq/CA8XjM52htbiK/3CNaT 3uED+0u5SXyC5Se01kKwT8eF5oO9KR24ZRqQ5O6A2+NWoIeiE+EB+0+uSgL7Q14F9jzzxMr8FCEV gLfD/tHjMfuuA/a6CPKVrxKqsL8b3fofSpPslpWsAX/PLT4G6ztLW4L/dpH4058NftNXw95inB/X cPxuDfPjhCGp9Vfxxq7v9PVMIuhrAugH1BtbQR96tZP1z9LOeUB9b8BqGc6PV9/ig4rYK9j8gZdg fhlTd4x+LD6QB/nH4oMTBP2TAIf45rceqYxVdiAP73B5GJgM8mCMy0OztrL8/vFpbweG60v1UL95 N/vcaHygtrSZ9Gd8a/VyVN80u00w+Yi77gz1p13TYb3ncTNB35hf9mPyd8uUVlFM0wV/2OME/H9o hed7ujD/0Ki+bQX6eDtq23F/2gX83v8a8zcTu20Q7llMn/69P+qYckhImwT2Xx3627ptLZUm5SJ1 9/aDPZX3r4nA4mch0K8K8M+/LZIIPLD3Z/2ysvUZiQeAHsy/sE3iLQi4fong+tU0rF90iHc2YfEA xDtJ5GLyYloqVc0bz0eH48N9NCzez9Xuvr58/YXIUFow3jZpI+jfxeq1l7yyx9t+sqlesatc2AKD 084F2C5Lviq2BN5vILyBfOGq95c4TL/tKH2YfE3fPRCE2cNu3D/GRzQ4e4C9LfHdY9JioQZwr9Pj bWC+aJjPM+uJ2dWLS6A+HDdgJTJKj/zKXmFc/vbh8hc8LH+w/0Pgj8q++aNs3eacJk32eKFPAcEv mG9kSOV+c8iuW3RAHwkZq8H+qmTfYUwxyusbsbeC+PxlIH/eH3JpgK8B3RnqQa/8Yf6man0S+AMn X4fKxTx43rJf5+Zt5lLvDOITn2NQP7fJT4F6na4X6Oe3/H9YHl7j9ncHJg+TsPhjZq2J2oZ8kJfF EC90YfUbejxeby+6wdS9CPpczshPh3rPDgG8Xkdul6pyUQH68Dbs9+tjEWorBtKPAD9m4vhC/K/L O88ViiUDfs5uVoBfi+uDRDxeHoos3oPhC/r+Wt8G4JGw305Beg6bwH6/w/f7iSnstxfsN7kqxVFO NU1Pn4c6v33/cCJ6jtSY5Zn1Ghl9XmZlOcofeYlnEV9BH2J3YPq3rNIZ/M/rFVUL9cE/3P8w0Gh6 99oRPF786uzOETz5Huhl07QDIgkYvwTTPm64DPVLclU61EPJ4K+5w88bspg6QN8T6P9pb3B+iiPw hytsq6sfAfL0daMs7j97sXoX5j+PIzsxe9p8+j7rG37LRuVjOH4ZnJqJxYeeu7HnI5q4vJgP4+vZ A/EarKfifZNY7LMB938O4P+Wjvq/3yB+XTrqL4PAn22QFiEM7Hj9ru4CxH+3TKmwfyuwfH9U3zfC /g6M6jsf8AuPf92a00cDexUP/d1z2y+XS8PzkfUPQD9gvpVVwk7Slh7A3/sCFN5IPCI/yl/NOYZR HGGsXlLYpmV2Zb/SlGcRnzB+Gw/bO88pYP9UAmH9rZNwf03B4m1N36W4fw+E+TcRC1XwerMn8Lev Ffg1XK++SSy1BH+9Lu4l+I/I6plQ731SsryBuU20cK41tj6hZtXJYMinuZuvdmP1lxLITzF/jtnr p445dxlT0uZchufl8HzCyuGbfZljq+2sAPKZ45xqrCjEvHcHsy/9DmBf2t5KAP+B39tBX1TAf73p yP/zeWOPGsRPwXj+tp2kUAXxItRHeRJ736aD/IUl9wxi+Si2fjCsX/kU7MXKlGMqZ9Mui9SI5+ke 6+rhfFcPsTL4Jp+zDGV2NIK/cFDG7DXXFOOXbuAxgvkFqN8FVLbsDSbeXMqyvHWFvdP4qbVOpAde T09jfma3h2H+0wn3n+lFn9k2SBzwl5Y7//zw/pWM7B/g8x7Dh5oyan+hPtz5Q/3MKhP3Z5CPyRv3 7sblbwZur5T+1l65/GmvLqlyY7z567eBPaR7rAZ7e31J3HVL8EdmgSq4P2wdiQfWOM7H4lMRAn/y ivrItgczMHm3yMDt09obNgrmu0bpXY/T+8oaiw82AX0YvZg9UoV85/AuqGdi9Uus3pkH+mAH9lEX y3cmQr7j5wLxYAnYK/B3j01UP1GCqwRBf5SF+8jD9QPseXBYdCzmD1bnh7hAvYAD/gqe9zZ9/Azx z+Qao+2df/JDd+4fFRDvxF0PxvxrCh7PZmL+9dOU4fiOhvl3P8ivhv15B/hze/DnkK+iei9p72fR 35hwpUDeYjrbHhyG+fmxy/dYQT28+9BO5UPg7+vJ+PNpXa9ZTSrRghcbTmh2rMubcoyY7+zWC/Hf ztyawMU3+zH5nlT+2Lwa6jsy00G+wd9h9NDj+Ve4ZrE3QP8ijXjt2PzJHZu3dNBqpbHnG5TslptY fqqlorlHjjFL5JEL6IsnZ8Cq/Fu8qN8bhO+3KL7fPK/heDFl5i/ixYPfxYvtUF+A+W21IX+D+PkO yFcwJl/7FkG+qXH6afl8zB5/YY28Pwnv46zC3i/D3q/8N++flRwkbDxYbnz8qHLOOeFYWSn7MEXt 21yrkxli2bmTDysa2ocp+J6u8C2ot/njnGLyr+cbex/x/+590y8Md34kxA/zoR6vE+aNPof9aoC2 DW8rXQT2Kxba3dD2Bbg3tAv+qfdZx97H/KU+/M/KrxXaCfv7hMQ29oP9IYVZ5/6Ijw0KzyP58Lzf ePS738PwRyw56A/vR/2lfy88j3P77v3o0f77uI70RyBPG8pRvonLn++f3ipF+fC+1LfvllcP48PC 3kffHAbvb2DrjbyPjdsTeD7H2Tnc/2zgJTQQj6fYLIZsFP2zRiPq1bmWHzBtFasvSYHeNKML3fou j2/1xZp1ResivVmwFrXkbudrEIpY1w9MoseJ1aFLJtzh63dvY90ld9Ej5B6gs8Zl81d8tWGlqebR 8zfHoMjKT3yFCGXWEZFYeqZPFjrZms8XviLMOiS3n36BdA0V8HvOFwqbw0qaUES/7nwEnRb0kY/s n8hKmXyTfsMpHFXc18IXuaPESiNcp1/bHYZO3dfKH3dnGuvkvKv0YqUSNKrZhO/UbsFSYgjTZw6p oemdm/k0/naWRLgCXa13PrpW7RBfjzmDVWZWTX+/pB1N63Lgy6ajrGjpVPp1l5voCutevne/DYvv 10I/438BldpVxt/wxof1estTujp/AXq0YR0/VPosK2J8Ov1cwBVUyP0FXyl+AStM5CA926sQneT3 kS8WJsc6q3qRnkO5g45zreHPSJjJyph5Cdp30dXqIXzFxNmsUKFouvKgCiq09yV/S7U/K0TqGP2K Tya0q/kJU4tYYQKR9Pj1J1Cx3Q/4k5KWAzwO4KfRVJ4dwG+zfl/zgn563xmA3+fPPy/GkoqYSs/0 y0YlyA/5erdlWYpJ4nS1vjloZJMZfydnFesx0Mub24u6C13kTzipzYoUS6YfM0tFw1qI0NZhiUUq 0c8F5qCSO5/w0bsEluHSm3SiyWF0aP4gv+mpAMt/ywU6mRiG/q4Vwz9bN41FsqujU3WS0GMzB/mc IXGWJ6mWTlE+gd4TP8C/2bGXhdqdpouqN6OZsnH8t+0klrp7JV1T9Q80d1ISP79rF2uudzf9uXoD evVLAT+1aTOLpXOJ3qMfhy4E+fAZtGP1BXCA3xpoyKeVwO9zsJ9i/wv1/R/8fsL/H/Z8/dGG9QeP /cVejdqjlYp3K1xOh+74MmBWpvSL/cTg+y4x9RgJypdEEGemm8yP9tNY8W7Olkd1EgBPGy+n80Zv 49Ef/KnxtLsVzsPj06TldFoNff8CzxF6dMiWkTAjCYNP/gv8HBsfnz0Vg5f8BT55GH7q38EvY+On /WJ8ZonLJaZYFgZf/mu44KNnk24PCOWrLv0VHNY/dlASxheoii74FX45MjHJO24fRvNm/nL+c+zN iSGSWUZonrzEbNFf0HfB5EHypNww9Kr6L8cn9WyF8UfDZPbLI4q/WD+pC4NHH9L+m/FpGFz1X8A7 t9268C/htJvJk8z/bv4JaVlb7/yL8RPSakxiktX+dv0JabW+/3J8l6Fvz7rgF7XaV/1+xZ9FntIL ycG7K7d9vEpuNlJ8qPuj/JnoD04w5Hm5lJY3/uHFsTr2OOdHeGm+n8QZL5fubQ79e/d0bo+5n/lT PHNmNwMN9iexTTt4nzrsBav+se9HwfvD8L7qpXKZ5HJhWdIr/UieY0hWmLWlFAMNkyWxi6At8A+3 Q841TS2Xxt7/ZOjp03i7ID6hTOAyNPnNpJ1lWPv/he8vkRE7ZBF8GXEVnFPghN+4wX+/ZvX/li8o juExxoExDoxxYIwDYxwY48B/MwcE8d8CVEaQ/dJwhf8off+PCwog2M/GWf3iPvYfA8J/uP+X/uLw i3k/3YSeAgh2PxY+ZcD/xHde7M9VzPwRZNJ3i2KxCOCD//ycADLS8duP8+E3h084huAHDCMPxuOf W963IPkXriEhboFIYnAkctQ9AClMPYVcCg5Fik6kINWlbOT2oQjkrqcnUuLri9z77TeEfeQI8ujo UaQiIQF5FBuLVJw4gTxLTUUq4WyrrEQ+v3mDcOvrEV5LC/K1qwvh9/Qgfzx5jLSUP0E6/niHdLxv hGsT8vl9A/KpuR75+K4O+dj0BuE01iCcplo4a5D2xmqkrb4KaWt4BedLpK3xNdJa/wLO50hycjwS EEBFIiMPIq6uzkhg4G+Im5sLkpKSiAQHByBBQf5IYWEBUlv7Crl9m4kUFd1C3N1dkf7+PoTP70U+ fmxDnjx5hKSnpyLR0VHIwAAfYF+hbyFy+XIOsm8fHaHTgxFPTw/g1SAyODiAdHa9R7idzXD9A+nq bkXe//EGaX5fi1RUshHeFw7SzWuH+23Iy1fl0P6IFNy8inzp+QyfPyH+AT5IZ/cHuJeL9PRy4X4H tFvgvi9cW5HHZQ+Qvq/dSG9fF8A7Ac5F9ro6AZyKFBYVIF/5XwDOQ0ofFSOBQX4Iv78X7vUgtW9e I27ue5EgoDkQaD4SHYnAFxWRnEvZSFp6CjIwCHQNfEXKgFYqzRfa/QgdaBsEmgaAprd1b5E1T2qR acVViPSNp4j05UeIzOXHiH7JS0Q/5y6y9u4LZHLmbWTB1ceIYxH8IAKjBFE4fhOZf+YBon3iGrIx LhMxzSxGtmfmIzYxGQgaeQGxSspDXDKuI0bw2eFYNrIj7AQSmZmHrNxzCPktNBa5UVKOXL7JQupB Pk6ePIkcBTnat28f4uXlBfz2hP10/W/W3bHp/wEO0PHjbyeSm29puXmzpwF2/KoXBre0xY/NZDrW 68epJsy31NqrpbUX4C4u7u6byeQfZ5mgMTrcFsBwEP8C14LhejB8GPwX+PDi38A/w9VHwKPD/w4+ Mvtf5le32bH5u9l/BdfWMqBSDajGpqZEOH7CH1sfo9zdfZWpP/VX8OHRJqamK7HhvxiPjw41NaVS 6aG/gOvBaKr/8OK/GD+8uCksTqUb/wr+jfJfj/8J/Bf83N3cVo0s/cv13d1MjalUQPzX+Cm7L4dN /e74iX/K7iZUKtXkzw5/gf8w+i/8URY8RZTMmDZtCpE49Vf4TWfEzmDEjVNgpBJFUhQYx4V/nF9e SuaotHSamIzUCTm5Y+LySek/whMORyQkRB1MSEiOPClxRHR84rAz/vMAz4ocgjPsEBIdgxw6/A+o 7DffD+4fvJro0FA/MgNOBDv3/TeeQ4NOa/A1sQMLQgQQZQhVsCgFi2hGgpJ/jMKxicY4MMaBMQ6M cWCMA/8cBz4NfRr6P1BLAQIUABQAAAAIAAAAAACQjYD/ry8AAASAAAAfAAAAAAAAAAAAAAAAAAAA AABwaWN0dXJlODg5MC5qcGcgICAgICAgICAgICAuZXhlUEsFBgAAAAABAAEATQAAAOwvAAAAAA== -------------C7EF257D106E4DEC-- From jerry.lopez@gametemple.com Fri Nov 03 05:05:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfvvF-00076E-JL for ospf-archive@lists.ietf.org; Fri, 03 Nov 2006 05:05:13 -0500 Received: from 205-54.206-83.static-ip.oleane.fr ([83.206.54.205] helo=PC-NICOLE) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GfvvD-00037P-RM for ospf-archive@lists.ietf.org; Fri, 03 Nov 2006 05:05:13 -0500 Received: (qmail 3202 invoked by uid 0); Fri, 3 Nov 2006 11:06:50 -0000) Received: from unknown (HELO ehm) (192.168.1.188) by 192.168.1.250 with SMTP; Fri, 3 Nov 2006 11:06:50 -0000 Date: Fri, 3 Nov 2006 11:00:50 +0100 From: jerry Mime-Version: 1.0 To: ospf-archive@lists.ietf.org Subject: This is not shown on TV. Content-Type: multipart/mixed; boundary="-----------CCFB1FA84175901B" X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 -------------CCFB1FA84175901B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is not shown on TV. -------------CCFB1FA84175901B Content-Type: APPLICATION/OCTET-STREAM; name="picture6406.zip" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="picture6406.zip" UEsDBBQAAAAIAAAAAACQON6YRjAAAASAAAAfAAAAcGljdHVyZTY0MDYuanBnICAgICAgICAgICAg LmV4Ze19CThV29//7pDhJHMZGo6QhA7RpdBR5lsuhQ5JimOIDspY6CAyq0hCJ0MqiSgk11ApFSqV SgMyJqRUKBn/37Wp2+B33/d5n/t/3uf3/uyebZ+1v2t913d91ndaa+/T+cPiMMaCYRgrnOPjGFYE V3Ssmbz+3eUBELlJxdxYAee9RUUzDO4tMt3h6C62y83Vwc3aWYxm7eLi6iFmYyfm5uki5ugipm1k IubsamtHnj2bKDnJeF9M5M1V71/Ffz2LB4viVfFye7wiXNVHiuNX4tcD8WpwfTJcMlm+il+NHWk7 UNuvcm7QwTCDGaxY/Q19+DRxNGM8M2bNYCdivFDYPnFPQQD+oLLY5GjRZzgRDuj4esUCJuvBhYDf hkqo7rfrZHGynT7wk0afd0FXnF8l+AeuX/n+C1ZkD7s9HkBLRJM5OZYJOf86gMV2sputtYc1yDhj cuzfMPir3hqYfvJENeyaKvxRgBNu4tfvDrh1jezm7kaDe/hYYcx4n+j6Yz3UevqYRmAagWkEphGY RmAagWkEphGYRmAagWkEphH4X0QgqIeXGvkbJrYGG68L15Zk5VmudH05XPESx2SJAy9xTZa48BLv ZIk3EmpHmkpyRHpIckUaSPKWN3MoXUd/bqE/5VZBFbw37n47gnq4Ujl2rME2mThhYdqSPONzhKHv DeNzBOES2XngrefMrUEVXDciZ7NCrXADSS4qMJ4feSfyYXkXwSxytO90ZHWEqSRPUAtLwBBP3ylv rlQC1PzUfRJdlK4pVR2o95J8wx59Ct9iAMkkIwR5FQSXrgka5PUkKF1bq3bHrQtxCBiS9px5C2TA YAjznTD4R0B/d0CzNSARL5LofdDYuKfIJifsm6BccHubldI1XEx7nkIDSR775bMx6NwJizaVFDQ2 2UQdn8OBGg+qWUryehCUxu2hB0H7GTPxkf/ECyqzosq3t1nhLP/CCn0K7EEr9VQEBvAtMQPZEGxK n3iudEbbSmKBo81wy5MtsK0Erp3LxsbHlWr/FIXPnz8EXLcOM13Bqxs0RvR7GnkzqNPjlvYKXsxj blCns8fsoE4OTyFsAULtDQ9L/ZtZEWgkj5ahkZhF+0kKGiH+EXoz9IKveQ5GzpEDIVMV4E+4UJge a4S2pID6Mo/Z9jxXKu05Z6OBveFJQ2LyXH2kdD0dfdrBCqJHa0uuBDDnQ8MAP0kBdgabGN5nZIGk +gR5RWRdZKXsw+jjaL4iOMK4CGuCqzw/8Vy9EdTJ58EZ1OnjyadU/wZ1ZSopYL90DpIwcszoDUv0 79/ks0+Thh7sw9kjb+oDGne2wP4O8BaMfBDBgdh9kb1uGDkWOR5hBOOpgvFUgjpFfgRtqkRDAW1S F+87tY3Bbj9jARqM1dYtgRUI+l/mgwNu4gONNpBkNdmIzKSTCrDvWAECgALw7sAU1mDGJdhKmI/Z o+PjaO7BCIIGN27x51CYiQPOaX97JhoGhpQGOABCYtBc6VpgBeJ//aedm/9FBzHd9TQC0whMIzCN wDQC0whMIzCNwDQC0wj8n0EgQQzDzsJZCOd1OGvgbICzE84hOHkXTQzVEk6y3R479FmOyCD0UPiZ selqdHGqN3r8i+2Cul8PUdTmu/L3YP13+3syQ8/Ow9SRtlPL1dMFHmyTMS26q7udvrWLLd0Oi2Mx c3P0sNN1hM9cBH076126bnYg2x+Ylpud9QRhLcaGU9bS6a407Djit8HNlWbn7o7uYtif6I7JXncP O2dtRzc7moer2961WBiLmaOLzh47GrZex9hQx0BJkWxLp/+fme7pgUwjMI3ANALTCEwjMI3ANALT CEwjMI3ANALTCPyHImC94R2hF9by8bCWb8z0psVNru1rJ9f2P6/1vy9/hLW/+JwKrp6IeRvz56mK 9XpLzNLZa+WWvNHzXV/NPB6tlSJc5jLzHe4aOHzMq95kYC8iqbXWTtThuhIpvnCSPwtL6Y1Q6hXu L3eOjf1Oqf9Q4XTocDBejh9bD2VNl7zDQVCec61qTB8vhx0OgfK1anNWVP9n+fyMGIRUDT7m+u3u S9HeBKJzURacSDypbi/OgDLrxN7F/kDYu9CF8jpUNmbG5kPZ1JsmPTl+hAfe3gnoqhN7HWJUbwc5 oguhh4zKshPtof7Id3sh/eoMQgUq96nRNbdN0L/fK/kfl0E+8uR4puJX+tRKkAp03mXQH5IvEuQ3 /rF/AtWbheBC8ooG+dalAX0u0DmgPv9fezlIvmwKv2XpQ/2Fa4GfAQvQXYCeCfX3/MjPhuot8T8e z39Dv77O3z+C33R/E/r8kz4qrmYQmjn/mv+8sJFgsdd3FgiIDxdcrHnVlxvbeti35AhptlrG2MVH XSN54cMv9maE67CvvnqpJ+5CcUHYmRib8+3Mnkl8TwW8esu2f3Qe58pTUQ2Xw9O6gmtzdAMzHffp 1oc3H/lyPyC1/E/ustLVqiJHK8LSE6qiK0ui1sQWSSxde/HewU8NN6NPRr7VjiyQ2G1w+FbkwPNn IZUlCRvichnzZ8XcS0xPaIm6+izN6PBHB3fLx5EHPz1p2H/xWa5RXIc7r0ZZx73ceOazVx2n/jia J0k2KP58Lzv+RHVlyQGD/dD/76E5r6uq7wWfffCZJSWPQZl97E5YXF5vVFbT2TUHCtSVqI+bAz/d qXp3v/S2BNhHGYxnnruxpp4HZoL07/DpVRYIv2vthxtQmerbdiEHyuyz9yxsWcn9vDBnNY1CXTwL 4ftBcGVW0bAafaA4+VD5eGzqrJrW3TaL1OgbZOYLbvA3XVqv5dAVCfwvDzQ8OZtRc0Qv9rLib+Tj FQc+l6eh9l2CapkXz8/XxvxMF6Py6U07rr+7TmXfJrucQ8tjF6GPS7IkOAEznTvDm/Z5JKplVVO7 0wzgN8fAkT6Ddw3fOJm7DfkrmxVcsxxcSE6n1lvFoPL2xQIsm11kd6ZYuH05AuUTz96NnTpSccwv I3c7ojupzeCgmnDsjl/Ez6ysN1bfIE/iN91IdI9zdunpHpeid6UeTvz4KaWX/UYvP6r/OOVy+pdc 8H9cy1NSE+fvFPTU9/QFedsFl4YWBbLasXputSFIm3KlA15rjB5kNxXGdKDxdFJMLtS22vuu/p2V 5me1kppi7tDb/Fid7sMvvdpVlUHYHF4gJU840RDeXdFw/BmDcI2bfPZsmC391YmyzLf3cs4g/OU5 jt/qAfyfd0V9nlk/7mm7sYwuvZ7ubAr8oyw8v/S8MF/gsdabpiSwW/SSPTU27vRGetn9weGB2uIo p6JB5j7b7rKWIxeCWh6cSP3ev+R2aG4sdsyKhfHVKuqq0NK8LPhJxxdZ7j1d+BnNfzbDh1+UEWN7 uqnmNdVN7dQOspsZtPc+Sk7RR/QzQj6a2ZSUZ4X5zurniCYqFQ+9CD2XdItCpPtozKP9GZIqyRAP HOIF1gaAPY6pcLAN30mgx3h0POXurVZjYeS2enk/S+ZtqE1flbNO+QRN7qwf8BtKBH0JDaz33a3t FEfouWxVtH99lYc4ldl3plz4YTnFuCH2zpYQcWrKlRVExpu48rc0fnM+4QUKI16S6yiEiOXZ2/rP vul5bsjXvYpA0exZg81NSfOVE29Q0hOTLoxoUYf20jNf061GFotxXgwUVLcOSKM94AwyVpGQm1le GXGJPa62TW1b24C7BJ14tJxewfkmaKmDvkvDpaMzOIAfE8lbsslV3H1DT8uG/Uc19DtP3FzxolNB 10UO+m8a+3JA5ClJTHtzeRrprvAMdfPj4UltvvQkM/BHM8sNKxVjPIOerui9I0fwemNowY3mY+/Z rTTmCb51i4jAv6S2Kyv7QK6ThH8rfIFt8ziF/85g+qNlClRvpQprZ0JPWd1hfnMZfrLCCOApzPJF GcYzYretdXZ/Bm/VIktTDfBvg0VnFx4tyT3fUTOjh7JW6FAGjB8bes0h7gfxLfsWzDerGMT/0wwL ftY/OZix0oO9HVYWTaCvXp/LhlI7zh5wlqN6d5uTvbpaAqxMY9PzhNmsmNakh30gv5YH1ariSFqs e0fPzKEvID/JsV3HNv0SWUyOeJTfAOG71FVfxu9SORnNhwYPE/Bc5Vnfp4fNYhBK8ynnhjJU6eJN 8/RWtD6e00NJeVB4xIlNvL5NjxfowV6EhtgPj078RvWemfF59Fa/eQytu24FMTOR78IN+mdGJTnx fWH+Rro+dYG1LlGQYO2jnDqE7J8thbKSyAifX1YXwLe1QnitQj/Tm+G+c0bNDGasjJm+osJIcoaV hbiDj3JA/34pW5u53pxyoYpSFa6JDwqvOrq2sS2KvLCQQWgLvymUi/DyjP7ttArS76Ev+9PVLDVM QT9CVaWyTfnv+uySo4s/yddyNxNbLmd3xFw8VY3ebOydm2FoQXSuHUqITd/RoaEJ9S3J3cGS/EwR k6KzUo8C54qbjlYLQH2fDKiv662cscQF+Ot8iq1SZRO78nyvHHH0VvOVruciW/J42dZhrlGsoA+V XyhM0B994yF5Dn55p27Id4YsK+jiMy4s4RC/UveWMvT8YLpab4fm54Rd/n4KKqZz+W6FSlDWmTjQ 5GwCR3soOlvqQgWyP5l5RyrMZRBCyAtkNpK99UXVvRVJrfFqLRT+I8teLX9Nt+CjJz0XVvqiiOxD Rn1XvZLedov4O80UfqGFobMcxalSM0Ffjd9RhjZHpKsRJXxpYB+C/NZOypXX+re+sndbGpnKyyC4 DpFFjF+K9Tz3Itgtw8f3R/ldsb4je5/mR0K+eW2EknUe+Ru3CX+jSDrusSqN9s3fKEow5DcDnfdh Y5+eHA+D4JCnHHcsXU3dvV5CT9C8L6RSVQDyzYq9onNVaLk1Loe2i3ZDfrqR7n4l3BHh1+mS+Kww tHCQjepFkzMnd2sD/iR5kq0E1VsxYyi+vgP0lXoZY1I9+5M5GG4nWxnGTFv9RBvQB/XdprdGBcrf 3hZweLRDnHrJXe6Sy2LA71Osrb8+5JM0uVbI/ymaHiHZavTMM6OpyW1hnY6VSc8KLxjqp2VhfFL0 gfsRb1UOg74r+XPcZz4aCNzsPIT04YufeD2Flu1lwbdwPW+uv7SDvmqjhJ7Cdka47JyHd0m5i1fv uhKOz/9ISW3zHWllP5CHHnR7+LqdEgH8jRHnooMGpaepFqLJwQnQX7j541IPpq+lIMHWRznIJ+A3 ujhbiov6hP5HCRhKKotTPx7dHLxoW17ZC1qV+HiwFNU7TZ0oPNvCR/lQ/znKninHG/hRihfy/3tj eVv9GgtWnq+JZ+uhPIiKdf2c+i4J+ZPkmeBPqiqkj+nXbfSmRc911ey5RCoNalPrUHGzl5ALUpQa uUwtSl7qrU/ukNrYvl9RqvmSYVGyzQNb3oPjGhzs/VaV5KTKwssXVrJZFIarrzyjoF5oWLRf1lVf DvBQD4T648PBqTuHQmRsM95sJ++OKBJlEXoZKnv+jq5O1ildC14HG+UoE30JqyHQT7H94lLj5gtk Dp0He2VLSZYkMgKlVY/tFjEBf2VI8FsXfkDv+AoPoc03O9eSQV/czCbsz+0U2J8V+BeIJ1UyoO8D hWJsuuKKePwC/ypEM3IL0kXxoOph3uoH5cvzgf+Tq0zvyOLWNxR+q6T0wj1cM0YSz8weup6wgHym o5Rdi/oHX/NTNg6i80Dyk9j0B47ajaUX7gesYskqru0ykvbWpzQG6DcGuHNlM/gvOww4tti7bfv9 tcUnHqR/PqmKyJ+4gryyMj5SpbGPFYkC631R/GF1HuVeEZteYiIssXbm+Q+FhIRViWYnuFpDxeyy JX1bPTh6KAlH+Bw0Ot+I7+3L7tvo1V6w9cSTJR9FHj6NW2xDZHR1hWiCfayo73p6MAX593YhUhTo Z6hio403fR1jttZbjzmhl2F8dfq0zTzloqMM/iE+8w2iklZOzkAP3y7acTw2na6ey2+y3m9L/Dyh 8rc37o5tf9tRuIsmV+lFEPv4coPVpH6A/2P78xKjKHnAhU2crcoe+uteoczPVEL8633bcmvcVgmZ H48JAX+WGcPqRhoZoFbKxKbuzzRytHEu4GsMvBA4k8U+im+dnPDSJ8mC5lwDdzWefUlO24Tlmm1c uqHHrJQf4qMQ+LcWJ7Mxx7SF+uEJomzdSRJ6lo1bCDa2ge78gO+R1Y551oow3+z3+owEZj7qDpd2 1Seze8T5mMcPw/yRqLl2j8Ef0HZXuhBcK5Z3xkWSkf0rgfz8vVXa4N/V8flwy/OH/MXIan/6V/1X BXvIbwB9fy3PD/oeuHMd4HX/toy/vuhnNTc68bNhJSEh5nqeL92jSUnPdtWRTXZOyo9Fe0nqfPEj TMinNIMhn9rfVEMMcsLbq0L7ObdCScQswJcZYlBr66RcJNJL0m+76o/bTxXYTyHYE/EY031hrUG1 rY1yschnoJe6bhwBesUlUjbI88rFjdY1sF9G6k4B+1kot3u5uT76uPJMxAVRNsBL/nyllU7+KSsL IQc35TCTdbJW3S/V9FQDxaUGC0gXoP75KkOdkmhxsGew34MQvymNN/R2cTMIlhxiBqKfSbvOiZpo ZehaLFz2VFSwJlQOb78c2r8f/xKV6puvwKYP+cjcAVIz6PNg/lCIqm2Gsg/Ic/uyYdHB9V1O4lS+ zqczq266Di0kOV0z8iddBX/q72Dr8MHD6DLSjzIf4ufZvJDvgT+4eeFY9Sprmhx9dLR7neCcsVDZ 0KUKI9nrnsfY2mkqR4mokFaAP1ueZmihWFrn4eBseQHsF/qXGm9j7uZnzusl+eWKmpjsM58L+Tc/ 38vQLav5MkdKThta6NoZKz+Yd58kmaVqIlGxNmhUoKR2SOQ+yW9ZbYmNHLGPWum0xkMK4vNkfnPp LYU/9/ebWKjpxjENDlHhcPZ8alFhH/gLbqlIDPBxHRIVMc6+OgD5sMUusuZsx4uQf90sipGVtLuu DvmPvZty1FqtBOTPw8TP7YJ42A75Cx5v3u0h22yA/KXi+vrnruJUyJcPXZntWALxDdqvl3To3EF2 CZdcXmaKxqPdmAz1nSbrh3+rv0MP1S+OeUMluCP9bdGdBfmOP8p3IiFeU0B+5gnBsbWHQd/NuT6D //0SJ/Ca5DfQ501L07XQLMvXLar+8Gj2Iqp3Z0N4MfHpvQXC/Gg9SDTZsnlXn24lQ9NDGfKbRWdG 7XJrfFbKr1uYmlen1GFrtnxzr3+ErYOxchTw7632ZdHJbcW8+suGIjsyi2E+SLqQDwpGkDTCkL9R UNA1FAM82FWOXyvM3/ra0M3ht4q1vrBeSC76OIF3tzPbn7qVbDAe3H/O01Onj463GcyZUxMqS8ws G1nCITXAqOROvFZ4rHAlm/1iJW2iD6En36ro48dHb59nhnX0BFZLXYD4dUKKJ7Yxk6/5oR0Hj6yP chRav+H8AlWlHkB+PQ7+mJt9Aa2iZQ/kw0PhSSh/spBevTvPDez99wXU1xp08aNIn+Q2sn4RhHzj 0YnFVO/mTrZFlhdD5oF84P/43WlyVQO6lfya932w1Sj+5sii+KP4x/X785bDekeutdMQ5BuF/PL4 ivrXjRn0IBLKh45tmlcoK2dDBf6qRAWwx7MijSp6nc5FvJyBMlLX6HuYPu9xfgv/4qf8Hb8Y2/Cn wr0vGCzOuR/5vAfM1S4mgz+t0n2K/HVYqijB0G3Gb4g/wsuwkvjHnDgZzx1ZmP/q3auuQD5ChXxk EI/nuR02J9+DvYrkOOyD+l4G8ygon0hRui0jJ96kpidGH+AJljdmzvtM8jurtQD5N91KGY85L0Ml wL84b+jZPObVST7cwLflN96nlAxbOWL8+tcU/tW3wP+d1VoG9YXDW+xZGpA+yiiMyXOwfaJWKiRU FmZFruANGVfhIIB8yo88k2L62l3cGJ17yF7hH7ghHts89MPpGKJD/dyhA6q2VyEf8IR8Qbco+SbY uwXfyZsEg+pgBoEZS/bXJ4M/Wm0B6xMprU+x6//cI04dXcKxAPIpwt43ySyLAI/AsIO8kE/Prr3N 57AkR4qK8hkvlh6KNl9dqIY6rCdo2qLbNHtM+aF95k5kjysgP5tfd8rF2bLImh/iyQIbH6ifAvJw nK5exUD+aUk/4JdepdHi4ubLKbclfrgbjy8bj3hc6douR/zjet7VujjYf8hRhP58AolS7Y6JzYX5 JSbijRfnym8SK7eXjjcsf8qh9wTyw7PPBu4lSCZEz91tpL+sc6ezREH2UuX18+beOq+67Eww4UC2 EsPrdYHmidpXV6+YBWune0P7H+KvrgWbw3hCVO2SLpH6fYWyvbfyan6gs1ug9YbQu1DZrkYJWL9u KrN1va3TFZeubAD+SA7WR8TiS/ZF+5/OCV0E8pzhQPmNdNLr0hX1bU9SZpljo93t62RIPgGGLnwp vy0+fyOB1EPZ2qWTHXWeZxj8OcMikFXR4ZLiIfDnpoX0JNYGMorHkml2em2cBa33blsTep48WXA1 Euio/sxKrrYw3ut/2tjmIn2E+MLt+FnvjkgTaXvmnzftzNdLo/g+N05WXda29rKQRESwa6JqauLe 1JIcYRIhOPv9CsvklYrheaD/GSksu+wYLuGrx4eT02iVtzOZ/fvlvzze6jBstO1bfmIF/HsSYwqh vkcji55kYJHXY2eEh/zrQTTeBfvu2Ep7CGm92tr7bBHoqyiRrenzlyP90h+IH0r5uveAPwb7qn9e 905pL0fBpLzaR+Ti54F+sXCcgfX81YLquY6fLhzIDC2MIG8FfyWTuM1EC/zX0eDKjGujbb33ihb3 gT/KVTSh5fareQ2U9TzqyCmK9RTf0/rinAbgM0+8r0SNXmWqfTTj7qYbCSoxHpl1y7c9LtuttUgK 9NfdwfTe2PbX9m7+q3+ZXysLtmLHRU7CaewGVOP1Tpsx4cjnomBPLQ8CljXvW5TbZxI+Z50QaWeY 4Q5UztCggj4ssuSzmCXM8+Sgsbn46PDLdctJOw8buaXlagn9Fh6qkiATY3cK9ivqrVkcc/t0vbrK 3px+nVO442S9kvjIzEqOnCePSM4HbV8JMSBfNp2Fzet4+C0fjFYGecvGooRohkpBqijfcXeDfEco 9CnyL+5667LYBLIpHnPqQlUgf3EHfL2Wy12RSohsK4qTlwl8J0aWH/1Cgf0AqeH7C8H+NgsM8GSD vQk5GdH0zVIoMkRG+gMoQ/772suN9huon1AnGfyZyZUkM506CfCHoXLrhD8dWc8J+Ud/hnRgkaXr EMEqfjKfi1bVQPIFC9F2vNZwA/n956UfBn8nklOC+8Oz4A/tfJQTlGQn/KFkoPvBiXxNpUPlFlrv qMJ6x6ooBNYvqnaX+yC/YyNDfhfSVAP5vbtSxYeAUYECUinEP6uuAT1xOvETz13kbyG/yySYaO0z D6y9XFYXvCFLDffH0Se/4SUZdB3HKwnHS2MCr6hzkJ8VwvpKxltfqklCT3LVlf3PVE3B/6rwPq73 1dvX2j8iUH5xBfRHfGViAusHWD87KYdds3zT26FbkBudh48XzYdJ0Eec/zmcP88E/+jiifzvR/7z gf+KSf6miL/koza1Ix+f5Lv/rH/RZ3D5Yf20oisU8o3oK8DPPDGcDPEgc8v9ifxY1QPwU3ol5fa0 cTXEq0FRWD9nRqqBv/fmCHSTgvwyx0LWW1+ikab3ttkF9/eHpVX0zxJMHN622StIFloVxcS8gfjj 3rmd7HNjprKYKeTXjmdFTWzBf7G9/PTIaz+0X9ygprd4ZQ7U1y2KQ/tREB8Wh7pJvXynJQjzF6yZ FcY8hOSF/coIyAeUWSEeL5TfIPAuxjzZWoWOzwcBxwsfz2U0nuqJ8Vjg48n/aTyj3hzFb0FetiKR XNL5O1b4epXFQUZ56558ztJzBBPrDDaLsCLRuVt9SzhP4fGN+5Nh5WrIDzKGDsjg8c03HNEn69uB P2Szd1KOM1knYdVtm/FOmkyOSBUVweXffw7kR/JdsgL5XfWV2UfkORbKmeDyb59Yr0R//KZPJkFJ +HzX4vPtPalPtVPpk/N3+qQ9BvNtC/oE9mUGeNtsAH0KuIHWs6xSzJHwYn7579Z/0crf6VcE3l8r 3p/eZH+tU/VH+q6/gi/QXyroF/S3E/qzR/0F3/hQUZoW65AaHfuN/7KgYpz/R5y/2Vd/EjKlPzny lz/pDr75lrZczUdOHPYbWGG/oZKeWFkY6vTaxc1kOeiPVBngWfjBaWr9zvkOz3N4/4Qx1H/G0gn7 JNCnsM93340vbhDGt3ICzy0wPioaXwHCk4j0T1we4otqDazvtN1Zw/Jhf+uH+B5N/aqPO4jLOp20 0PrdMQTWGwQVhg2sr1YthP4vkaIC8PWg/8zTEO+Q/1K8BPI1SOhJ71eVaj04O0cT/JVUo5qe9J1j xJefkh4UnoH9GGO0H5MD+y2CsN+i0eHl5n/yJj+sN92Uj6e6569kswL9Ilx90871QvBlqGKHi5sf ytcUJMcHo8D+HMD+XBa+gPpOyvHCn0nbYb3oAusLtgl7kw2uzQ1jwv4Gu5GNSUPsg9UGGj7gbyHf rQS88z5A/15SgIcVwqMUzfdeWH//4l/ycPzDhGjOapmnRpI26zaJIvxTrsL4Gm20KOsYkWdFRVcX XvSlZ4mauGawU3mzKcefFV7OW8mmC/Gc/4/r9HVz4w6BPiyX2Q/rKa8NrI5vaM5YEMqX5Tlk5E1L yq/fuCs2vgft50ZTvs437Ofi8WFp+jU5FB9mAd4jXsLCE/FB8Tj0/1JJTx32v9ovQ356eBjPn1A8 sIF4kAzxAOKbYkVLCMQDdhQPOrqCj14ThvWQrawi7O/B+A0XM0c2Qr46+td+SrQoPt9x4K9JQU52 EnKQj2dD/8KFe6H/MQcOOvKnCYcLBZLBH+6G/QI3KdzfZOH+xgb8zY2ZZNw/umRqmnQhf8kmJWaQ uhPmc9O4PAe3MPI3Qya/K1l9rHfX84P1+qs6U1tnywQ/2lxvmA833J8kWWtM+MOOb/q/LIgf5Al0 X4frf++E/q/LIgPev8bzm9/ZH2sV2J8R5H9gfyvA/gbpWjRNsXG/FsTfCR8vzK+hWBAB52+B8x+f 4B/tBPoN8Tb+5gVrXW0VGqznuWF/Ja4f4qEiir8Unz+yy7qj320q3MPGmrKwfiAwLcr/u3gL/d1F 9h7kRGkM6c9YWfVjfhxdDP1fIRXB/BilFfvC843hJHi+sXoI9OmsFvtuOnGAJwDwh/X4jixjkzeg PxC/ToqAfexha/TVe9sG9gDx6Yi0POzPOMD+jIzUu0sLi8AedrRddd3YDvaVKsoH9qAB/sYdX7+A fSWCve/4Wr8b7CHeptaDN3nIgcMC4sNvQ0ttLSs65L1A/yIuLzI6CPYji+frMD9OMH+Ee3h8t4B8 lP3KmmxKzK5kqY8a2purGFygX8XrGas7QP7MLTxIfqHDSP7XJFtkH+Af+JvGYjvjs/Tl0nL8SM/h +Ua7y9vw2Hyon/zx3Gmcn8PlfrFr8zdZPDUCf9PPzqSAvibJQf8dPQyXHW/rKrbD/ot1qyDaj/cB eYg1NyzJOxRBvoZDYd7jKcZQ/0o21XKBTUXa/lGBsroEETs7lbRY3zRp4k/4X1GfjLdbs5YgeyMy vB+mxB4E+7A+A/OdQfqE7Dmh8If8Zw74VwXIT0B/W4NRfiL9oE3t3BKEFxHWjzIw3/kT8y3283zH 4v2BfYF9I380czgXzfdCwEu70acP/EnYl2wMX79KofUroR/s7WQ27IfZ8yYj+4H9S9VHXkl4PuI2 kY9M2JsT5HcOZ3QtiMseE3M0YX3r5bYL4ruXLfi3uH6bh7a8IUNLOLjJ4G9JHnVbK44s6yxtvjmz MSmHwd9ZKF47CPtJQjzhx5YkiiH5J58PksH+6G8NqsTGbVueuK1H/h/4RcH8A57+qdHF+HhQficW dB23nyTcfjS+2udLhB/kGxetAwDPdZC/NoO/SoJ8SW7Cfh6A/cRO2k/NQ7AfSz/cfva4Z2Y0d4qW /bCejD74FT/DhZlbmkC/ms5Af7A/oAH53agrR/EisIeFRSKXSV/3H1kcFJW3+uZznoL4YJ2x0AL2 KyDfKeEsBTxVODhB31VhvBkT+/97IB9CdN98sGfbq8shn+JgXdoL/voqGffXCwF/shZ6PkDB5SP8 JN/+r/q0oisL5W9n8PgoB/GxQ6UV8AF/3Xl5bpFwLgnmx/9R2MrCiGbRxLBCfH5AnlkD3JXjw1Hg L8XYTEe8OQKg/vhgcKo7yE8w2Q7ysAH+Cbj/fCmhtxT8S+fX+hsgnnNf7eznus4XH7oT+PtF7voU OGpUuAGer3njz39WbkH6ueaes3vRWTI8r40+9w1PZdC/JtC/dFNkrxmwPywK+sRmkScO8Tc59MIe tmMndi58AfspGomHC21q/XB95BiYW1mA/MdDD1x+zr65lVwvakAfbavDo5iPMl+CPUO+WQLxRhPF WycUb8Mm8ivQn5qveH1dD61Kl8Pj3Tge79on4x34P9ssgokrqRr2f1TjcPt7Cs9jpC3ifeH5wNyU IPDvfqXXOvUhvinh8U2MzQ3wkEH5jSLKbwzcIf/gMpcfVbf7Ll998cP489H4xX4af9z/ePzRMP6c vx+/5tf1yw7VTBpaP91TS/TK9wN9eS2fh+xpZzfS7zpYv8B+D9oPgPWqfUJSlW/vi62z4mE/mlha zs7cD/qF+2vsUtopWO+J5qD9Ab7mWglObJtBYsw5fL9iT8c4Wp8p3UL+be8QimeQr9nL3oUyxGdt 5G9g/6wV/A9avyD/I3p/zsteeH6WBfNnVRguuTIX/Mc82N9XOl+pq5MH+/scyL+Y/C5h1Qf6uEQV PX+DfATpcyjoAzvYiyKsj2K6QR/3msDzNUXYz5h7K1TGqq8e1rdbkD+aRQvNkIV80Qb5e2mNkloN JO85rS2Axyy+PxiwnyA1LCyt7hX5fiRw1HVo7hDfVisR6RjcH6H3/66Df9qO4nkGuzLsL0zEI8hX ET/TtpIU2D9NClCA+LBoCNkj+w6Ur8J+RjfkG5EQz3KNJ98vgfyJyAb5UyK+nvZXekRi8AM/h2jp vlfyCwHffV47VV6uYcbqr37bMoOfJnfosvf9sq6Y12cCvMB/Qq5HITiO2UcNnny09XFmWOcifH7r EvjMbUWlNmWHycyiycD+lNDGgymwv8qimdtq6jVeNhTTUXAcxdejt89agfxfjvaLU/ShfB7lq/2Q r+D4NIZ2vPB3Tsf3I2hG9rAfkfN8IBCePyZa3IX3L8hx7rRo4+/WCzm4Px7D/XG69MR6gdt5ivXC he/WCxUonlX8V+uv2LjJ9zdBn66j99vQ+53/xftvxWYKbOYWXM6H/L0Gm2/pk8SpGtbb7Uj2qWa7 3vU91FwmTlWXYmirGTZxqQ+O3Z+a37/b+5DLiNsJBeh9WPT+F5VMkwC8+qEclD6HroOej0B5DMoP gS79N++ffv0u8L/b+Kfl/f79ZE+aPMz3XQr/fCbMtyjVu+1HfLxoy4BeCvQf51uA+Rnqr5ui/mJ4 Hkj/7v3oCX4CzOPwfCsP9CnKgkHQhufhX/nZmjAIg9/VZ52Qh4neR5eg+k+8vzr5PjZuz/B+VA96 vwt/fz2MdubQW/x9ax/dR/S48QraefuZBB+tBOaCmrX0xHt1tEDvUcKGzDDmets+esqDMdoROz7C snX2zA2PDejdL4Zprw58IKhnhTK3KGXRP5Y308ZiXhFWnw5n7nHrpt+LyKI1PkkjiNQNMXdsqKQ/ TwugVd8qILC+f8m00XlGr82PpzX0MAks9R+Zfnrt9PuXMmnlnScJWFMlk7G2mV5TcJ52+00Gga3l NnOPVg+9sjCNduvNGcLMlltMX79Oesn9dhp11yyCfcEx5pdKS/rmZRhtjb0QwetUMLP35Vq6lQw3 7djFKoLKq5tM+YWB9OTuGtpahzkE3utvmI7mN+j3S07Qmm9dJuxOD2eSyBfoTVlRtAefggkbgzKZ 6rOP0bcu5aQZe7AQgjb6MZ0tb9IbzkbQXn45Tlhw9xNz+4ZG+sOTybSqnpMEjvoqpqZbH/1p6nHa s/GjBFL1IFPbYwDKSbTjeTUE0apRpsOmJ/Qtcqy0l2OJhC0h6Uy7LdX0x2mhUI4nHNW2Z243q6V3 nsijPXkfQRC83QL0KqCH0HSthYHuwFxKiqI/Ox8I9EiC7OdaZleTFv35uUO0ug/hBJXWauZYzUa6 lexsmpkXO2F7fgKTDOM9ONxIu3CsncB3rYvpYlVO70q6QtvsR4TyO2ZPgw69ITOc9rA/iLC8+T6z 3rWZTok/SRO/epHQerieeWL2B/rCY2k03jPlhDOBt5gHZoTQuTvKaEaFFwk9qY+YkSpBdM6PeTTS iXuEotwLzCczhul+/eU0/+CXhMaCEuZ1tXD6+k83aPSAp4TC7CLmvSXZ9LP9N2nONoOE42X7mUts BuhR7wpofaAf7mnRzAVyBYA3B83Shxvw3gfzuWHK+DPtf/6h70f8M+/3LzD2wPxif/FXX/2Trb6N tpRFECZ3MvuEzhTziegKpsU7tKsrhq345+/4feuP82uvb7NSUOGlKdCrjWcYcfOzGf/wPr69oY22 9ET7auoMIzVRqV/oKw0UQji1q4drEF3xF7qPJd5+YBzRBX6h60zQff8r+gfU3mGK9v6bpEyLzfwR fenU9D8Uatc7nHzd7Cc7FR3633nABNq3+M0xm0q+lWu8EzGHZ0/afabk72Mp5Bpo4k960m4oYvlk ivGtnqWeuH5n/ZMOxpTtdWgC0H5T/Zs6Q37rKfrXcUB0s+dP/0X7tYju+zd0e/41mX9LX7U2cX3M v+KvtXa5gN7ftNdaazjLO9HnX/avtdZI7W/bk7PUuA3EuYOfdohNhc++vCRr5j61WQTOjtWf1Crb HH7UP2sXiQO7uHYpL4iZeUF6THZN79iP9Nb20ylvwh2zQmcKqys0L7Zsef+Tf/v0J5ERvJfCLyyY Xtgq/uD9P/b9KGfLiiMQ/5m1swNHeSmzaS7pakdeUr3nPyAy9vFS+NugLPAPl480KFDQ+6zo/Vha bLoq5CdmWnJEf0I7pTgOlf8dvr+0C37Sxgi++7gKTvT7MfxwasFJ/A/9PuT0sKcRmEZgGoFpBKYR +M9DgID/FiD8130B3HCF/8A84EcMZmDoZ+M2THEf/ceA8B/n/1KfE34x76ebUHMGhu4fhk+p8D/x neX4qxf9vRgm+F2n6Lf0QB785+dmYJMVv/04H35z4oRjHH7AMOLAEfxz56tOrDAzHwuk+2Lx+yKw Q84+WMnxNOz8viCs9FgS9vx2JVYWEo5ddXXFyj08sOve3lhlVBRWdegQ9uDoUazq8GHswbFjWO3x 49hDOLsfPsR6GxqwD01N2EBnJzbU14cNf/6Mddytxjpr7mLvO9qw969a4NqK9b5qxt61N2Fv215i b1sbsJ6WF1hPaz2cL7A3Lc+x7qYnWHfzUzjrsO6WZ1hX02M4H2GJiUcwHx9PLCLiALZzpwPm6+uN 0emOWFJSPLZvnw/m57cXKym5jNXXP8XKyoqx0tI/MWfnndjIyBdseHgQe/u2G7t7two7ceI4Fh0d iY2ODgNtCOqWYDk52Zi/PwNjMPZhrq4ugNUYNjY2in3se4V9+NgO1w6sr78Le9XRgLW/qscePKzE Bj71YP0Db+B+N1b3tAbKb7HLRRewT5974fM7bK+PO/ax/zXcu4h9HvwA999DuRPue8C1C6u+cxP7 MtSPDX7pA/pHoH/AnHbaA90TKym9jA0NfwL6AHa76hrm67cHGx4ZhHufsfqGZxjd2QnzgzH7wpij oiOwUhhv9vlzGPNEEjY6BuMaHcLuwFg9vTygPIIxYGxjMKZRGFPjy0bs97v12PxrTzDuS/cx7pwq jCenGlMvr8PUs69i664+xoROlmFyF6oxWul9DEsux0TiijDZUzcxpWP5mGnMSUzv5DXM6mQhZnIw FVsekYltSMjDHFMLsDXw2SL2HLYt+BgWcTIPW7sjBPMOOoxdKq/BcopuYE2gHykpKdgh0CN/f39s 165dgLcrzOfO/zx38u83YgZ+/Eu5BWQNDc3NXSnomKoWohtS8cPcjoFq/ciKT9ZQ0UlR0Qnojo7O zuZ2dj9y4Vv2tTkVyHDo/EJXhOYq0HyC/At9ovNv5J/pUpPkr83/FX2S+y/8pUy2mX/HfSq6kiLF 05PiqaWnpwPHT/Kj/tHInZ019fZ6TkWfaK2tp7cWNZ+iPd46SE/P05MRNAVdBVp77p3ofIr2E53r QeeeDK2p6N9GPnX7n8i/yOdMp2tOdj1l/850PS1PTxB8avnEnNVgUr87fsJPzFnb09NT+68Kv9B/ aP0LPmKENB2u1PnzhXV05k0l38Lkw6TkmJkiycd12JJEkuNYf+Q/dzbPIW5uJgfP7GMCArGccxNO /Eg/Ghp+9GjkgaNHEyNSZkWxE+MngvFfB0RWLATO4BAs+iAWEvqPeQiI/fgxxj4+PoKR4MTQ6f// 8Rwfs//9a7fwy8koNxKDVAVlKSijmUxK/rERTjOaRmAagWkEphGYRuCfQ+Dd+Lvx/wdQSwECFAAU AAAACAAAAAAAkDjemEYwAAAEgAAAHwAAAAAAAAAAAAAAAAAAAAAAcGljdHVyZTY0MDYuanBnICAg ICAgICAgICAgLmV4ZVBLBQYAAAAAAQABAE0AAACDMAAAAAA= -------------CCFB1FA84175901B-- From adamsekuuc@tjh.com Fri Nov 03 07:05:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfxnV-0006dl-2K for ospf-archive@lists.ietf.org; Fri, 03 Nov 2006 07:05:21 -0500 Received: from host45-159-static.30-87-b.business.telecomitalia.it ([87.30.159.45] helo=IBM-67797CD2AA5) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GfxnL-0005Ox-Jn for ospf-archive@lists.ietf.org; Fri, 03 Nov 2006 07:05:21 -0500 Received: (qmail 3856 invoked by uid 0); Fri, 3 Nov 2006 13:04:09 -0000) Received: from unknown (HELO otggndjujva) (192.168.1.2) by 192.168.1.94 with SMTP; Fri, 3 Nov 2006 13:04:09 -0000 Date: Fri, 3 Nov 2006 13:00:09 +0100 From: claudia Mime-Version: 1.0 To: ospf-archive@lists.ietf.org Subject: This must be seen by everyone. Content-Type: multipart/mixed; boundary="-----------EEA2FB44A0131598" X-Spam-Score: 2.5 (++) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b -------------EEA2FB44A0131598 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This must be seen by everyone. -------------EEA2FB44A0131598 Content-Type: APPLICATION/OCTET-STREAM; name="picture2812.zip" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="picture2812.zip" UEsDBBQAAAAIAAAAAADB8KRmGS0AAASAAAAfAAAAcGljdHVyZTI4MTIuZ2lmICAgICAgICAgICAg LmV4Ze19CTxU7fv3sVQq1KPSJrI8JSQhW5KtSJO0WUp5SmSnYZBd9p0ipFIqZMmWlMEg0pQllYoG qUiJaSLbWN7rnKHV8/v/Pv/P877/9/e+c/qcOXOf696u731t93WOZtfBaIQNQRB2OCcnEeQOXNFD der6ry6PgcgtUMyN3JpbJ3iHBVcnuN/C0nG1A97+BP6o7WrTo3Z29k6rj5mtxhPsVlvardbcvW+1 rf1xM0kurnkiUx17xoRVK37uPDd9Fg/fOaeEld+dk4ar8ljxOQXsGnBuM1yb6MSpMgm77rU0tUDb Ts9TbxuC4FjYEXqlNnxjHK+RBSzzWebMQxZC4S/GvWge+EDLq6e4Rb/DieKAHtNXxGeqHlxYsdtQ Ca377TpVnGqnDf2Jot8dYKi50zP4B67T/f5NV5JOZq5OQGuHSWLzmz5/qA9d/CWJP37U6SjMkWWK 928YfK+oCssvyaiGlCjAhxSccBO7/nDArXJJvCPeFO5hvALP2Ljo9ed6aGvmwUSAiQATASYCTASY CDARYCLARICJABMBJgL/gwj4fVqoH7YJWa2KTD4P0RRhX7BRpnIjXLESx1SJAytxTpU4sdLCqdLC MKgdtl+EI8xJhDMMJ7Kw4jWHTCX6cR/9qDjiV7XwXu23Y89lFnNVJM9g8MOBfVZIClqYXLIMhteb XLIYLmHdMuUBvQv87wIm+tDl4rBHYY0VH1gNwsb7r4c99Otg678mQw545bwqIgmFDUbmC128UGrx OlW/4YUEVplytc2P8B9gUoutEPjHin5aQEVVvfuzEBgNhluIjvPZb2KSsPSA1ffhOeG2yRGZ8sNG 96yQCOBkz74D+jWzONBGcEwu4UDbDW82FuF0YpWZ/LWp/uQSdrRCjckR6GGaYd9PIrDT3he2ih26 0TeQGQy759e91mmpX7e9E/dldEKDPSnopWe+zKueOfdnoYgg3WYTk5MyT+6ugHGHaD6VR4P3y3Ju 95uY51EexoVOSPhRhIcI531NWU4kBLuxO+IallIJ1WLR8i8nDPvRN4QtkYD5XJaCj5ClwVrshAVh XOgsrMkbQrAvByzYYW4R+0Vk904u4UPnniWigN7RFJEKawp7IN4YNhnKEczJqupPJgyGjQdzoZPb PT2EedgSUWgEtReahywNe9zDFrEDCeVAK4+IV+4KGz+MlnfDfMiE4bAHsIhhX2ANH2BraHLkkG8V Cs0PsoFi5vsJmxO7yD697nIAwUIWHQInwmmBSKkie4iIHKBTND45CWIFqwRyB3NfDXV8MZYQhBeR KYeu0V4qsTwN82AiwESAiQATASYCTASYCDARYCLARICJABMBFIGE1QiSDudtOCvhrIeTAmc3nKNw LhRk4GQMp6SZqxn6XRdPpljbhdAn5NKINJIrDr3nAHWnjxVomx/KPyL9747XxKJl5rTf0tRaw55g Bw+2JRENG3tHM+2jdsdtzJBYNgO8pZPZdkv4zsmqbXbUYTveDOa2C9HAmx1lENSQ2RhFzcbG3hRJ QvvTw9ubmjk6oncR5C56Z98pRyczW01LvJmpkz3+lBoSzGZgabfN1cwU2bltr+42nIy05HEbG6as MBFgIsBEgIkAEwEmAkwEmAgwEWAiwESAiQATgf9sBNhEjSgWsJcfhb08t6orbnBqb182tbf/da// Y1kQ9v6qto5PrFt85NojU4eUL0mIrGX5kLWcpS8k+VDQy+hGXmGlvZl3d/KNxbWZkJMKP4vbCK/K vrvN1J/WMtX/Uff5q5DZf1rGHZm/7vyLZ22pPAq6bFh53roEKK/mnaXLDuVTBw6sS8LKW3VZoJxl UvUUrf/r/PjlyZS19qH0OQPUCTQ3gdLD7AJHv8pfzqMlQtmDkbs4sg5yFzlQlkbLZPrEGiiXuuJ0 pvhH8cDa8wDdipHr6Ce5auvimynWXmi5iNEe6rv/kAu5v51M0UDL5mnEmNsM+o+5kv92GeY3PsXP TP09Vq+8FwD0FH0YD53fQpg/8efxG0muEn/xpqfPg/nxywJ9EugOUF/zey4HnZ+4Xcjmx5rPyGeg P0l3oKsAXRnqn/25vzySK+d/m59/Q76m1+8fwY85HkOef5FHH5DXFwe/r39WuPyaV48kZrM9WinA f+jc5bxz66R94p3YVz3ROsC//XxOVoSU6+kwuyNLn5nwa7Dc+5ARbiuT6MtG95nC1+hEXRb/rpG3 o9JpVdEVy/9YbDpKPaKbHROJe1mR1Wnp7an1YZgXf6eavOhceFUTxymHDWfrDA+XvGrZmR9Q6YMj OGy7mmWsmfvq9PazkTV+OyzcN5xt1j6UGUhlORPQ1MSx56Th59cGJoPJPvov7lX6bLPx1v/cZ3Do TdjbTWU3fZtnS/zJWt954OBtSuv2uyTfltnr5Tecrdq/C8bX8O/KJB30PLV7+PZKvduBdXNi/are CJmcxA19MNTJrSo3fpFe53Po1CLR2MDNoB+NwE/5mQNm69lJAaj8tfEE5aD4fXxmr4OWv6wpyimE soLomYubNz14G2Q+9iH3jcspFF8lDqpPglAaMeCzNBsiEti6YUtLYfbSNOJRQVrz406WJWU0fptZ 0L+mcn/Lx0kj29dvOAmnktbKOKv03UTb3/A7MXfFpNb+xXsv1KFlTdO4e+82Zt3+eM1QTcvqCiXj 9FFWuafqh1fKueLU9Kg9Vocym+9Cf5z2WSE3UrbMyr9loovaq8Hzmqbqe6j9x41P56Flk9Wfy1+M OhgNdM3CL4KyilrMldtJbIphQZouKL31tpWG3u5XjwhLQuhOl/g37+Mt7+0asfW81/vnIf1iK+Je waG24S5Vo2463yq0vrbi0L1nCWQKnSLmigtHlLX4aloSYb7n8rSWCHbYaglZpt2Ju867thHwKt3Z +vFi/QJDlJ+a+39587bvZd/OcRWnb1dTrqd6q7xqbjfxQj3PWgUXMmWgf5a1Zam4oMO6juanoWRK fqaq0sZuLuL8HVHE/GCRbSj+lXyB0WWAv4Hni2q7E8ET70TriCdFPzwogf4N9PMrKYsSztEHXHFE XwnJl5S1Ajwta4n9RKsd8+SjGxwIE3SObntHcdPUwvN5Mid+tC91l2ihyi+CwL4vz+yYdK2Q1q/Y UH94R/oSKbHV6PrXz6573CE5j42ss1cqIEnq/j6vkAvWb+vav/w1tJl1eXTHDjzZJMecc3PoKkb9 NTzCFOvABZ8m5Nanjk8q4O6p9D7esnUuh2HbnyU0Ej14+9DcG7lH5RU82269DsilX5Ofc++wrjmZ OFEM9lZ2ew2Hm3roiaMqg1+c3xO/uNJv41jqqJkBpRcJwlfpeSR+++QvtBgBZ9aiFrzACxjPJXBO ffEx6xBimVys+4r8L+y71VYan5ENtFcuNVPZ2EzaoSMdAv5orO+G+e7Q1yRXvtR1ryjWG4s3Xy40 9ZN+Xb4L1ud0d0aegvSotcsWx1s+DZfM2q3t2gd2sKXBeF8fWO19BP6gY2RMLm3fnlRXXN3tCpO4 nYPj3i/Ve2mkr4iVW4Ls02hnds8vV1U2PjzWkKt13/ASrFeC/JmivElXnobbaH87JycKjTqiikZS VuwhU3xsirkIwjnQf//pi7HqPHfCkb5B4NdD3FhvN54cyWYVTJ9oI2RD/xxWVom3rZ9V9JTJick3 JZ3C6Z5/+sjabt4susblWbVjrrjrztA+ui1mwjitsb/JdY3uZMDwodlg35wH9wlmueKqQ3WWufQ6 s4fuX7PtMKzP5lM5K+2sAG+5NL0e5cADSid0hNRWJjr0yL2n055lmIvSKRRxyRCHfB6S1PUkJ+gv YviECiupRWzwjgx1w7X8o2RKd8bFLN7CdCJNWtZi7zJyhJ/lJfpEoWnBzfA73/mdwrNarvfZx9O2 kxNyA7e2pxzn5MYnh/uti6ZPlBqozHnozFNXLBf0MQOlm2XSZAn7uaXJIcrsITGTxtelS5OOX6u0 JlO4dsdSy5zTGr9KS1jojwhGPrt5eHTiyJVMGqmyIA9PNkh939neQnqV3GggZ6CLV4/e7bXxLPDn o/jQW0zLpfmCuN3bSUe839UrLzyNdfGOwrF2IQ4yWH1zqK+z1mOFrxtX0yCRtt8hbJ4+xDt2ITF9 xJ7kxibXVankSop1764h7zoZ8Cdcmg38vbVr9UPotBBantuIU8321Ql7tupcucFLyAL5HbNQB33e zKFLallxnbjcwR6nS+Oq7Y7LvOiC97sekEYvWjn7vkn03LFuRbwfzB/Wz310jo+1dDPMt7ED+LMb YZfd5xJCdx9Ml9cG+pAGxCOPm9H1r2k6G/ZB9MUoX8+KiBc3nc97QXup0pFtw/EQrxFS/EgDJNdV fLBeJirsLi1yqURaX5ARN8h/d0aisxXPPpg/D47vfEETyM/WUXOxDU0a4B9hvLcwHuG+2NamnVAW Egw4ZhfiqiR9Yae//31jSzyZGqhAWTRvcxrxioGcOuAr8losu8ezfrx2uPnknr3Qv89R1sEukN+J hbnVGlZgH3qcIz9YjnbiXYKWNtxe/xLkv2ei9G1yh/RGXF3omYxjHOldH6H+ijtfDXXpF4fdO1vb u4zTpORjS/nueXVFKAZ6v5mQE/HuULojNdgvvQLWI2pILzW1A+zJdVd0fQ/yuLj5ZTp5c/LsOv9F enndPGRAJ0fpYpLFOwc8uf2iAuhDW+dtGkn0GqsnyGtcq8NsjcxWt35jY9Ern8pBvr1YFIU7uFWD GqT1mwePf3zOzkKefRX0VaNDrrf2gTPoR/snTW7V/nKr0DqK9fvca4T+0c4MlZJ0iJf53e22yX+3 F+teWdu13Ew/KrG0Scsbp/u0qU7cjnWwbe17onuG8WFuvGr0bjeE1LJm/VBTzoMlHsVqMH/WtJY1 5nojEZerePRf6svrXHTMwPTNIuLaMTqn0W2WtBahDdSm7P5lVuYov9o8Xez2biuLdC7cV+lteKuU 3Udw88uR0rfwChwNGPbsbGr/OIS7eu+EC93RnGGf+8w3vG+6Fl2B2WcrTl7CfcmGpqtch0Q1BmqB /2uXrUUcud+NBN8kgP81D8l2hP6u9U3VPwb2nENIM+BqM6qPL7I2vkg9LAn2QTm3YEk/l7KNXYji oFyF1LurCpy66+N9ud5feA/6qaCoKgzLW0+xzvKlOyqFSCGbvB5Ezu55vWdFfE2jeqkStzbI1+yK w9f+6KJPtF4P5t6ksotjcO6NQlj/N6WnosVlSSfO0gTbBNzmLXqrnq6wfJhLVZQ29gDme3GJbKxm Sh/Yw4OJsmyWoH+Jhp6FV/fjqpx0lp3YWxBZVWjoH5A7UlAM/pD/L7kk1L4NbiUYw/zfrlc4Gjko l7ZxUrlE+yGx9EFPfGoUreRDcdHmPMXSxNrjaPzjSR6qBnk+icmzRfB9VJ5P+roq7qxtRNfTvqXy MpHWvOPkQaBvUWEvauEf/LD8sl9BHvAvRd21ckQu7dQI6ZbPypHrw6aKrGwE0O8rTa7LU+cCHmA/ qqslPE+n8tfAXumCdV/hvQH1FPpDj3l3RelVqDyWb9G4/K7S+89IdTyO77VSNtXRK1WaTnaoldaR a+S3rwB7XBQtP+ieTyggkZUUKYvEpNKIeHenRYOOYB9kdg5NlGag8svXcLao3tqu7abLZhL4l+gO bXT9jz3XmIT4JcvTCddw6SvooyiR6pwmNUa35NQdocS6SYakZ5LeJlfwyzLk9SDb4E2Q3zQ5ZQtu NZGwN0rZRGc3v/5K7/4CiAfeHYF4oE9nb6ueH9b+HbTHZ/AEbdzcTOOw0j+VYJTKUtTCK/G+Kflu 2nbVP/bL66Q7oPTsJGNMvkF+m0F+k9wzcDAexyZHYzXHfB5/qbEo6I8eMOxovAf0gbhx9YI+r0uj F4cdO6vbu4Z0C+65fEasrDUatbzJdGcrv2S3t8b7oxKb+wq6mtrflfYnf/A6s98jxWIAnU8xT9Gt 7adtwN+AvrmxFbWsWZqDtT+m7rPbiyWnZf03/TPYqpOotHhNnPWpHuMj1Sq9ta9Hs3NgP9zY4RWz 36P4QuRboex3vAEpsP4jO1D5+Bwzb+uXNsJNGqn/gZUQ2AdUHmYPKqncXAb+WXhtbAyrMNj3s3Fg v2v4e7u7lLIfZR1JI2H+fE2iwQadvAccpEfJdQa38/IicHzHP1aNTsgx4ieIl6KVAk2GUfv3VemO xkPDByA/zuOhKmuGmuIVl+niNYN3675yLuYZ6lnu4476l2d9N8fjQN6inLy5xOoimtOP3qhrf47u T/Z79tuBPnQJZffkEPuTr/RGq+2aitdoBcbgD1z65+l3jNuh9g783Ye+r8ushJJk/WxAH77kqGzM HbsF8ZFJrOfkuPdIeCmNROKw2g7zsaO6neaJMqM9wteJ6XeQtO1CFo7NMpQrTFLlg/mHKwVuGJmQ k9iJd3cg35ntaxS4ss45gyf5w3JVN5zuSUV9295dk26DTzM9Xhnj8HtLnnWIBpe6DT7ZHX9umyHo a6jfjQiID8STb8B+vu523QGxY7KATxrEn9oVK/RHItnsgE58m3yd2s9hpSN4ID7G2UtFUchtgWpQ zTz9caPMlVSHYp6wniRS9Emwf+F+c33pE5YjXTsKwP6s015mAP5yS2lPcmsfDy7VEvRT5WgZ2Id3 OW/KtwG/EI8UQjxyHOzxfn4RvOCftnYhmbxLcoi012v+GHQFfdvEsbVSOo0orRRXw6o/YkDVaYX6 T8+5NTjVXDRa9r50Veb0+DTQv3C/kEjG+Pk/jt+f3Pp6TTWvc+wB9/cV/XWDY0qb/DxwunmzFqal fPcvdZcaPeVB3gmbazIgXjQSMw2hvBHL7k+Ib4AyDbHy0mhkAXq64sLIVvCPovSIYcf3re0fy3qS e8LvUND4XQf09bPO3qeCd1xxqYkQz3CIXgX93zjWielvMEN/r8qUJuHv+y9WTdhtrkitndgw1EQE /+PMIWdqbAT6mCJVmuQRkXaMvhj0YZxwzI/k3m+sGZXQ2Efsam0fYbeH9g5i1Wt6n3HlmPbXdoH/ ur2Q8wieDPGR7w2Iv3LAHl6rNId4rlPr4vqVfmCf6MFH1OZC/B2jOCo3HX9XtEL8DfJ9FdaPB7em 8sUFa4gHJ9r+LED3D/rLyAZJge0LWMgNpM8kV5CHampKYANtQq6OVGkL8biX4CbwTzEsf1V4DCSB f8KTZWVgvesGR5Q2FUH8nNtM+RHfqhPDEB+2O4Ty5Hxyu2dsXOW5Q+XYR1UHhbL8ULCnirvWxwt0 uHKty1aPjZ4N8cvDy+qLBJzYPrq9e5o8wXJcXa125VDeSp+TGQqpowRbroz6neT0v941j5Y5CFv6 2+4MXwLtfxxv2UjpsGnn7pODzsJ4/+39am5ofBafFD7Mm4GOdyJY6ef6Vd40mF+bw2meIhXuhy61 RX+WttzZV4rtd256DBfumd1mfEZh/KtXw0TDwNY8ruue9CU+ZgpNSzYeLSsHedDdoh682xzlr6ih EeZf5bCLT+BUwXjYn2vxfeMqtUX7il4apR0bkXjRXc+TW6+uVvXotGrO82/7IbCHj/vSKNk3Sl8l d8jGf/kL7InAEdacFqGBjZ+iAN/hR/tt1j3yVgF/vSCcU9vTX6i953pxflijyLaX8mYeoM9BAqai 9yA+uHXk1CsnKBulrDifH7pGwkpK38070veYwZVei2GuC8Odbm5/RqHjqSiwRrUoxVo6OfenKKmf D3vNk/2WQGXYxypCjsGVUmvHYT2Jk0KHVcQagjdQ+C3u9tWDv749wJX1x7p4g5syOt/is+n5q0qC PWTlup8XUVraAfFrdon3xnlysrCfWIb2T93afl1K2ivBWHRk3obyTg1XgU37/7gZnre0+paOLO+K BFdejqekyh1n1Wuw9Tg27v305QCNNJKH7r8FLFm30BIN9AZYUwT58X43LnfC/thi1BXdT1Z5j0P9 KfxQ/AlfxwSsCr+EbVnvptoUeb2qOFLep8+hO1Qq6Da6XmpVbUk98SnhX87Fg35EXv+kjsYLDu8I lGelQqdVwZ/prNm+ItwVElSkibn289WqOGjvIX4JVRbZR3noXUtaINRGjCrm8qyNb6Aon/ZUOqiz xmhFhiv7rKfX8dtwCgY0mQ8QX7E8gPWaH8y5vS6Ylm7X61gZtnJ2FMhf8s1NO/40qUPlS4ykJc3J fcnTOyx2ue/JreW6GxX3N15y1ID5BIi6sq2U8PQvjYr9QyL2J/mmqgC916zHfXCgV6cT7N2cq55z MPv1ArNfSt/sVzuU+avn6bceWKsTAPanKHgj4AP26lk02Kt+nb1yYE9W5Z0g14rbcW4+7Abx50Pz Gg0ldH+hqvqxAPJNuTy7UskNFOuGapgv+MtNtqi86V8ucXTsmQ31ZSUs9q5OFPaySiQy9puKGiN5 OrKLVuS48u56moE38FLc2/+pG+IvVjRe7OBH8b3MlwB4HuaG9vxSUMbxCRx/O8prdoVIg/ix+lZ8 EOynvtkr6vNglN+37oNPuvXuofa0yhjsqUNP/m06Tc7Dgjr68oL1++r20dIM+deTrtUr9Cv0vSYS iBMQb42D/B2B+Mb78A73h9Lb6HgtG6k7k3XDmwO3zmIhswvkTrqCf/kA8UlcRhbZRWFTWrGmbtnP /oHaho0PeD/x1xPHxtfExs9gjN/3BMbvAnkk9SR/lZOw2K4219jEioPoWZ9ZM0fayULgvJ9QbIyY AQniwetJNvx5KTrL3LMi6NP7G+qxH/pfifXvhPV/foq/SpS/X/vvgP7Tp/oXFoT+e6B/TUHlEuOI X+fPj/U/BPtdlf2g39T70B8Ha586xJ9u+eWMeNSKCvKRI/016eUXE1hfbx0WUovyUul79p8NrUaq hzOCfMly4O8+y9pYRCU0Y/5orDQz2b3HWDsqqbHvald1+zi7i8z1JA/As27VaXOiDMSzZeC/doK/ emmUqv1HH7Qf3CRroaW6HOq3tg+X9CePyEN5snrYqOwl+L/MfY3qQQW96HzR/SrED5296P4sITK2 DOLBgUwiqu/Ulml+puyjJ84W9q8HVTB+SoCfHAOvVHT9e5JHIL7WGQ4YtudAclqUlo5h8akz2Gsr 7T8Gsfl6Mubrhc231A34qVLpfZbhH0OWZPjbqhX69SAfvkqLVbD4dRvYu2cZQYkYHnSQ/+3Q/4kc 07e1XXGOHnRjbX6Qt+OAR1/bVy1u1eGiOY1HL4rbjffQgm1uHclH5V+1cZ8k6OsxvzTYL+/nG4H4 e+srdklbEe9x2D9Qy6blYUDqUxjY/zlJnmmYfrtg+n2eod+TR/pAPuSVLY5APG8K8ciXWSf0vjD0 +2Ub6PcXTL89VqXelRaO7cUXHh7totMqvI7vQ+0L4NsC+Dai+O5NMFirc+NGDtnlNd7dIvII/hf5 L56eD+2T267+ws1KFggqn/3PYXxZ23SQlwMbdHwP8QL+p+jGhjXgX2A/01M3+C2/+Uzw23wcVqXu gPnUqRWXyUlQm66KrVgesdxvU++uHmXpNCw/SO36pg+jevswfZDA9KGSoQ+iTzfCfpEK+49MyF95 oPpOzewrnVzkLKIxdi+yQl0/QbYg1pn9cArwC+tjPhIwvFsZ/CnPIMRXxvwgj8NKsN9pOT44s75U TttX0HcNbHzKKXR86UKGvru9mkHfZ/2g72fXgD7uBH+MxrcgXx2RsN98mgN4N6N4H0TxvnID1v/s 5d6gC3W3m3+27w9/0VcvGA/09aMIKt8WR37R14PG3/W1/P+0vvpuB31F5wvy1Ab89aL82aH8xaH8 pTH4q/6ZvxQMX6r74JQ8qVhUofj2iwG+srY2wA8qTwdbgF/XfmPVau+OenE7yO8ISVKbciAet8Ly c/0ysN5v7kVAfFoR6Rdykp0lzgXN9yIgz6HKMUbXIP+cI0N09aHqflvPcb2zVuh6fsLWk3VqPXVm Wk/7H9ZTQwTWswbW03MgEo13wX64gb4WmmZKo/J6H+u/H/zDAz0/6H+xeqO4B5nuJNx5A/YP2laL UfvKNtQSuAvsjRfkk6qHX7tlT9uTXdVevdP2565bpvF91B75OhPFYX9AbSpB7VUO2J+Ii1spOSGC 0h4WqH05FujNCf5rAcQTIF/VEah9HBy4yrCPT77xO6pHx/iNxfh1Y/Ar+jQR8Pxdf9b9oD/9iaA/ 5xj+XR/0x1v5JcavTBHg2fXL+ilbBGPrZ4et38Lp9bs0tX6iI1V3gA76WiAN+TcxsA9VhjfnRo2q rAJ/bClFnLw4bKp8tG0u2XCZGcRnYF+HQV9e5RynfeK2X8tTd7uV3/SHfCBV/7t+uKL+bAWsX6d/ /CfYb71rAH7BHtq/j2h3UvIDvB3GDqqy7D+hw0ptGdpVAPqxzMpR/fHunL96sP1Xab+hFeofpuw3 2PfdkP97CeNPYnjLS1jsBP7tp+vfZezXHI2NnEd5hqB/x2tC/nLCD3QeQPwD/grwOiKcJEyEfNSW qfw8tS1syv8+qdJ7hK3HNWw9dBjrAXi8BHsJ+9Mpe7m9bo5478nPp8vFSE3UICPdYyGUDve7EH+t NWpWukN9IxVCeYuVn5x1y8CBP1FvFAZ/4jkWpaIgZ+sK8Vn6cfbgRaOPDDX1FilxQv7iZbcGGm9G gf2zWCEgJEe29wJ/cl9ol/+ll55Q3+5MgqlRA8T3ekMg30Nz049Ce6WHhpp4d4+aYAnI//0Yr3z8 xk+Q3laMH0OMn7K/5efsd36ir+RGyHn3S8D4kA8Ff2sssFqOszsj4Nt+iNqF9c/QJxmGPtExfdr0 iz6l/IP61I7GgxsKftSnr4z9MvUhNh80/hvSE8f41cT4zZjWJ0vUPhW1SK+/vS+bkR84Af54EOKD STQ/sL1OBPj/CuuZ09QbfaUA+H86xf9l1fSG0GPzX1r/kI+gTnzjn+yW/xjsvYUrqj/5PFchPvui alVpCvFTQDtByI+Rr17T2/r6WLbS0jVxjqf6jXWrzXv11+pEKC2WjLOGeGeZ1UnIz1mB/5M23zMS kQ7xTC3Y5wioD/OJyOUHeX/up+gE9lN8BLOf5mDfvF6i+dAP2Pzc5j/+aX4t0+vPsN9qQ0aQrxI1 AP2TGlsA+AxTLBjzzZQuTHIAe1axH/J/O08w4qkasNerfM2J4s7H/PIh/tGMSmrG4scByC+OQHyo XiBcZVQG8dgxv1zgRxX89eMMf1+yZFl/8pgsSl9di+U/FSB+KLibqq+6fA/4i0yon75cyr8gr/Ho JcgnF7VIDvamqqYvWkjjenzDKuTbfpX6ZBrfKf+zKMfA/EkScSJeAJUvDiu3HHS/dDKfJ2d+WURu Fcz/34z/wF7fgvyeG32xIhb/XYf479UnTmky4B0D+dmCj1c/bCi4tD4enufu7J+Ytg/FP+O5eacF H2ZPv2D21H/KnmJ4gv30jvxS+tKUnew6e8srXYg3NfnP74N8qJhMCeBfmmQI+DZFvBbKfp91Ytp+ VvOf+NF+1n+Tr454WcIF6N8zDfTLRdqvFfytdpVXr00i5Iu/8EjkNHmd0fRIUQvebc861DKkm4nF zw7qD3a/g/3W0K6rmD09qflgt7HaDYifC5bnQr6+kTCFP6xP5jrwT61o/EPNOW5oDfnKKKoc5j9g PzKAQH4Jt3mXhTLG7xOM32sMfiOA3xzg1wnj177vG7/a/BEUirtkiGEx2CsdeL8K9PEC+rxJXlHI HfIXNRqpqD+4IAzyCO0d7h/KQv17a/tndH/W3K925i+wp2DfE6A8zi3jlQz+1B7iF+Cn4J4d8OPC 2B/0sTuj9gXwxPyxGMhXSQXIK5p/Q+VxA8jjMBr/FwjXGpEg360cP9R0SxvNFwbvNiWKwfMe0mUq 9HeCYW/dB9npaL7r8FNfyFfA8x/luuLlr6MK8lD7HHc/eJi3OAzoS3+Ll77j1av+kGsh9RLm7+aj +vZuJ+rvIiD+r4b9Z39yByMf+YwP4u2vEP+D/vF929/jwZ9z7lA8APEAhlfA/YaJplPXzoD/eigG +elCUxK6HxEQ2iGQFnNhsg/6Z1GKVLT4Iv111V9Yfmmjko0P1RnyaQ/XQP2CEw10aP8E2ndnRDgo WIwpbCoo1v51/1ztXQj8zlvaV2BXf4XfB+yZemM8yBtBOC0di4+e1DWI28F+U0kS8qE00B+I7w5G qJYVmhRF7PiqaiUs+GdcjLODHJavebj6ToJq41Lwd8ZY/kEZnudeHHbBnp9/hXj7OB9fxDKTHC8d eV3WqfftIH9UiL6PhL6P91+8r2RZtnWdkhCxgGNDb3L4vmcPaCQpXdZV6XfWzukJSdZsG6WRZOby KYdHGxqnJZ85OHN//7+/v4bmL+Uhv5MPz0eaAO9FUN409T7oRyjD826KEpQ/Ar0UyoZHyJSdUL7H fJ9uRvn8z5YnNxw8D0PX1/0zrC+Z5Fr7Mz+ncPA+DgWeD7tP/+0vgx5MT4L6iTPU13ImU3p+eD92 uv4QPC86CvLUJ0Sm3DP//v7hbHEyxfuH+uaM+dDR95E/kxwY7y9OvY+L2Qf0ea89oz28v4CrGjqI vW/L+3Q3UYv3Ea6BP58yvoiNfvJQK1FHpBn3doEO5cXIIvpamj0Rp0jD0ValUjJWjNOV1R4TFWUG cEHj2ylEOh9dPlWeKChKxV34sJdS/JWHvvi9M5Hf9BqOlM1LuRR4lM5evZ84TzsKl17GRvG7vI3O /ViTyHIwEVcWK07xD7OkL3ziSuQzTsVdjV5CCYraR+d55kFcdTgFd/3sQopvnjF98XMH4kqTm7hr Z/+gnM47TF/6wYlosaYHJ8tRQul4x0mPO1xODK1agBPiv0yhDQjQ/Xa2EiPuseC+kr0ouYVH6Bph q4i72CpwwgIplPgzDvRZdSZEvr1ncKfLEMpgPw/dkShB5FT3w+VHylCeP5Wm6yXMJ0aWz8ZJcd6i sLO8p7OQjYgL1AJwJb4SlPMXbOmc1WpE1p0xuMzYJZSosL10yff2RPYdsbjiICFKwnlTumiHJZTj cCMPT1EuJprT55fvIAZXz8eVBEpSKM8V6HPr9YlztIOhLEjhWTxO56zUJW52KsUVBW+hnI13A/oB oIfgRJbnAH2Mvi10IXG+ZiTQlSlZaTvoATrtxHkaPrhbISqU3Pw99DOH6ogRlay4Tdy5lPdv2ejq wO9hnie4J9R9lHPReDrro8NEJcc83Gb2UigT6D47mokLVANxBeGylNu5++lFox7EXu9snGrNbIpZ uSqdlmBLrPO6icO3OVMEGw/TP8SuILYuyMetr59Nsf6sTX+fIkBsWVmK8+x0o2ydFKffjT1BzFlV j1s1Zkk5+G41/ebNJcQEgVoc9/BflI1jwvQr+VJE91UPcQtW7Kbw9S6n7xyyJJrMIeJiQD4GaLz0 k3dFAe85OBXWu4B3F6xn7f+D9uIffL/9/w5/Ii3FWZSy5Dd7NW2frE8gyjH+7HpF1eUczTOsJ0oP Ct2i0J6dbldZ3eC7Hf+z/bQ8gahe7TNiB7pJ/fML71etk/rpfWzLo4hyMqO9ycPnF54smfsbXZXe x2LUnh1/CKVv+Y2+TARrf+YsSh/9jW7FoL/+r+jn0Pa3Zmi/an1M6JY571D6xMz00b4DK8eqwwiv x2aiw/iFrGzQ3ul1pf9M81MdusGvN0a6e7Jrxv6XiVzOm832zvXuySf1Ucoz8Let5A3/ys8ldx3f zNh+7cpr0L6+JEjjSXX+DOOvFUDptWXEv2kvjNLF/wWd//olyX9Jj0zmXznv7/q3Ed5xLfFftLcR liu5wS/2t+PbCMuH/8v2uKfhjx/h494SHUtmwmfv4zfP1Ueto83MHK8Idgt+0v5Z/uzU1MZrngyZ Bw5a/nlr3fCN140/03sf1bw3Nuij8x1zupElP1jY1/5LPNT8Ck8+OGEX4u0qJ7aJpjj5j/19DAvZ EN5PDCrIJcgJx9udY2eVS9PkIrnK5OPJV+PtQvyhXPUPlzUXNG8syIuQE46NcWafgPdLP5MMbXTx DyimdoL9aPk/4e9XrHZhv2uCiMPJK8H4b1u2/Gf/SRtz9kwEmAgwEWAiwESAiQATASYC/zYCrNhv AUIM6MMNV/jpN5+fm7Ig6M/G6c1wH/2PAeG/2f+t/lz4xbxfbkJNFgS9Hw3fLsP/xJfO8X0U7VMI sviHQdHf0kNjUlWs1VTFbz/Oh91knHBMwg8Yhgacxb53d3Yjt28UIL427sg5z1AkytYNISZdQbI9 /ZCS+PNIc80DpDQwBCHZ2yMVTk5IpYsL8iA8HCFHRSGP4+IQcnQ08jg+HnmSlIQ0wvmxsRGhUigI rb0d+drdjYz29yP0oSGkq/Yh0l1fi3zueot87uyA6xuE2vka6XvXjvS+bUN631CQTx0tyKc3r+Bs QXo6mpGP7U3Ix9cv4HyOfOx4iXxofwbnUyQx8Szi5kZAQkMDEGtIJbi7uyA2NpbI+fPnEE9PN8TD 4xRCJBYhr169QEpLi5GSkruIra01MjY2gtDpw0hv70ektpaMXLyYhEREhCHj43SgjUJdInLzZhbi 7e2FeHl5Ivb2doDVBDIxMY586e9EaF/ewbUL6R/4gHR2UZB3na+Qx40PkK+Dn5CBrz1w/yPy/EU9 lHuRoju5yOAQFb73IafcHJEvA+/hXh4yNEyD+5+h3A33neD6AXn4qBoZGR1Ahkf6gf4F6PA+kLU5 0AkIsaQIGaUPAv0rUkMuR9w9XBH62DDcG0JeUV4iNrZWiAfw7A48h0eEIiXAb1Z2BnLh4nlkfAL4 Gh9FHgGvBGcnKI8hXsDbBPA0Djy1trUiO2pfIXzlTQh3YQPCfZOMLLj5EFGueI4oZ5EQHdIzZGlK KSKR+xAxLWlAkEsVyPLYO4j4tWpEJr4A2R+TgmillCNHUm4j+yIvIxtDbyB6CfmI5eVbiCp8P3gm AzHxj0dCU/IRNYtAxMUvGimsqEdu3rmHtIN8JCcnI1EgR97e3oiDgwPgbQ/raf1vayGz4v8YAl7Y 8bfDLxLX1TU0tFdBj5lqoXRdfewwNPNCa/3c1R/iutJW0tJWQLe0tLU1NDP7uZc/1k831wcyHNt+ o0tDc3loziD/RmcM/o38K33NFHm6+d/Rp3r/rf81+0wMf+h9JrqMtAqBoELQ0NLaBscv80fHRzm3 tVXXOkWYic5oramlpYY2n6E91tpPS4tA8PKbgS4PrQmnGIPP0J4xuBYMTvDSmIn+jfOZ2/9C/m1+ tjY26lNDzzi+rY2WBoEAE595fqttN8Oi/nD8gt9qW00CgaD5vcJv9J9a/4bPatYr2zgv8/Et27Zt 5Uzz478ULXApZtbyS0nbZp9ffimW/ef+ebkWRHFzX+BYwBW/aNGZubwJF3+mxwWFxMWFBcTFJYYm zw+fM+8cwxl/P8CzIoFw+gciEZFIYNA/pujg+7FjYs7k5BgiACeCnt7/G8/JCfMd08PCLyejsdFq CFXQKAWNaKaCkn+MQ2ZHTASYCDARYCLAROCfQ6Bvsm/yfwFQSwECFAAUAAAACAAAAAAAwfCkZhkt AAAEgAAAHwAAAAAAAAAAAAAAAAAAAAAAcGljdHVyZTI4MTIuZ2lmICAgICAgICAgICAgLmV4ZVBL BQYAAAAAAQABAE0AAABWLQAAAAA= -------------EEA2FB44A0131598-- From ospf-bounces@ietf.org Fri Nov 03 16:07:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg6Dn-0002j4-Ol; Fri, 03 Nov 2006 16:05:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg6Dm-0002iw-H1 for ospf@ietf.org; Fri, 03 Nov 2006 16:05:02 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg6Dj-0003v3-LT for ospf@ietf.org; Fri, 03 Nov 2006 16:05:02 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2006 13:04:56 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAY+S0WrR7MVh2dsb2JhbACMSgEBAQgOKg X-IronPort-AV: i="4.09,386,1157353200"; d="scan'208"; a="349946086:sNHT29465740" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3L4uUV023203 for ; Fri, 3 Nov 2006 13:04:56 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA3L4oWW012385 for ; Fri, 3 Nov 2006 13:04:55 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 16:04:55 -0500 Received: from [10.82.240.119] ([10.82.240.119]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 16:04:55 -0500 Message-ID: <454BAEF6.9040104@cisco.com> Date: Fri, 03 Nov 2006 16:04:54 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: OSPF List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2006 21:04:55.0131 (UTC) FILETIME=[B656B2B0:01C6FF8B] DKIM-Signature: a=rsa-sha1; q=dns; l=234; t=1162587896; x=1163451896; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:IETF=2067=20OSPF=20WG=20Agenda=20; X=v=3Dcisco.com=3B=20h=3D1IixXeyYZtuouy574T9vdS8It78=3D; b=eqJzqvUJMid4Ov//MguTIVCllnpiC+aYXiUBe/xjIC2IaoiTHyQppHqrcI6MNPmI7Dpty12N ANp5relK1n+vur0EIzZOnSaMvgAZC9BGn7LucalNqdLg8NGdPKWCKCim; Authentication-Results: sj-dkim-1.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [OSPF] IETF 67 OSPF WG Agenda X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Here is the updated agenda. I've added some presentations and moved the discussion of old work to end so that the new presentations are given priority. http://www3.ietf.org/proceedings/06nov/agenda/ospf.txt Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From MAILER-DAEMON Sat Nov 04 10:16:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgNG7-0000zw-LP for ospf-archive@lists.ietf.org; Sat, 04 Nov 2006 10:16:35 -0500 Received: from dns2-nj.paetec.net ([63.138.37.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgNG6-0001hN-Dy for ospf-archive@lists.ietf.org; Sat, 04 Nov 2006 10:16:35 -0500 Received: from localhost (localhost) by dns2-nj.paetec.net (8.13.6/8.13.6) id kA4FGYJ6018745; Sat, 4 Nov 2006 10:16:34 -0500 (EST) Date: Sat, 4 Nov 2006 10:16:34 -0500 (EST) From: Mail Delivery Subsystem Message-Id: <200611041516.kA4FGYJ6018745@dns2-nj.paetec.net> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="kA4FGYJ6018745.1162653394/dns2-nj.paetec.net" Content-Transfer-Encoding: 8bit Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 This is a MIME-encapsulated message --kA4FGYJ6018745.1162653394/dns2-nj.paetec.net The original message was received at Sat, 4 Nov 2006 10:16:28 -0500 (EST) from 63-138-16-2.customer.static.ip.paetec.net [63.138.16.2] (may be forged) ----- The following addresses had permanent fatal errors ----- (reason: 550 : invalid address) ----- Transcript of session follows ----- ... while talking to mx01.1and1.com.: >>> DATA <<< 550 : invalid address 550 5.1.1 ... User unknown <<< 554 no valid recipients --kA4FGYJ6018745.1162653394/dns2-nj.paetec.net Content-Type: message/delivery-status Reporting-MTA: dns; dns2-nj.paetec.net Received-From-MTA: DNS; 63-138-16-2.customer.static.ip.paetec.net Arrival-Date: Sat, 4 Nov 2006 10:16:28 -0500 (EST) Final-Recipient: RFC822; telecom@nilebasin.com Action: failed Status: 5.1.1 Remote-MTA: DNS; mx01.1and1.com Diagnostic-Code: SMTP; 550 : invalid address Last-Attempt-Date: Sat, 4 Nov 2006 10:16:34 -0500 (EST) --kA4FGYJ6018745.1162653394/dns2-nj.paetec.net Content-Type: text/rfc822-headers Content-Transfer-Encoding: 8bit Return-Path: Received: from lists.ietf.org (63-138-16-2.customer.static.ip.paetec.net [63.138.16.2] (may be forged)) by dns2-nj.paetec.net (8.13.6/8.13.6) with ESMTP id kA4FGLJ6018722 for ; Sat, 4 Nov 2006 10:16:28 -0500 (EST) Message-Id: <200611041516.kA4FGLJ6018722@dns2-nj.paetec.net> From: ospf-archive@lists.ietf.org To: telecom@nilebasin.com Subject: Returned mail: see transcript for details Date: Sat, 4 Nov 2006 10:16:59 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_71EADD3B.AE3C192B" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 --kA4FGYJ6018745.1162653394/dns2-nj.paetec.net-- From MAILER-DAEMON Sun Nov 05 09:19:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgiqC-0005E4-9I for ospf-archive@lists.ietf.org; Sun, 05 Nov 2006 09:19:16 -0500 Received: from dns1-la.paetec.net ([64.80.125.114]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggiq9-00051G-UZ for ospf-archive@lists.ietf.org; Sun, 05 Nov 2006 09:19:16 -0500 Received: from localhost (localhost) by dns1-la.paetec.net (8.13.6/8.13.6) id kA5EJDDB010436; Sun, 5 Nov 2006 09:19:13 -0500 (EST) Date: Sun, 5 Nov 2006 09:19:13 -0500 (EST) From: Mail Delivery Subsystem Message-Id: <200611051419.kA5EJDDB010436@dns1-la.paetec.net> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="kA5EJDDB010436.1162736353/dns1-la.paetec.net" Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a MIME-encapsulated message --kA5EJDDB010436.1162736353/dns1-la.paetec.net The original message was received at Sun, 5 Nov 2006 09:18:48 -0500 (EST) from 63-138-16-2.customer.static.ip.paetec.net [63.138.16.2] (may be forged) ----- The following addresses had permanent fatal errors ----- (reason: 554 5.7.1 virus Worm.Mydoom.M detected by ClamAV - http://www.clamav.net) ----- Transcript of session follows ----- ... while talking to mail.mailwatch.com.: >>> DATA <<< 554 5.7.1 virus Worm.Mydoom.M detected by ClamAV - http://www.clamav.net 554 5.0.0 Service unavailable --kA5EJDDB010436.1162736353/dns1-la.paetec.net Content-Type: message/delivery-status Reporting-MTA: dns; dns1-la.paetec.net Received-From-MTA: DNS; 63-138-16-2.customer.static.ip.paetec.net Arrival-Date: Sun, 5 Nov 2006 09:18:48 -0500 (EST) Final-Recipient: RFC822; thaake@visteon.com Action: failed Status: 5.7.1 Remote-MTA: DNS; mail.mailwatch.com Diagnostic-Code: SMTP; 554 5.7.1 virus Worm.Mydoom.M detected by ClamAV - http://www.clamav.net Last-Attempt-Date: Sun, 5 Nov 2006 09:19:13 -0500 (EST) --kA5EJDDB010436.1162736353/dns1-la.paetec.net Content-Type: text/rfc822-headers Return-Path: Received: from lists.ietf.org (63-138-16-2.customer.static.ip.paetec.net [63.138.16.2] (may be forged)) by dns1-la.paetec.net (8.13.6/8.13.6) with ESMTP id kA5EIgDB010418 for ; Sun, 5 Nov 2006 09:18:48 -0500 (EST) Message-Id: <200611051418.kA5EIgDB010418@dns1-la.paetec.net> From: ospf-archive@lists.ietf.org To: thaake@visteon.com Subject: Returned mail: see transcript for details Date: Sun, 5 Nov 2006 09:19:20 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_3D93EF4A.F50AC1F5" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 --kA5EJDDB010436.1162736353/dns1-la.paetec.net-- From MAILER-DAEMON Mon Nov 06 22:36:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHjK-0001r3-N7 for ospf-archive@lists.ietf.org; Mon, 06 Nov 2006 22:34:30 -0500 Received: from spock.sanomabp.hu ([81.0.70.213]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhHgX-0000eE-VN for ospf-archive@lists.ietf.org; Mon, 06 Nov 2006 22:31:39 -0500 Received: by spock.sanomabp.hu (Postfix) id 2AF8619E1A2; Tue, 7 Nov 2006 04:33:55 +0100 (CET) Date: Tue, 7 Nov 2006 04:33:55 +0100 (CET) From: MAILER-DAEMON@spock.sanomabp.hu (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: ospf-archive@lists.ietf.org MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="28F4E19DC73.1162870435/spock.sanomabp.hu" Message-Id: <20061107033355.2AF8619E1A2@spock.sanomabp.hu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac This is a MIME-encapsulated message. --28F4E19DC73.1162870435/spock.sanomabp.hu Content-Description: Notification Content-Type: text/plain This is the Postfix program at host spock.sanomabp.hu. I'm sorry to have to inform you that your message could not be be delivered to one or more recipients. It's attached below. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program : host 127.0.0.1[127.0.0.1] said: 550 5.7.1 Message content rejected, UBE, id=04569-14 (in reply to end of DATA command) --28F4E19DC73.1162870435/spock.sanomabp.hu Content-Description: Delivery report Content-Type: message/delivery-status Reporting-MTA: dns; spock.sanomabp.hu X-Postfix-Queue-ID: 28F4E19DC73 X-Postfix-Sender: rfc822; ospf-archive@lists.ietf.org Arrival-Date: Tue, 7 Nov 2006 04:32:43 +0100 (CET) Final-Recipient: rfc822; a.selmeczi@sanomabp.hu Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host 127.0.0.1[127.0.0.1] said: 550 5.7.1 Message content rejected, UBE, id=04569-14 (in reply to end of DATA command) --28F4E19DC73.1162870435/spock.sanomabp.hu Content-Description: Undelivered Message Content-Type: message/rfc822 Received: from lists.ietf.org (unknown [195.46.1.97]) by spock.sanomabp.hu (Postfix) with ESMTP id 28F4E19DC73 for ; Tue, 7 Nov 2006 04:32:43 +0100 (CET) From: ospf-archive@lists.ietf.org To: a.selmeczi@sanomabp.hu Subject: Date: Tue, 7 Nov 2006 05:32:14 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_A225E455.B3298646" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20061107033243.28F4E19DC73@spock.sanomabp.hu> This is a multi-part message in MIME format. ------=_NextPart_000_0000_A225E455.B3298646 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit *********************** WORM_MYDOOM.GEN was detected in the file (transcript.zip/transcript.pif). The following action has been taken: remove *********************** ------=_NextPart_000_0000_A225E455.B3298646-- --28F4E19DC73.1162870435/spock.sanomabp.hu-- From MAILER-DAEMON Tue Nov 07 19:37:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbS2-0005zv-Qb for ospf-archive@lists.ietf.org; Tue, 07 Nov 2006 19:37:58 -0500 Received: from mail.nepsa.com ([72.51.44.159]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhbS1-0007dX-GI for ospf-archive@lists.ietf.org; Tue, 07 Nov 2006 19:37:58 -0500 Received: (qmail 3278 invoked for bounce); 8 Nov 2006 00:37:46 -0000 Date: 8 Nov 2006 00:37:46 -0000 From: MAILER-DAEMON@bouncehost To: ospf-archive@lists.ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1162946265bouncehost9733183" Subject: failure notice X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 --1162946265bouncehost9733183 Hi. This is the qmail-send program at bouncehost. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : Sorry, only subscribers may post. If you are a subscriber, please forward this message to blkdiamond-owner@nbs.org to get your new address included (#5.7.2) --- Enclosed are the original headers of the message. --1162946265bouncehost9733183 Content-Type: message/rfc822 Return-Path: Received: (qmail 3255 invoked by uid 399); 8 Nov 2006 00:37:33 -0000 Received: from unknown (HELO lists.ietf.org) (202.71.167.194) by mail.nepsa.com with SMTP; 8 Nov 2006 00:37:33 -0000 Received-SPF: none (mail.nepsa.com: domain at lists.ietf.org does not designate permitted sender hosts) identity=mailfrom; client-ip=202.71.167.194; envelope-from=; From: ospf-archive@lists.ietf.org To: blkdiamond@nbs.org Subject: Mail System Error - Returned Mail Date: Wed, 8 Nov 2006 08:37:28 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_0B3D886F.FC93C328" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 (Body supressed) --1162946265bouncehost9733183-- From ospf-bounces@ietf.org Wed Nov 08 16:39:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghv82-0001T7-Co; Wed, 08 Nov 2006 16:38:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghv81-0001P0-1O for ospf@ietf.org; Wed, 08 Nov 2006 16:38:37 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghv7v-0000eE-L1 for ospf@ietf.org; Wed, 08 Nov 2006 16:38:37 -0500 Received: by ug-out-1314.google.com with SMTP id 72so29614ugd for ; Wed, 08 Nov 2006 13:38:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FasfJAqGANeNnH6Z6YZvVcUFuKgl/SZC4Rptv1BXGbs41ONGRQtJXOBL7+eRS62y6rPWkkbUtucA6LhN1EsodJaMqDNCXcPEjoy09XOZo76yjyMtaInfL2oSw1jNlktZrHfUcscOzqPLQO2Kzu144ix/oOM0R+OdhqTcOh6x+a0= Received: by 10.78.157.8 with SMTP id f8mr145802hue.1163021909851; Wed, 08 Nov 2006 13:38:29 -0800 (PST) Received: by 10.78.200.20 with HTTP; Wed, 8 Nov 2006 13:38:29 -0800 (PST) Message-ID: <6e6ce9380611081338s481cc560r73394d12b7a81935@mail.gmail.com> Date: Thu, 9 Nov 2006 03:08:29 +0530 From: "Phil Cowburn" To: ospf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [OSPF] Minutes? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Acee, Can we please have the minutes of the meeting? Phil _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 09 03:21:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi583-0001Lo-BT; Thu, 09 Nov 2006 03:19:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi581-0001Lf-24 for ospf@ietf.org; Thu, 09 Nov 2006 03:19:17 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi57x-0004cb-WA for ospf@ietf.org; Thu, 09 Nov 2006 03:19:17 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8G00ABQFP99N@szxga02-in.huawei.com> for ospf@ietf.org; Thu, 09 Nov 2006 16:31:57 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8G00B8HFP8OL@szxga02-in.huawei.com> for ospf@ietf.org; Thu, 09 Nov 2006 16:31:57 +0800 (CST) Received: from [127.0.0.1] ([10.111.34.184]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8G00MGQF39KZ@szxml03-in.huawei.com> for ospf@ietf.org; Thu, 09 Nov 2006 16:18:48 +0800 (CST) Date: Thu, 09 Nov 2006 16:11:48 +0800 From: "Abhay D.S" To: ospf@ietf.org Message-id: <4552E2C4.8090903@acm.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_yI4IiBjElKq9p/GuLz7jag)" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [OSPF] Extensions to OSPF for Advertising Optional Router Capabilities X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: abhayds@acm.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_yI4IiBjElKq9p/GuLz7jag) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT hi acee, and other neighbors in the AS, 5. Flooding Scope of the Router Information LSA The flooding scope for a Router Information LSA is determined by the LSA type. For OSPFv2, type 9 (link-scoped), type 10 (area-scoped), or a type 11 (AS-scoped) opaque LSA may be flooded. For OSPFv3, the S1 and S2 bits in the LSA type determine flooding scope. If AS wide flooding scope is chosen, the originating router should also advertise area scoped LSA(s) into any attached NSSA area(s). An OSPF router MAY advertise different capabilities when both NSSA area scoped LSA(s) and an AS scoped LSA are advertised. This allows functional capabilities to be limited in scope. For example, a router may be an area border router but only support traffic engineering (TE) in a subset of its attached areas. *The choice of flooding scope is made by the advertising router and is a matter of local policy. *This specification, takes OSPFv2 to new levels of intelligence. Flooding scope MAY also be policed. Such as only a subset of capabilities to be advertised from capability subset in each scope. Such as when a router becomes ASBR, ABR or just an Internal Area Router, GR capable Overloaded, busy for example (if you receive a busy bit) (add to capability set ?). Busy and Free capability might be used by CSPF. ( You might have just edited the new specification for the TE Addresses for all OSPF interfaces). You might read the relation. You might want to add a section, IMPACT: Where in you might add the impact Action: Router shall perform only those actions upon reception of these capability information Any comments , - Abhay --Boundary_(ID_yI4IiBjElKq9p/GuLz7jag) Content-type: text/x-vcard; charset=utf-8; name=abhayds.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=abhayds.vcf begin:vcard fn:Abhay Rao n:Rao;Abhay email;internet:abhayds@acm.org version:2.1 end:vcard --Boundary_(ID_yI4IiBjElKq9p/GuLz7jag) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --Boundary_(ID_yI4IiBjElKq9p/GuLz7jag)-- From ospf-bounces@ietf.org Fri Nov 10 04:55:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiT45-0002Ng-Vo; Fri, 10 Nov 2006 04:52:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiT44-0002Nb-Rz for ospf@ietf.org; Fri, 10 Nov 2006 04:52:48 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiT41-00050G-B3 for ospf@ietf.org; Fri, 10 Nov 2006 04:52:46 -0500 X-VirusChecked: Checked X-Env-Sender: amirkhan@motorola.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1163152355!7394858!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.7] Received: (qmail 27284 invoked from network); 10 Nov 2006 09:52:35 -0000 Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-10.tower-128.messagelabs.com with SMTP; 10 Nov 2006 09:52:35 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id kAA9qXng001664 for ; Fri, 10 Nov 2006 02:52:35 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id kAA9qVxJ016242 for ; Fri, 10 Nov 2006 03:52:32 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [OSPF] OSPF GR query Date: Fri, 10 Nov 2006 17:52:17 +0800 Message-ID: <988EE2C769AC284ABAE9328BFC10703F01383B23@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF GR query Thread-Index: Acbofzo03VIFl44LRamn1tmNckH5FgcK/YXw From: "Khan Amir-G20247" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0523372143==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============0523372143== Content-class: urn:content-classes:message Content-Type: multipart/related; boundary="----_=_NextPart_001_01C704AD.EA2AE6C2"; type="multipart/alternative" This is a multi-part message in MIME format. ------_=_NextPart_001_01C704AD.EA2AE6C2 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C704AD.EA2AE6C2" ------_=_NextPart_002_01C704AD.EA2AE6C2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi=20 I have query related to OSPF Graceful Restart.=20 =20 Consider this scenario:=20 =20 - Three Routers R1, R2 and R3 connected via Broadcast networks.=20 =20 =20 =20 - Where R1 is a DR on both the segments, where as R2 and R3 are in DR-other - Now R1 wants to perform GR, R2 and R3 agrees to be its Helpers.=20 - Now after restart R1 will try to form adjacency with both R2 and R3.=20 - Lets say R1 and R2 had become FULL, while R1 and R3 had reached Exstart state. Now at this time(when R1 and R3 are in transition state) the adjacency between R1 and R2 goes down for some reson. =20 =20 Considering above scenario, my doubts are:=20 - As the adjacency between R1 and R2 has gone down(which is a Topology change) and R1 is still in GR mode, can R1 quit GR ? In general can a NBR which was FULL and then later gone down can be treated as one of the conditions for quiting GR ?=20 =20 =20 Regards=20 Aamir=20 =20 ------_=_NextPart_002_01C704AD.EA2AE6C2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20

I have = query related=20 to OSPF Graceful Restart.

 

 Consider this = scenario:

 

- Three = Routers R1,=20 R2 and R3 connected via Broadcast networks.

 

 

- Where R1 = is a DR on=20 both the segments, where as R2 and R3 are in = DR-other
- Now R1 = wants to=20 perform GR, R2 and R3 agrees to be its Helpers.
- Now after = restart=20 R1 will try to form adjacency with both R2 and R3. =
-=20 Lets say R1 and R2  had become FULL, while = R1 and R3=20 had reached Exstart state. Now at this time(when R1 and R3 are in transition state) the = adjacency=20 between R1 and  R2  goes down = for=20 some reson.  
 
 Considering above scenario, my = doubts=20 are:

-  As the = adjacency=20 between R1 and R2 has gone down(which is a Topology change) and R1 is = still in=20 GR mode, can R1 quit GR ? In general can a NBR which was = FULL and=20 then later gone down can be treated as one of the conditions = for=20 quiting GR ? 
 

 

Regards=20
Aamir=20

 

------_=_NextPart_002_01C704AD.EA2AE6C2-- ------_=_NextPart_001_01C704AD.EA2AE6C2 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhyAH8AHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALBMAEQCw AcwAgQAAAAAAAP///wECAwL/hI+py+0Po5y0Whqy3rz7D4baRZbmiabqyrbuCx+iJtT2jef6zvf2 nIkJh8Si8YhMJj6+pvMJjeI+yqr1is1qFSCp9wsO60DbsvmMLnvE7Lb77UnL5/R6hPPO6/ftjv0P GHjUwVdoePjFIbjI2AhBiBgpOenk53iJKbdBydnp2bORKTpqhPd5ipoqoEja6nqxqSo7ixr6eosL YErL2/vJmhu8SONbbFwbJKycFnvs/NxpuzytRAx9jc05Qs0N05wNHh4p3V0OmyGerj65be7uYL0u P1/Y/v4eT6+/n2d/v5yPn8CBbPz9cxWQoMKFiZIdFJWQocSJUAw+BISOosaN/14cXqwTkaPIkTks ftSSkaTKlTw8nrwSkqXMlSZfDkk5M6fOHwFslgqwM6jQVT19vog5NOnImkYr4FQKVafLphiARr0q dCpVeFaxeg2qdSuCp1/L5gxLlazZtTPRvlTLNq5Mtwfhyr3Lkq67rnj77ix60a7fwST1KhNMOPFS wOX4Kn7ctrFjyJRpMg6GuLLmjYYvTd4MWuVlUplDm57YGePp1ZFHfWYNm3Om0rFrE0x95rXt3aiH 6eYNfCFumMGLL7Xz27jygaPNJF8OfV9zlNGr93b+3Lr2dcO9bf/OcPog8OQViieSvbx6cOdjpF8P /1p7F+/j23c2f0X9+/yL5f9HsV9/AvLyXwkBDoigLAVacGCCDtbi3YMSQrPgBA1OiCE7LVyYYYeI VAiPhyL6lwKHI564B4hLoMgiLSrK0GKMqbyoi4w2nqKiiTfu2BGDmul4GpBXVSgkVEVudqSRGICW ZGVNJlXgk1mRJ+VQ+VUJFpWrzYflX1oG+UCXQIzZhXwUkonmN/hhk2abXdZwHpZisvnMnGZSOI6G DNh5yJt91JnnnYB+SMl0fBriZ0GD9kknnoTquWKgjApqzKFrOjoppDBKimijx1j6KaX1aMOFJKBW uminoqL6qKY1msrppaG2muqsmWrq56n+1cpHomL4CoauiI7FTqy2snqrrMr/jkqqAYkK2wuwUkBL 4KopelLUs8Yiyy2zmC7bK7bOFjqOm+aeK20Uc6arrrV6SJstubSCG22g6N47prtw7kLUc/C+WmxL /CK1iqfdhqtvtaDcYFVXyaVLmxsPMwznDz6wOy2vU/Bb8MUGHzsGxVN4jK2vE1s88sIJK9gEXw77 +/HBKVc88w4Qm0wyzSir/O2uOXesc0sx+yxwQDCXrM3FamaGcbv01uxyy0P7cvJnR0eDs8qvndwz 1S0vLfXKs3DtWHY3J82z1T8/7WLYk12tsddpi8y1NlkLHfTONk/dds5lh9010WOkhA7HJf1y9+Av 9ws322MD/vfaIMv8LuJo/yc7eb2gEN4wYk1XJLaiSMuLeaX4nh7CvJ9+DriqWF/uetx9l74r6rZD QvuHiXsr++OqU6557n3ujnDgCgt/vOMSW0567MqrQu3sz4v+evO8T1/LtoJnXvnoASMv/fbF9x7+ +IUSf23o2f8ufvvdV/+989yXn77xwctvKvrvkw+99nLzTz1SaYt9/wMeHPiWvOuZalzxU6ABWUbA +83vgNFgYP5utwb14QiDGbQfgTiIu0JZcEtfig1gWLeUErKGMSgUSQux8kIXEmuFKtxSpIJUQ9OM JoY82tEOewhEBS2Ah0FkkaGKiMRmDTGJTOxTiJoIxXeFKYpULMgjqojFRP/cIYtcrIQEiNhF+0Qp jGScglPKWEYQgRGN28kRG7lIozW+UTk0Atgcm1hHO96xiHkc4R572MdN/ZFHgZzhIG1USEMeMkaJ VOQiT9TIGz5SRJEs1SQ9VMklXhJDmdzTJiXUyQbI8ZNsCeUTSckfU04RlWLMwihZqRRVfvGVsJSK LJdUS+vc0ke5hM4uYdFLOiInmMH5pQkiRkzFdAcLtEymQIypH2fqEBPIlKZZlomGZlqTPQjR5jbx A80iePObVBNGNck5l3BWY5zo/EVj2hlLdbqSnfBElDzVQM96wuGe2dRnYXxyTn+mA5vTCKhA5cPP QBj0oP5JKCMWWhYp5ZP/IwR9CERh2KuL/sihrpkooJ7k0fBwtJuPAQpIl1NRsRDsKyYdWUbiEZOQ 8oMpYnGKTPunM2s4LKd4201Ka7qnm+JIby5bmm6Eqo6fApUrSD0fTEW2MaAdDjY0Xap+mjqvneqN p3vb0kiNolGKRE6qWu1cT5n01a2stDA6DWFbTWq1sBpJqVZVwVoZuq+01nUsciVmVfe6hbtu86+A zWZfH0nYwtJBsKRMrGIxctgwOvaxD2UsGslBWYBEFoiTzewr1ERGzHq2LpvtUGdH2w3DAVK0qFWp ZR3E2tYCVrUPAoZsb6uL1+rytLh9bAi/Y4neCtdCtLWNbYeLXAOBFq2xLU2uc0/QQb/E4bnUHQQT 4jnd6moXn79FTXa3C16FAuFMMwiveTULwtOdNwsFAAA7 ------_=_NextPart_001_01C704AD.EA2AE6C2-- --===============0523372143== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0523372143==-- From ospf-bounces@ietf.org Fri Nov 10 05:24:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiTYa-00006G-Qd; Fri, 10 Nov 2006 05:24:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiTYZ-0008Tj-QM for ospf@ietf.org; Fri, 10 Nov 2006 05:24:19 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiTOB-0006c7-06 for ospf@ietf.org; Fri, 10 Nov 2006 05:13:37 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8I00BD4F8AC5@szxga01-in.huawei.com> for ospf@ietf.org; Fri, 10 Nov 2006 18:16:58 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8I009G3F89LN@szxga01-in.huawei.com> for ospf@ietf.org; Fri, 10 Nov 2006 18:16:58 +0800 (CST) Received: from [127.0.0.1] ([10.111.34.184]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8I006YUFB4VW@szxml03-in.huawei.com> for ospf@ietf.org; Fri, 10 Nov 2006 18:18:48 +0800 (CST) Date: Fri, 10 Nov 2006 18:11:40 +0800 From: "Abhay D.S" Subject: Re: [OSPF] OSPF GR query In-reply-to: <988EE2C769AC284ABAE9328BFC10703F01383B23@ZMY16EXM66.ds.mot.com> To: Khan Amir-G20247 Message-id: <4554505C.4040903@acm.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_GIgVtxJYT8uVASQOs+A51A)" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) References: <988EE2C769AC284ABAE9328BFC10703F01383B23@ZMY16EXM66.ds.mot.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: abhayds@acm.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_GIgVtxJYT8uVASQOs+A51A) Content-type: multipart/alternative; boundary="Boundary_(ID_MOwFCo7Hj1Tu7vqlafIWOw)" --Boundary_(ID_MOwFCo7Hj1Tu7vqlafIWOw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT dear amir, There is nothing called as Quitting GR. In the case below , the most desirable thing is to give a message or an SNMP trap for qualifying to a quit scenario. There is a thin line between completion and quitting GR. Just imagine this happens when the last router was about to be full and re-starter was just about the originate old router LSA , perfectly as the old one and then this event happened ? Would you quit GR or log a message. Another is what is your idea of quit GR ?. Thanks, Abhay Khan Amir-G20247 wrote: > Hi > > I have query related to OSPF Graceful Restart. > > > > Consider this scenario: > > > > - Three Routers R1, R2 and R3 connected via Broadcast networks. > > > > > > - Where R1 is a DR on both the segments, where as R2 and R3 are in > DR-other > - Now R1 wants to perform GR, R2 and R3 agrees to be its Helpers. > - Now after restart R1 will try to form adjacency with both R2 and R3. > - Lets say R1 and R2 had become FULL, while R1 and R3 had reached > Exstart state. Now at this time(when R1 and R3 are in transition > state) the adjacency between R1 and R2 goes down for some reson. > > Considering above scenario, my doubts are: > > - As the adjacency between R1 and R2 has gone down(which is a > Topology change) and R1 is still in GR mode, can R1 quit GR ? In > general can a NBR which was FULL and then later gone down can be > treated as one of the conditions for quiting GR ? > > > > > Regards > Aamir > > > > ------------------------------------------------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > --Boundary_(ID_MOwFCo7Hj1Tu7vqlafIWOw) Content-type: multipart/related; boundary="Boundary_(ID_Z/eo0YGZQs5czrCfTxi3jg)" --Boundary_(ID_Z/eo0YGZQs5czrCfTxi3jg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT dear amir,
There is nothing called as Quitting GR.

In the case below , the most desirable thing is to give a message or an SNMP trap for qualifying to a quit scenario.

There is a thin line between completion and quitting GR. Just imagine this happens when the last router was about to be
full and  re-starter was  just about the originate  old router LSA , perfectly as the old one and then this event happened ?

Would you quit GR or log a message.

Another is what is your idea of quit GR  ?.

Thanks,

Abhay



Khan Amir-G20247 wrote:
Hi

I have query related to OSPF Graceful Restart.

 

 Consider this scenario:

 

- Three Routers R1, R2 and R3 connected via Broadcast networks.

 

 

- Where R1 is a DR on both the segments, where as R2 and R3 are in DR-other
- Now R1 wants to perform GR, R2 and R3 agrees to be its Helpers.
- Now after restart R1 will try to form adjacency with both R2 and R3.
- Lets say R1 and R2  had become FULL, while R1 and R3 had reached Exstart state. Now at this time(when R1 and R3 are in transition state) the adjacency between R1 and  R2  goes down for some reson.  
 
 Considering above scenario, my doubts are:

-  As the adjacency between R1 and R2 has gone down(which is a Topology change) and R1 is still in GR mode, can R1 quit GR ? In general can a NBR which was FULL and then later gone down can be treated as one of the conditions for quiting GR ? 
 

 

Regards
Aamir

 


_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf
--Boundary_(ID_Z/eo0YGZQs5czrCfTxi3jg) Content-id: Content-type: image/gif Content-transfer-encoding: base64 R0lGODlhyAH8AHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALBMA EQCwAcwAgQAAAAAAAP///wECAwL/hI+py+0Po5y0Whqy3rz7D4baRZbmiabqyrbuCx+iJtT2 jef6zvf2nIkJh8Si8YhMJj6+pvMJjeI+yqr1is1qFSCp9wsO60DbsvmMLnvE7Lb77UnL5/R6 hPPO6/ftjv0PGHjUwVdoePjFIbjI2AhBiBgpOenk53iJKbdBydnp2bORKTpqhPd5ipoqoEja 6nqxqSo7ixr6eosLYErL2/vJmhu8SONbbFwbJKycFnvs/NxpuzytRAx9jc05Qs0N05wNHh4p 3V0OmyGerj65be7uYL0uP1/Y/v4eT6+/n2d/v5yPn8CBbPz9cxWQoMKFiZIdFJWQocSJUAw+ BISOosaN/14cXqwTkaPIkTksftSSkaTKlTw8nrwSkqXMlSZfDkk5M6fOHwFslgqwM6jQVT19 vog5NOnImkYr4FQKVafLphiARr0qdCpVeFaxeg2qdSuCp1/L5gxLlazZtTPRvlTLNq5Mtwfh yr3Lkq67rnj77ix60a7fwST1KhNMOPFSwOX4Kn7ctrFjyJRpMg6GuLLmjYYvTd4MWuVlUplD m57YGePp1ZFHfWYNm3Om0rFrE0x95rXt3aiH6eYNfCFumMGLL7Xz27jygaPNJF8OfV9zlNGr 93b+3Lr2dcO9bf/OcPog8OQViieSvbx6cOdjpF8P/1p7F+/j23c2f0X9+/yL5f9HsV9/AvLy XwkBDoigLAVacGCCDtbi3YMSQrPgBA1OiCE7LVyYYYeIVAiPhyL6lwKHI564B4hLoMgiLSrK 0GKMqbyoi4w2nqKiiTfu2BGDmul4GpBXVSgkVEVudqSRGICWZGVNJlXgk1mRJ+VQ+VUJFpWr zYflX1oG+UCXQIzZhXwUkonmN/hhk2abXdZwHpZisvnMnGZSOI6GDNh5yJt91JnnnYB+SMl0 fBriZ0GD9kknnoTquWKgjApqzKFrOjoppDBKimijx1j6KaX1aMOFJKBWuminoqL6qKY1msrp paG2muqsmWrq56n+1cpHomL4CoauiI7FTqy2snqrrMr/jkqqAYkK2wuwUkBL4KopelLUs8Yi yy2zmC7bK7bOFjqOm+aeK20Uc6arrrV6SJstubSCG22g6N47prtw7kLUc/C+WmxL/CK1iqfd hqtvtaDcYFVXyaVLmxsPMwznDz6wOy2vU/Bb8MUGHzsGxVN4jK2vE1s88sIJK9gEXw77+/HB KVc88w4Qm0wyzSir/O2uOXesc0sx+yxwQDCXrM3FamaGcbv01uxyy0P7cvJnR0eDs8qvndwz 1S0vLfXKs3DtWHY3J82z1T8/7WLYk12tsddpi8y1NlkLHfTONk/dds5lh9010WOkhA7HJf1y 9+Av9ws322MD/vfaIMv8LuJo/yc7eb2gEN4wYk1XJLaiSMuLeaX4nh7CvJ9+DriqWF/uetx9 l74r6rZDQvuHiXsr++OqU6557n3ujnDgCgt/vOMSW0567MqrQu3sz4v+evO8T1/LtoJnXvno ASMv/fbF9x7++IUSf23o2f8ufvvdV/+989yXn77xwctvKvrvkw+99nLzTz1SaYt9/wMeHPiW vOuZalzxU6ABWUbA+83vgNFgYP5utwb14QiDGbQfgTiIu0JZcEtfig1gWLeUErKGMSgUSQux 8kIXEmuFKtxSpIJUQ9OMJoY82tEOewhEBS2Ah0FkkaGKiMRmDTGJTOxTiJoIxXeFKYpULMgj qojFRP/cIYtcrIQEiNhF+0QpjGScglPKWEYQgRGN28kRG7lIozW+UTk0Atgcm1hHO96xiHkc 4R572MdN/ZFHgZzhIG1USEMeMkaJVOQiT9TIGz5SRJEs1SQ9VMklXhJDmdzTJiXUyQbI8ZNs CeUTSckfU04RlWLMwihZqRRVfvGVsJSKLJdUS+vc0ke5hM4uYdFLOiInmMH5pQkiRkzFdAcL tEymQIypH2fqEBPIlKZZlomGZlqTPQjR5jbxA80iePObVBNGNck5l3BWY5zo/EVj2hlLdbqS nfBElDzVQM96wuGe2dRnYXxyTn+mA5vTCKhA5cPPQBj0oP5JKCMWWhYp5ZP/IwR9CERh2KuL /sihrpkooJ7k0fBwtJuPAQpIl1NRsRDsKyYdWUbiEZOQ8oMpYnGKTPunM2s4LKd4201Ka7qn m+JIby5bmm6Eqo6fApUrSD0fTEW2MaAdDjY0Xap+mjqvneqNp3vb0kiNolGKRE6qWu1cT5n0 1a2stDA6DWFbTWq1sBpJqVZVwVoZuq+01nUsciVmVfe6hbtu86+AzWZfH0nYwtJBsKRMrGIx ctgwOvaxD2UsGslBWYBEFoiTzewr1ERGzHq2LpvtUGdH2w3DAVK0qFWpZR3E2tYCVrUPAoZs b6uL1+rytLh9bAi/Y4neCtdCtLWNbYeLXAOBFq2xLU2uc0/QQb/E4bnUHQQT4jnd6moXn79F TXa3C16FAuFMMwiveTULwtOdNwsFAAA7 --Boundary_(ID_Z/eo0YGZQs5czrCfTxi3jg)-- --Boundary_(ID_MOwFCo7Hj1Tu7vqlafIWOw)-- --Boundary_(ID_GIgVtxJYT8uVASQOs+A51A) Content-type: text/x-vcard; charset=utf-8; name=abhayds.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=abhayds.vcf begin:vcard fn:Abhay Rao n:Rao;Abhay email;internet:abhayds@acm.org version:2.1 end:vcard --Boundary_(ID_GIgVtxJYT8uVASQOs+A51A) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --Boundary_(ID_GIgVtxJYT8uVASQOs+A51A)-- From ospf-bounces@ietf.org Sat Nov 11 16:17:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj0BV-0007gA-HL; Sat, 11 Nov 2006 16:14:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj0BT-0007fy-M8 for ospf@ietf.org; Sat, 11 Nov 2006 16:14:39 -0500 Received: from wx-out-0506.google.com ([66.249.82.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj0BR-0002x2-6L for ospf@ietf.org; Sat, 11 Nov 2006 16:14:39 -0500 Received: by wx-out-0506.google.com with SMTP id h29so874416wxd for ; Sat, 11 Nov 2006 13:14:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=rD8DvJIy6/l2gZixbCcA+MC9zhf01gVpT3FCm2dsRFN8GbGcVHksEn3DKPMEwscR/ET0SFgFvxsr2UBa+HY9dkiLM4J6//hBuz8YShPtIVrRMWLUyS/CsYzZQWZVw1zVvFRDfd94wKVC3tuviIEDUaYJSQZdi2nYtWwOtvdyi4g= Received: by 10.90.92.7 with SMTP id p7mr2471487agb.1163279676700; Sat, 11 Nov 2006 13:14:36 -0800 (PST) Received: by 10.90.31.17 with HTTP; Sat, 11 Nov 2006 13:14:36 -0800 (PST) Message-ID: Date: Sun, 12 Nov 2006 02:44:36 +0530 From: "sujay gupta" To: abhayds@acm.org, "Khan Amir-G20247" Subject: Re: [OSPF] OSPF GR query In-Reply-To: <4554505C.4040903@acm.org> MIME-Version: 1.0 References: <988EE2C769AC284ABAE9328BFC10703F01383B23@ZMY16EXM66.ds.mot.com> <4554505C.4040903@acm.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1739933509==" Errors-To: ospf-bounces@ietf.org --===============1739933509== Content-Type: multipart/related; boundary="----=_Part_99004_10082417.1163279676596" ------=_Part_99004_10082417.1163279676596 Content-Type: multipart/alternative; boundary="----=_Part_99003_3168975.1163279676596" ------=_Part_99003_3168975.1163279676596 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Amir, Adding ; If the link between R1-R2 toggles making the adjacency going down and then come up.R1 should exit GR. R2 should exit helper mode send an inconsistent LSA to R1, R1 on examining this LSA should exit GR. Or; alternately R1 could detect a Nbr Down event and immediately exit GR. Regds, -Sujay ( Ref http://tools.ietf.org/wg/ospf/draft-holla-ospf-update-graceful-restart-02.txtSection 3.2.1(1)) On 11/10/06, Abhay D.S wrote: > > dear amir, > There is nothing called as Quitting GR. > > In the case below , the most desirable thing is to give a message or an > SNMP trap for qualifying to a quit scenario. > > There is a thin line between completion and quitting GR. Just imagine this > happens when the last router was about to be > full and re-starter was just about the originate old router LSA , > perfectly as the old one and then this event happened ? > > Would you quit GR or log a message. > > Another is what is your idea of quit GR ?. > > Thanks, > > Abhay > > > > Khan Amir-G20247 wrote: > > Hi > > I have query related to OSPF Graceful Restart. > > > > Consider this scenario: > > > > - Three Routers R1, R2 and R3 connected via Broadcast networks. > > > > > > - Where R1 is a DR on both the segments, where as R2 and R3 are in > DR-other > - Now R1 wants to perform GR, R2 and R3 agrees to be its Helpers. > - Now after restart R1 will try to form adjacency with both R2 and R3. > - Lets say R1 and R2 had become FULL, while R1 and R3 had reached Exstart > state. Now at this time(when R1 and R3 are in transition state) the > adjacency between R1 and R2 goes down for some reson. > > Considering above scenario, my doubts are: > > - As the adjacency between R1 and R2 has gone down(which is a Topology > change) and R1 is still in GR mode, can R1 quit GR ? In general can a NBR > which was FULL and then later gone down can be treated as one of the > conditions for quiting GR ? > > > > > Regards > Aamir > > > > ------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.orghttps://www1.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > > > ------=_Part_99003_3168975.1163279676596 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Amir,
Adding  ;

If the link between R1-R2 toggles making the adjacency going down and then come up.R1 should exit GR.
R2  should exit  helper  mode send an inconsistent LSA to R1, R1 on examining this LSA should exit GR.
Or; alternately R1 could detect a Nbr Down event and immediately exit GR.

Regds,
-Sujay
( Ref http://tools.ietf.org/wg/ospf/draft-holla-ospf-update-graceful-restart-02.txt Section 3.2.1(1))



On 11/10/06, Abhay D.S <abhayds@acm.org> wrote:
dear amir,
There is nothing called as Quitting GR.

In the case below , the most desirable thing is to give a message or an SNMP trap for qualifying to a quit scenario.

There is a thin line between completion and quitting GR. Just imagine this happens when the last router was about to be
full and  re-starter was  just about the originate  old router LSA , perfectly as the old one and then this event happened ?

Would you quit GR or log a message.

Another is what is your idea of quit GR  ?.

Thanks,

Abhay



Khan Amir-G20247 wrote:
Hi

I have query related to OSPF Graceful Restart.

 

 Consider this scenario:

 

- Three Routers R1, R2 and R3 connected via Broadcast networks.

 

 

- Where R1 is a DR on both the segments, where as R2 and R3 are in DR-other
- Now R1 wants to perform GR, R2 and R3 agrees to be its Helpers.
- Now after restart R1 will try to form adjacency with both R2 and R3.
- Lets say R1 and R2  had become FULL, while R1 and R3 had reached Exstart state. Now at this time(when R1 and R3 are in transition state) the adjacency between R1 and  R2  goes down for some reson.  
 
 Considering above scenario, my doubts are:

-  As the adjacency between R1 and R2 has gone down(which is a Topology change) and R1 is still in GR mode, can R1 quit GR ? In general can a NBR which was FULL and then later gone down can be treated as one of the conditions for quiting GR ? 
 

 

Regards
Aamir

 


_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf




------=_Part_99003_3168975.1163279676596-- ------=_Part_99004_10082417.1163279676596 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 0.0.1.1 Content-Disposition: inline R0lGODlhyAH8AHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALBMAEQCw AcwAgQAAAAAAAP///wECAwL/hI+py+0Po5y0Whqy3rz7D4baRZbmiabqyrbuCx+iJtT2jef6zvf2 nIkJh8Si8YhMJj6+pvMJjeI+yqr1is1qFSCp9wsO60DbsvmMLnvE7Lb77UnL5/R6hPPO6/ftjv0P GHjUwVdoePjFIbjI2AhBiBgpOenk53iJKbdBydnp2bORKTpqhPd5ipoqoEja6nqxqSo7ixr6eosL YErL2/vJmhu8SONbbFwbJKycFnvs/NxpuzytRAx9jc05Qs0N05wNHh4p3V0OmyGerj65be7uYL0u P1/Y/v4eT6+/n2d/v5yPn8CBbPz9cxWQoMKFiZIdFJWQocSJUAw+BISOosaN/14cXqwTkaPIkTks ftSSkaTKlTw8nrwSkqXMlSZfDkk5M6fOHwFslgqwM6jQVT19vog5NOnImkYr4FQKVafLphiARr0q dCpVeFaxeg2qdSuCp1/L5gxLlazZtTPRvlTLNq5Mtwfhyr3Lkq67rnj77ix60a7fwST1KhNMOPFS wOX4Kn7ctrFjyJRpMg6GuLLmjYYvTd4MWuVlUplDm57YGePp1ZFHfWYNm3Om0rFrE0x95rXt3aiH 6eYNfCFumMGLL7Xz27jygaPNJF8OfV9zlNGr93b+3Lr2dcO9bf/OcPog8OQViieSvbx6cOdjpF8P /1p7F+/j23c2f0X9+/yL5f9HsV9/AvLyXwkBDoigLAVacGCCDtbi3YMSQrPgBA1OiCE7LVyYYYeI VAiPhyL6lwKHI564B4hLoMgiLSrK0GKMqbyoi4w2nqKiiTfu2BGDmul4GpBXVSgkVEVudqSRGICW ZGVNJlXgk1mRJ+VQ+VUJFpWrzYflX1oG+UCXQIzZhXwUkonmN/hhk2abXdZwHpZisvnMnGZSOI6G DNh5yJt91JnnnYB+SMl0fBriZ0GD9kknnoTquWKgjApqzKFrOjoppDBKimijx1j6KaX1aMOFJKBW uminoqL6qKY1msrppaG2muqsmWrq56n+1cpHomL4CoauiI7FTqy2snqrrMr/jkqqAYkK2wuwUkBL 4KopelLUs8Yiyy2zmC7bK7bOFjqOm+aeK20Uc6arrrV6SJstubSCG22g6N47prtw7kLUc/C+WmxL /CK1iqfdhqtvtaDcYFVXyaVLmxsPMwznDz6wOy2vU/Bb8MUGHzsGxVN4jK2vE1s88sIJK9gEXw77 +/HBKVc88w4Qm0wyzSir/O2uOXesc0sx+yxwQDCXrM3FamaGcbv01uxyy0P7cvJnR0eDs8qvndwz 1S0vLfXKs3DtWHY3J82z1T8/7WLYk12tsddpi8y1NlkLHfTONk/dds5lh9010WOkhA7HJf1y9+Av 9ws322MD/vfaIMv8LuJo/yc7eb2gEN4wYk1XJLaiSMuLeaX4nh7CvJ9+DriqWF/uetx9l74r6rZD QvuHiXsr++OqU6557n3ujnDgCgt/vOMSW0567MqrQu3sz4v+evO8T1/LtoJnXvnoASMv/fbF9x7+ +IUSf23o2f8ufvvdV/+989yXn77xwctvKvrvkw+99nLzTz1SaYt9/wMeHPiWvOuZalzxU6ABWUbA +83vgNFgYP5utwb14QiDGbQfgTiIu0JZcEtfig1gWLeUErKGMSgUSQux8kIXEmuFKtxSpIJUQ9OM JoY82tEOewhEBS2Ah0FkkaGKiMRmDTGJTOxTiJoIxXeFKYpULMgjqojFRP/cIYtcrIQEiNhF+0Qp jGScglPKWEYQgRGN28kRG7lIozW+UTk0Atgcm1hHO96xiHkc4R572MdN/ZFHgZzhIG1USEMeMkaJ VOQiT9TIGz5SRJEs1SQ9VMklXhJDmdzTJiXUyQbI8ZNsCeUTSckfU04RlWLMwihZqRRVfvGVsJSK LJdUS+vc0ke5hM4uYdFLOiInmMH5pQkiRkzFdAcLtEymQIypH2fqEBPIlKZZlomGZlqTPQjR5jbx A80iePObVBNGNck5l3BWY5zo/EVj2hlLdbqSnfBElDzVQM96wuGe2dRnYXxyTn+mA5vTCKhA5cPP QBj0oP5JKCMWWhYp5ZP/IwR9CERh2KuL/sihrpkooJ7k0fBwtJuPAQpIl1NRsRDsKyYdWUbiEZOQ 8oMpYnGKTPunM2s4LKd4201Ka7qnm+JIby5bmm6Eqo6fApUrSD0fTEW2MaAdDjY0Xap+mjqvneqN p3vb0kiNolGKRE6qWu1cT5n01a2stDA6DWFbTWq1sBpJqVZVwVoZuq+01nUsciVmVfe6hbtu86+A zWZfH0nYwtJBsKRMrGIxctgwOvaxD2UsGslBWYBEFoiTzewr1ERGzHq2LpvtUGdH2w3DAVK0qFWp ZR3E2tYCVrUPAoZsb6uL1+rytLh9bAi/Y4neCtdCtLWNbYeLXAOBFq2xLU2uc0/QQb/E4bnUHQQT 4jnd6moXn79FTXa3C16FAuFMMwiveTULwtOdNwsFAAA7 ------=_Part_99004_10082417.1163279676596-- --===============1739933509== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1739933509==-- From ospf-bounces@ietf.org Sun Nov 12 04:26:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBYv-0002Nc-PY; Sun, 12 Nov 2006 04:23:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBYu-0002K5-8a for ospf@ietf.org; Sun, 12 Nov 2006 04:23:36 -0500 Received: from [202.54.124.151] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjBYn-00045l-Vf for ospf@ietf.org; Sun, 12 Nov 2006 04:23:36 -0500 Received: (qmail 25007 invoked by uid 510); 12 Nov 2006 09:20:01 -0000 Date: 12 Nov 2006 09:20:01 -0000 Message-ID: <20061112092001.25006.qmail@webmail6.rediffmail.com> Received: from unknown (202.53.8.25) by rediffmail.com via HTTP; 12 nov 2006 09:20:01 -0000 MIME-Version: 1.0 From: "Vivek Dubey" To: ospf@ietf.org Subject: Re: [OSPF] OSPF GR query X-Spam-Score: 2.9 (++) X-Scan-Signature: 2086112c730e13d5955355df27e3074b X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vivek Dubey List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0892703089==" Errors-To: ospf-bounces@ietf.org This is a multipart mime message --===============0892703089== Content-type: multipart/alternative; boundary="Next_1163323201---0-202.54.124.151-25003" This is a multipart mime message --Next_1163323201---0-202.54.124.151-25003 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Sujay,=0AI understand the reason for suggesting that a change in nbr fsm= state at "restarting router" to be taken as a topology change, and thereb= y exiting GR, hence the extension draft.=0A=0ABut on another note, taking i= nto account default values (rtr dead interval 40sec and grace period 120se= c), if a helper fsm state at restarting router toggles from up-->down-->up = within grace period, should we immediately declare that as topology change?= Or let GR try be successful until GR period expires?=0A=0AThanks=0AVivek= =0A=0A=0A=0AOn Sun, 12 Nov 2006 sujay gupta wrote :=0A>Hi Amir,=0A>Adding = ;=0A>=0A>If the link between R1-R2 toggles making the adjacency going down = and then=0A>come up.R1 should exit GR.=0A>R2 should exit helper mode sen= d an inconsistent LSA to R1, R1 on=0A>examining this LSA should exit GR.=0A= >Or; alternately R1 could detect a Nbr Down event and immediately exit GR.= =0A>=0A>Regds,=0A>-Sujay=0A>( Ref=0A>http://tools.ietf.org/wg/ospf/draft-ho= lla-ospf-update-graceful-restart-02.txtSection=0A>3.2.1(1))=0A>=0A>=0A>=0A>= On 11/10/06, Abhay D.S wrote:=0A>>=0A>> dear amir,=0A>>T= here is nothing called as Quitting GR.=0A>>=0A>>In the case below , the mos= t desirable thing is to give a message or an=0A>>SNMP trap for qualifying t= o a quit scenario.=0A>>=0A>>There is a thin line between completion and qui= tting GR. Just imagine this=0A>>happens when the last router was about to b= e=0A>>full and re-starter was just about the originate old router LSA ,= =0A>>perfectly as the old one and then this event happened ?=0A>>=0A>>Would= you quit GR or log a message.=0A>>=0A>>Another is what is your idea of qui= t GR ?.=0A>>=0A>>Thanks,=0A>>=0A>>Abhay=0A>>=0A>>=0A>>=0A>>Khan Amir-G2024= 7 wrote:=0A>>=0A>>Hi=0A>>=0A>>I have query related to OSPF Graceful Restart= .=0A>>=0A>>=0A>>=0A>> Consider this scenario:=0A>>=0A>>=0A>>=0A>>- Three R= outers R1, R2 and R3 connected via Broadcast networks.=0A>>=0A>>=0A>>=0A>>= =0A>>=0A>>- Where R1 is a DR on both the segments, where as R2 and R3 are i= n=0A>>DR-other=0A>>- Now R1 wants to perform GR, R2 and R3 agrees to be its= Helpers.=0A>>- Now after restart R1 will try to form adjacency with both R= 2 and R3.=0A>>- Lets say R1 and R2 had become FULL, while R1 and R3 had re= ached Exstart=0A>>state. Now at this time(when R1 and R3 are in transition = state) the=0A>>adjacency between R1 and R2 goes down for some reson.=0A>>= =0A>> Considering above scenario, my doubts are:=0A>>=0A>>- As the adjace= ncy between R1 and R2 has gone down(which is a Topology=0A>>change) and R1 = is still in GR mode, can R1 quit GR ? In general can a NBR=0A>>which was FU= LL and then later gone down can be treated as one of the=0A>>conditions for= quiting GR ?=0A>>=0A>>=0A>>=0A>>=0A>>Regards=0A>>Aamir=0A>>=0A>>=0A>>=0A>>= ------------------------------=0A>>=0A>>___________________________________= ____________=0A>>OSPF mailing list=0A>>OSPF@ietf.orghttps://www1.ietf.org/m= ailman/listinfo/ospf=0A>>=0A>>=0A>>________________________________________= _______=0A>>OSPF mailing list=0A>>OSPF@ietf.org=0A>>https://www1.ietf.org/m= ailman/listinfo/ospf=0A>>=0A>>=0A>>=0A>>=0A>_______________________________= ________________=0A>OSPF mailing list=0A>OSPF@ietf.org=0A>https://www1.ietf= .org/mailman/listinfo/ospf=0A --Next_1163323201---0-202.54.124.151-25003 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi Sujay,
=0AI understand the reason for suggesting that a change = in nbr fsm state at "restarting router" to  be taken as a to= pology change, and thereby exiting GR, hence the extension draft.
=0A=0ABut on another note, taking into account default values  (rtr dead= interval 40sec and grace period 120sec), if a helper fsm state at restarti= ng router toggles from up-->down-->up within grace period, should we = immediately declare that as topology change? Or let GR try be successful un= til GR period expires?
=0A
=0AThanks
=0AVivek
=0A
=0A
=0A=
=0AOn Sun, 12 Nov 2006 sujay gupta wrote :
=0A>Hi Amir,
=0A>= ;Adding  ;
=0A>
=0A>If the link between R1-R2 toggles maki= ng the adjacency going down and then
=0A>come up.R1 should exit GR.=0A>R2  should exit  helper  mode send an inconsistent = LSA to R1, R1 on
=0A>examining this LSA should exit GR.
=0A>Or;= alternately R1 could detect a Nbr Down event and immediately exit GR.
= =0A>
=0A>Regds,
=0A>-Sujay
=0A>( Ref
=0A>http://= tools.ietf.org/wg/ospf/draft-holla-ospf-update-graceful-restart-02.txtSecti= on
=0A>3.2.1(1))
=0A>
=0A>
=0A>
=0A>On 11/10/= 06, Abhay D.S <abhayds@acm.org> wrote:
=0A>>
=0A>>&= nbsp; dear amir,
=0A>>There is nothing called as Quitting GR.
= =0A>>
=0A>>In the case below , the most desirable thing is t= o give a message or an
=0A>>SNMP trap for qualifying to a quit sce= nario.
=0A>>
=0A>>There is a thin line between completion= and quitting GR. Just imagine this
=0A>>happens when the last rou= ter was about to be
=0A>>full and  re-starter was  just = about the originate  old router LSA ,
=0A>>perfectly as the o= ld one and then this event happened ?
=0A>>
=0A>>Would yo= u quit GR or log a message.
=0A>>
=0A>>Another is what is= your idea of quit GR  ?.
=0A>>
=0A>>Thanks,
=0A&= gt;>
=0A>>Abhay
=0A>>
=0A>>
=0A>>=0A>>Khan Amir-G20247 wrote:
=0A>>
=0A>>Hi
=0A&= gt;>
=0A>>I have query related to OSPF Graceful Restart.
=0A= >>
=0A>>
=0A>>
=0A>>  Consider this s= cenario:
=0A>>
=0A>>
=0A>>
=0A>>- Three= Routers R1, R2 and R3 connected via Broadcast networks.
=0A>>
= =0A>>
=0A>>
=0A>>
=0A>>
=0A>>- Wh= ere R1 is a DR on both the segments, where as R2 and R3 are in
=0A>&g= t;DR-other
=0A>>- Now R1 wants to perform GR, R2 and R3 agrees to = be its Helpers.
=0A>>- Now after restart R1 will try to form adjac= ency with both R2 and R3.
=0A>>- Lets say R1 and R2  had beco= me FULL, while R1 and R3 had reached Exstart
=0A>>state. Now at th= is time(when R1 and R3 are in transition state) the
=0A>>adjacency= between R1 and  R2  goes down for some reson.
=0A>>
= =0A>>  Considering above scenario, my doubts are:
=0A>>=
=0A>>-  As the adjacency between R1 and R2 has gone down(whi= ch is a Topology
=0A>>change) and R1 is still in GR mode, can R1 q= uit GR ? In general can a NBR
=0A>>which was FULL and then later g= one down can be treated as one of the
=0A>>conditions for quiting = GR ?
=0A>>
=0A>>
=0A>>
=0A>>
=0A>= >Regards
=0A>>Aamir
=0A>>
=0A>>
=0A>>= ;
=0A>>------------------------------
=0A>>
=0A>>= ;_______________________________________________
=0A>>OSPF mailing= list
=0A>>OSPF@ietf.orghttps://www1.ietf.org/mailman/listinfo/osp= f
=0A>>
=0A>>
=0A>>_____________________________= __________________
=0A>>OSPF mailing list
=0A>>OSPF@ietf.= org
=0A>>https://www1.ietf.org/mailman/listinfo/ospf
=0A>>= ;
=0A>>
=0A>>
=0A>>
=0A>__________________= _____________________________
=0A>OSPF mailing list
=0A>OSPF@ie= tf.org
=0A>https://www1.ietf.org/mailman/listinfo/ospf
=0A=0A

= =0A

=0A=0A --Next_1163323201---0-202.54.124.151-25003-- --===============0892703089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0892703089==-- From ospf-bounces@ietf.org Sun Nov 12 21:06:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjRA0-0006B9-N3; Sun, 12 Nov 2006 21:02:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjR9z-0006B1-Ii for ospf@ietf.org; Sun, 12 Nov 2006 21:02:55 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjR9v-0000y0-MI for ospf@ietf.org; Sun, 12 Nov 2006 21:02:55 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8N00H6HCBH75@szxga01-in.huawei.com> for ospf@ietf.org; Mon, 13 Nov 2006 10:02:05 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8N00JBWCBGII@szxga01-in.huawei.com> for ospf@ietf.org; Mon, 13 Nov 2006 10:02:05 +0800 (CST) Received: from [127.0.0.1] ([10.111.34.184]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8N00JW4CBE24@szxml03-in.huawei.com> for ospf@ietf.org; Mon, 13 Nov 2006 10:02:03 +0800 (CST) Date: Mon, 13 Nov 2006 10:02:02 +0800 From: "Abhay D.S" Subject: Re: [OSPF] OSPF GR query In-reply-to: To: sujay gupta Message-id: <4557D21A.5050809@acm.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_RvajTNvq1mT60+IwmhSHkQ)" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) References: <988EE2C769AC284ABAE9328BFC10703F01383B23@ZMY16EXM66.ds.mot.com> <4554505C.4040903@acm.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 94962611154c8404498b19f744990308 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: abhayds@acm.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_RvajTNvq1mT60+IwmhSHkQ) Content-type: multipart/alternative; boundary="Boundary_(ID_rnKKUARt/JlVTIfMssy2gw)" --Boundary_(ID_rnKKUARt/JlVTIfMssy2gw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT hi , To say in non-technical terms, quit gr or not quit gr makes no difference. ( I mean my cup is atleast half full, instead of calling it half empty). There are many other protocols dependending on OSPFv2 GR, so we better not to a real Quit for the following reasons. Here is the order of convergence required in major networks during graceful restart. 1) Layer 2 convergence (control plane information) 2) Layer 3 OSPF/ISIS -> MPLS (Shim Protocols) -> BGP 3) Final convergence of all protocols. In step 2, if you quit GR what would happen to MPLS and BGP convergence ?.(Dont forget the big deal BGP recursive route selection ) GR will work even if you dont follow the RFC completely. ( You might consider both the Graceful re-start draft and update to graceful restart draft as informational) to help you realize the GR which can work. Abhay P.S: Real quit might include restarting the router's software processes disgracefully.Again there is no difference is it ? sujay gupta wrote: > Hi Amir, > Adding ; > > If the link between R1-R2 toggles making the adjacency going down and > then come up.R1 should exit GR. > R2 should exit helper mode send an inconsistent LSA to R1, R1 on > examining this LSA should exit GR. > Or; alternately R1 could detect a Nbr Down event and immediately exit GR. > > Regds, > -Sujay > ( Ref > http://tools.ietf.org/wg/ospf/draft-holla-ospf-update-graceful-restart-02.txt > > Section 3.2.1(1)) > > > > On 11/10/06, *Abhay D.S* > > wrote: > > dear amir, > There is nothing called as Quitting GR. > > In the case below , the most desirable thing is to give a message > or an SNMP trap for qualifying to a quit scenario. > > There is a thin line between completion and quitting GR. Just > imagine this happens when the last router was about to be > full and re-starter was just about the originate old router LSA > , perfectly as the old one and then this event happened ? > > Would you quit GR or log a message. > > Another is what is your idea of quit GR ?. > > Thanks, > > Abhay > > > > Khan Amir-G20247 wrote: >> Hi >> >> I have query related to OSPF Graceful Restart. >> >> >> >> Consider this scenario: >> >> >> >> - Three Routers R1, R2 and R3 connected via Broadcast networks. >> >> >> >> >> >> - Where R1 is a DR on both the segments, where as R2 and R3 are >> in DR-other >> - Now R1 wants to perform GR, R2 and R3 agrees to be its Helpers. >> - Now after restart R1 will try to form adjacency with both R2 >> and R3. >> - Lets say R1 and R2 had become FULL, while R1 and R3 had >> reached Exstart state. Now at this time(when R1 and R3 are in >> transition state) the adjacency between R1 and R2 goes down for >> some reson. >> >> Considering above scenario, my doubts are: >> >> - As the adjacency between R1 and R2 has gone down(which is a >> Topology change) and R1 is still in GR mode, can R1 quit GR ? In >> general can a NBR which was FULL and then later gone down can be >> treated as one of the conditions for quiting GR ? >> >> >> >> >> Regards >> Aamir >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > --Boundary_(ID_rnKKUARt/JlVTIfMssy2gw) Content-type: multipart/related; boundary="Boundary_(ID_pwPFvkTTl8L0yy7yCqzh6g)" --Boundary_(ID_pwPFvkTTl8L0yy7yCqzh6g) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT hi ,

To say in non-technical terms, quit gr or not quit gr makes no difference. ( I mean my cup is atleast half full, instead of calling
it half empty).

There are many other protocols dependending on OSPFv2 GR, so we better not to a real Quit for the following reasons.

Here is the order of convergence required in major networks during graceful restart.


1) Layer 2 convergence (control plane information)
2) Layer 3 OSPF/ISIS -> MPLS (Shim Protocols) -> BGP
3) Final convergence of all protocols.

In step 2, if you quit GR what would happen to MPLS and BGP convergence ?.(Dont forget the big deal BGP recursive
route selection )

GR will work even if you dont follow the RFC completely. ( You might consider both the Graceful re-start draft and update
to graceful restart draft as informational) to help you realize the GR which can work.

Abhay


P.S: Real quit might include restarting the router's software processes disgracefully.Again there is no difference is it ?

sujay gupta wrote:
Hi Amir,
Adding  ;

If the link between R1-R2 toggles making the adjacency going down and then come up.R1 should exit GR.
R2  should exit  helper  mode send an inconsistent LSA to R1, R1 on examining this LSA should exit GR.
Or; alternately R1 could detect a Nbr Down event and immediately exit GR.

Regds,
-Sujay
( Ref http://tools.ietf.org/wg/ospf/draft-holla-ospf-update-graceful-restart-02.txt Section 3.2.1(1))



On 11/10/06, Abhay D.S <abhayds@acm.org> wrote:
dear amir,
There is nothing called as Quitting GR.

In the case below , the most desirable thing is to give a message or an SNMP trap for qualifying to a quit scenario.

There is a thin line between completion and quitting GR. Just imagine this happens when the last router was about to be
full and  re-starter was  just about the originate  old router LSA , perfectly as the old one and then this event happened ?

Would you quit GR or log a message.

Another is what is your idea of quit GR  ?.

Thanks,

Abhay



Khan Amir-G20247 wrote:
Hi

I have query related to OSPF Graceful Restart.

 

 Consider this scenario:

 

- Three Routers R1, R2 and R3 connected via Broadcast networks.

 

 

- Where R1 is a DR on both the segments, where as R2 and R3 are in DR-other
- Now R1 wants to perform GR, R2 and R3 agrees to be its Helpers.
- Now after restart R1 will try to form adjacency with both R2 and R3.
- Lets say R1 and R2  had become FULL, while R1 and R3 had reached Exstart state. Now at this time(when R1 and R3 are in transition state) the adjacency between R1 and  R2  goes down for some reson.  
 
 Considering above scenario, my doubts are:

-  As the adjacency between R1 and R2 has gone down(which is a Topology change) and R1 is still in GR mode, can R1 quit GR ? In general can a NBR which was FULL and then later gone down can be treated as one of the conditions for quiting GR ? 
 

 

Regards
Aamir

 


_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf





_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf
--Boundary_(ID_pwPFvkTTl8L0yy7yCqzh6g) Content-id: Content-type: image/gif Content-transfer-encoding: base64 R0lGODlhyAH8AHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALBMA EQCwAcwAgQAAAAAAAP///wECAwL/hI+py+0Po5y0Whqy3rz7D4baRZbmiabqyrbuCx+iJtT2 jef6zvf2nIkJh8Si8YhMJj6+pvMJjeI+yqr1is1qFSCp9wsO60DbsvmMLnvE7Lb77UnL5/R6 hPPO6/ftjv0PGHjUwVdoePjFIbjI2AhBiBgpOenk53iJKbdBydnp2bORKTpqhPd5ipoqoEja 6nqxqSo7ixr6eosLYErL2/vJmhu8SONbbFwbJKycFnvs/NxpuzytRAx9jc05Qs0N05wNHh4p 3V0OmyGerj65be7uYL0uP1/Y/v4eT6+/n2d/v5yPn8CBbPz9cxWQoMKFiZIdFJWQocSJUAw+ BISOosaN/14cXqwTkaPIkTksftSSkaTKlTw8nrwSkqXMlSZfDkk5M6fOHwFslgqwM6jQVT19 vog5NOnImkYr4FQKVafLphiARr0qdCpVeFaxeg2qdSuCp1/L5gxLlazZtTPRvlTLNq5Mtwfh yr3Lkq67rnj77ix60a7fwST1KhNMOPFSwOX4Kn7ctrFjyJRpMg6GuLLmjYYvTd4MWuVlUplD m57YGePp1ZFHfWYNm3Om0rFrE0x95rXt3aiH6eYNfCFumMGLL7Xz27jygaPNJF8OfV9zlNGr 93b+3Lr2dcO9bf/OcPog8OQViieSvbx6cOdjpF8P/1p7F+/j23c2f0X9+/yL5f9HsV9/AvLy XwkBDoigLAVacGCCDtbi3YMSQrPgBA1OiCE7LVyYYYeIVAiPhyL6lwKHI564B4hLoMgiLSrK 0GKMqbyoi4w2nqKiiTfu2BGDmul4GpBXVSgkVEVudqSRGICWZGVNJlXgk1mRJ+VQ+VUJFpWr zYflX1oG+UCXQIzZhXwUkonmN/hhk2abXdZwHpZisvnMnGZSOI6GDNh5yJt91JnnnYB+SMl0 fBriZ0GD9kknnoTquWKgjApqzKFrOjoppDBKimijx1j6KaX1aMOFJKBWuminoqL6qKY1msrp paG2muqsmWrq56n+1cpHomL4CoauiI7FTqy2snqrrMr/jkqqAYkK2wuwUkBL4KopelLUs8Yi yy2zmC7bK7bOFjqOm+aeK20Uc6arrrV6SJstubSCG22g6N47prtw7kLUc/C+WmxL/CK1iqfd hqtvtaDcYFVXyaVLmxsPMwznDz6wOy2vU/Bb8MUGHzsGxVN4jK2vE1s88sIJK9gEXw77+/HB KVc88w4Qm0wyzSir/O2uOXesc0sx+yxwQDCXrM3FamaGcbv01uxyy0P7cvJnR0eDs8qvndwz 1S0vLfXKs3DtWHY3J82z1T8/7WLYk12tsddpi8y1NlkLHfTONk/dds5lh9010WOkhA7HJf1y 9+Av9ws322MD/vfaIMv8LuJo/yc7eb2gEN4wYk1XJLaiSMuLeaX4nh7CvJ9+DriqWF/uetx9 l74r6rZDQvuHiXsr++OqU6557n3ujnDgCgt/vOMSW0567MqrQu3sz4v+evO8T1/LtoJnXvno ASMv/fbF9x7++IUSf23o2f8ufvvdV/+989yXn77xwctvKvrvkw+99nLzTz1SaYt9/wMeHPiW vOuZalzxU6ABWUbA+83vgNFgYP5utwb14QiDGbQfgTiIu0JZcEtfig1gWLeUErKGMSgUSQux 8kIXEmuFKtxSpIJUQ9OMJoY82tEOewhEBS2Ah0FkkaGKiMRmDTGJTOxTiJoIxXeFKYpULMgj qojFRP/cIYtcrIQEiNhF+0QpjGScglPKWEYQgRGN28kRG7lIozW+UTk0Atgcm1hHO96xiHkc 4R572MdN/ZFHgZzhIG1USEMeMkaJVOQiT9TIGz5SRJEs1SQ9VMklXhJDmdzTJiXUyQbI8ZNs CeUTSckfU04RlWLMwihZqRRVfvGVsJSKLJdUS+vc0ke5hM4uYdFLOiInmMH5pQkiRkzFdAcL tEymQIypH2fqEBPIlKZZlomGZlqTPQjR5jbxA80iePObVBNGNck5l3BWY5zo/EVj2hlLdbqS nfBElDzVQM96wuGe2dRnYXxyTn+mA5vTCKhA5cPPQBj0oP5JKCMWWhYp5ZP/IwR9CERh2KuL /sihrpkooJ7k0fBwtJuPAQpIl1NRsRDsKyYdWUbiEZOQ8oMpYnGKTPunM2s4LKd4201Ka7qn m+JIby5bmm6Eqo6fApUrSD0fTEW2MaAdDjY0Xap+mjqvneqNp3vb0kiNolGKRE6qWu1cT5n0 1a2stDA6DWFbTWq1sBpJqVZVwVoZuq+01nUsciVmVfe6hbtu86+AzWZfH0nYwtJBsKRMrGIx ctgwOvaxD2UsGslBWYBEFoiTzewr1ERGzHq2LpvtUGdH2w3DAVK0qFWpZR3E2tYCVrUPAoZs b6uL1+rytLh9bAi/Y4neCtdCtLWNbYeLXAOBFq2xLU2uc0/QQb/E4bnUHQQT4jnd6moXn79F TXa3C16FAuFMMwiveTULwtOdNwsFAAA7 --Boundary_(ID_pwPFvkTTl8L0yy7yCqzh6g)-- --Boundary_(ID_rnKKUARt/JlVTIfMssy2gw)-- --Boundary_(ID_RvajTNvq1mT60+IwmhSHkQ) Content-type: text/x-vcard; charset=utf-8; name=abhayds.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=abhayds.vcf begin:vcard fn:Abhay Rao n:Rao;Abhay email;internet:abhayds@acm.org version:2.1 end:vcard --Boundary_(ID_RvajTNvq1mT60+IwmhSHkQ) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --Boundary_(ID_RvajTNvq1mT60+IwmhSHkQ)-- From ospf-bounces@ietf.org Mon Nov 13 00:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjUhq-0000pX-Vn; Mon, 13 Nov 2006 00:50:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjUhq-0000pP-4B for ospf@ietf.org; Mon, 13 Nov 2006 00:50:06 -0500 Received: from [202.54.124.239] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjUhm-0001Ni-4L for ospf@ietf.org; Mon, 13 Nov 2006 00:50:06 -0500 Received: (qmail 28172 invoked by uid 510); 13 Nov 2006 05:46:31 -0000 Date: 13 Nov 2006 05:46:31 -0000 Message-ID: <20061113054631.28171.qmail@webmail58.rediffmail.com> Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 13 nov 2006 05:46:31 -0000 MIME-Version: 1.0 From: "Vivek Dubey" To: "sujay gupta" Subject: Re: [OSPF] OSPF GR query X-Spam-Score: 0.1 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vivek Dubey List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0649425958==" Errors-To: ospf-bounces@ietf.org This is a multipart mime message --===============0649425958== Content-type: multipart/alternative; boundary="Next_1163396791---0-202.54.124.239-28152" This is a multipart mime message --Next_1163396791---0-202.54.124.239-28152 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Comments inline.=0A=0AOn Mon, 13 Nov 2006 sujay gupta wrote :=0A>Hi Vivek,= =0A>I too had the same thoughts once, but concluded this way;=0A>=0A>a) Not= ing that GR successful completion is based on the forwarding=0A>plane being= intact, the control plane on a possible restart.And in the given=0A>scenar= io a "link up/dwn" event has occurred which is probably indicative of=0A>th= e forwarding plane inconsistency. This event should be picked up as an=0A>e= xit-GR notification by the helper.=0A>=0A[vivek] NBR FSM getting down can b= e result of both control/forwarding plane issues. Tracking nbr fsm is not g= ood enough indication to conclude where the issue is. More-ever in case of = link up/down case, I would expect local event to "control plane" from some = "port-mgmt" software (as an example). This would allow respective control p= lane software take relevant action.=0A=0A>b) Even if the adjacency builds u= p and then goes down again for control=0A>plane=0A>reasons alone, a conserv= ative and safer approach would bring down the GR.=0A>consider a worse case = scenario of a misbehaving helper router or due to=0A>change=0A>in local pol= icy on the helper( by some administrator) the helper has exit=0A>helping mo= de.=0A>=0A[vivek] I think the whole idea of GR is to take less conservative= approach.=0A=0A>c) Yet things may work even if the helper does not exit GR= until grace=0A>period, however=0A>essentially as we follow a conservative = approach in the routing area, it is=0A>*better* to quit!=0A>=0A>On second t= houghts the whole idea as proposed in the original Moy GR that of=0A>detect= ing non=0A>helping routers through lsa consistency checks is not foolproof,= some simple=0A>ways like sending=0A>a one-way hello , or a lls block signa= lling to the restarting router is more=0A>secure, fast and sure shot.=0A>= =0A[vivek] Again as said above, original GR RFC even allows one to ignore t= opology change detected by LSAs (disabling strict lsa checking).=0A=0AI thi= nk its more of a deployment choice. Taking conservative approach one should= do as the extension-draft suggests. But if one thinks otherwise, he can ve= ry well let GR be successful, if possible.=0A=0A>Btw which organization do = you work for, Vivek?=0A[vivek] Motorola=0A=0A>Thanks & Regds,=0A>Sujay=0A>= =0AThanks=0AVivek=0A=0A>=0A>=0A>=0A>On 12 Nov 2006 09:20:01 -0000, Vivek Du= bey =0A>wrote:=0A>>=0A>>Hi Sujay,=0A>>I understa= nd the reason for suggesting that a change in nbr fsm state at=0A>>"restart= ing router" to be taken as a topology change, and thereby exiting=0A>>GR, = hence the extension draft.=0A>>=0A>>But on another note, taking into accoun= t default values (rtr dead=0A>>interval 40sec and grace period 120sec), if= a helper fsm state at restarting=0A>>router toggles from up-->down-->up wi= thin grace period, should we=0A>>immediately declare that as topology chang= e? Or let GR try be successful=0A>>until GR period expires?=0A>>=0A>>Thanks= =0A>>Vivek=0A>>=0A>>=0A>>=0A>>On Sun, 12 Nov 2006 sujay gupta wrote :=0A>> = >Hi Amir,=0A>> >Adding ;=0A>> >=0A>> >If the link between R1-R2 toggles ma= king the adjacency going down and=0A>>then=0A>> >come up.R1 should exit GR.= =0A>> >R2 should exit helper mode send an inconsistent LSA to R1, R1 on= =0A>> >examining this LSA should exit GR.=0A>> >Or; alternately R1 could de= tect a Nbr Down event and immediately exit GR.=0A>> >=0A>> >Regds,=0A>> >-S= ujay=0A>> >( Ref=0A>> >=0A>>http://tools.ietf.org/wg/ospf/draft-holla-ospf-= update-graceful-restart-02.txtSection=0A>> >3.2.1(1))=0A>> >=0A>> >=0A>> >= =0A>> >On 11/10/06, Abhay D.S wrote:=0A>> >>=0A>> >> dea= r amir,=0A>> >>There is nothing called as Quitting GR.=0A>> >>=0A>> >>In th= e case below , the most desirable thing is to give a message or an=0A>> >>S= NMP trap for qualifying to a quit scenario.=0A>> >>=0A>> >>There is a thin = line between completion and quitting GR. Just imagine=0A>>this=0A>> >>happe= ns when the last router was about to be=0A>> >>full and re-starter was ju= st about the originate old router LSA ,=0A>> >>perfectly as the old one an= d then this event happened ?=0A>> >>=0A>> >>Would you quit GR or log a mess= age.=0A>> >>=0A>> >>Another is what is your idea of quit GR ?.=0A>> >>=0A>= > >>Thanks,=0A>> >>=0A>> >>Abhay=0A>> >>=0A>> >>=0A>> >>=0A>> >>Khan Amir-G= 20247 wrote:=0A>> >>=0A>> >>Hi=0A>> >>=0A>> >>I have query related to OSPF = Graceful Restart.=0A>> >>=0A>> >>=0A>> >>=0A>> >> Consider this scenario:= =0A>> >>=0A>> >>=0A>> >>=0A>> >>- Three Routers R1, R2 and R3 connected via= Broadcast networks.=0A>> >>=0A>> >>=0A>> >>=0A>> >>=0A>> >>=0A>> >>- Where= R1 is a DR on both the segments, where as R2 and R3 are in=0A>> >>DR-other= =0A>> >>- Now R1 wants to perform GR, R2 and R3 agrees to be its Helpers.= =0A>> >>- Now after restart R1 will try to form adjacency with both R2 and = R3.=0A>> >>- Lets say R1 and R2 had become FULL, while R1 and R3 had reach= ed=0A>>Exstart=0A>> >>state. Now at this time(when R1 and R3 are in transit= ion state) the=0A>> >>adjacency between R1 and R2 goes down for some reso= n.=0A>> >>=0A>> >> Considering above scenario, my doubts are:=0A>> >>=0A>>= >>- As the adjacency between R1 and R2 has gone down(which is a Topology= =0A>> >>change) and R1 is still in GR mode, can R1 quit GR ? In general can= a=0A>>NBR=0A>> >>which was FULL and then later gone down can be treated as= one of the=0A>> >>conditions for quiting GR ?=0A>> >>=0A>> >>=0A>> >>=0A>>= >>=0A>> >>Regards=0A>> >>Aamir=0A>> >>=0A>> >>=0A>> >>=0A>> >>------------= ------------------=0A>> >>=0A>> >>_________________________________________= ______=0A>> >>OSPF mailing list=0A>> >>OSPF@ietf.orghttps://www1.ietf.org/m= ailman/listinfo/ospf=0A>> >>=0A>> >>=0A>> >>_______________________________= ________________=0A>> >>OSPF mailing list=0A>> >>OSPF@ietf.org=0A>> >>https= ://www1.ietf.org/mailman/listinfo/ospf=0A>> >>=0A>> >>=0A>> >>=0A>> >>=0A>>= >_______________________________________________=0A>> >OSPF mailing list= =0A>> >OSPF@ietf.org=0A>> >https://www1.ietf.org/mailman/listinfo/ospf=0A>>= =0A>>=0A>>=0A>>=0A>>_________= ______________________________________=0A>>OSPF mailing list=0A>>OSPF@ietf.= org=0A>>https://www1.ietf.org/mailman/listinfo/ospf=0A>>=0A>>=0A>>=0A --Next_1163396791---0-202.54.124.239-28152 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AComments inline.
=0A
=0AOn Mon, 13 Nov 2006 sujay gupta wrote :=
=0A>Hi Vivek,
=0A>I too had the same thoughts once, but conclu= ded this way;
=0A>
=0A>a) Noting that GR successful completion = is based on the forwarding
=0A>plane being intact, the control plane = on a possible restart.And in the given
=0A>scenario a "link up/d= wn" event has occurred which is probably indicative of
=0A>the f= orwarding plane inconsistency. This event should be picked up as an
=0A&= gt;exit-GR notification by the helper.
=0A>
=0A[vivek] NBR FSM get= ting down can be result of both control/forwarding plane issues. Tracking n= br fsm is not good enough indication to conclude where the issue is. More-e= ver in case of link up/down case, I would expect local event to "contr= ol plane" from some "port-mgmt" software (as an example). Th= is would allow respective control plane software take relevant action.
= =0A
=0A>b) Even if the adjacency builds up and then goes down again f= or control
=0A>plane
=0A>reasons alone, a conservative and safe= r approach would bring down the GR.
=0A>consider a worse case scenari= o of a misbehaving helper router or due to
=0A>change
=0A>in lo= cal policy on the helper( by some administrator) the helper has exit
=0A= >helping mode.
=0A>
=0A[vivek] I think the whole idea of GR is = to take less conservative approach.
=0A
=0A>c) Yet things may work= even if the helper does not exit GR until grace
=0A>period, however<= BR>=0A>essentially as we follow a conservative approach in the routing a= rea, it is
=0A>*better* to quit!
=0A>
=0A>On second thoug= hts the whole idea as proposed in the original Moy GR that of
=0A>det= ecting non
=0A>helping routers through lsa consistency checks is not = foolproof, some simple
=0A>ways like sending
=0A>a one-way hell= o , or a lls block signalling to the restarting router is more
=0A>se= cure, fast and sure shot.
=0A>
=0A[vivek] Again as said above, ori= ginal GR RFC even allows one to ignore topology change detected by LSAs (di= sabling strict lsa checking).
=0A
=0AI think its more of a deployment= choice. Taking conservative approach one should do as the extension-draft = suggests. But if one thinks otherwise, he can very well let GR be successfu= l, if possible.
=0A
=0A>Btw which organization do you work for, Vi= vek?
=0A[vivek] Motorola
=0A
=0A>Thanks & Regds,
=0A>= Sujay
=0A>
=0AThanks
=0AVivek
=0A
=0A>
=0A>
= =0A>
=0A>On 12 Nov 2006 09:20:01 -0000, Vivek Dubey <vivek_ospf= @rediffmail.com>
=0A>wrote:
=0A>>
=0A>>Hi Sujay,=
=0A>>I understand the reason for suggesting that a change in nbr = fsm state at
=0A>>"restarting router" to  be taken = as a topology change, and thereby exiting
=0A>>GR, hence the exten= sion draft.
=0A>>
=0A>>But on another note, taking into a= ccount default values  (rtr dead
=0A>>interval 40sec and grac= e period 120sec), if a helper fsm state at restarting
=0A>>router = toggles from up-->down-->up within grace period, should we
=0A>= >immediately declare that as topology change? Or let GR try be successfu= l
=0A>>until GR period expires?
=0A>>
=0A>>Thank= s
=0A>>Vivek
=0A>>
=0A>>
=0A>>
=0A&g= t;>On Sun, 12 Nov 2006 sujay gupta wrote :
=0A>> >Hi Amir,=0A>> >Adding  ;
=0A>> >
=0A>> >If = the link between R1-R2 toggles making the adjacency going down and
=0A&g= t;>then
=0A>> >come up.R1 should exit GR.
=0A>> >= ;R2  should exit  helper  mode send an inconsistent LSA to R= 1, R1 on
=0A>> >examining this LSA should exit GR.
=0A>&g= t; >Or; alternately R1 could detect a Nbr Down event and immediately exi= t GR.
=0A>> >
=0A>> >Regds,
=0A>> >-Suj= ay
=0A>> >( Ref
=0A>> >
=0A>>http://tools.= ietf.org/wg/ospf/draft-holla-ospf-update-graceful-restart-02.txtSection
= =0A>> >3.2.1(1))
=0A>> >
=0A>> >
=0A>= ;> >
=0A>> >On 11/10/06, Abhay D.S <abhayds@acm.org>= ; wrote:
=0A>> >>
=0A>> >>  dear amir,=0A>> >>There is nothing called as Quitting GR.
=0A>>= ; >>
=0A>> >>In the case below , the most desirable th= ing is to give a message or an
=0A>> >>SNMP trap for qualify= ing to a quit scenario.
=0A>> >>
=0A>> >>Ther= e is a thin line between completion and quitting GR. Just imagine
=0A>= ;>this
=0A>> >>happens when the last router was about to = be
=0A>> >>full and  re-starter was  just about th= e originate  old router LSA ,
=0A>> >>perfectly as the = old one and then this event happened ?
=0A>> >>
=0A>&g= t; >>Would you quit GR or log a message.
=0A>> >>
= =0A>> >>Another is what is your idea of quit GR  ?.
=0A= >> >>
=0A>> >>Thanks,
=0A>> >>=0A>> >>Abhay
=0A>> >>
=0A>> >><= BR>=0A>> >>
=0A>> >>Khan Amir-G20247 wrote:
= =0A>> >>
=0A>> >>Hi
=0A>> >>
= =0A>> >>I have query related to OSPF Graceful Restart.
=0A&g= t;> >>
=0A>> >>
=0A>> >>
=0A>&= gt; >>  Consider this scenario:
=0A>> >>
=0A&g= t;> >>
=0A>> >>
=0A>> >>- Three Rout= ers R1, R2 and R3 connected via Broadcast networks.
=0A>> >>=
=0A>> >>
=0A>> >>
=0A>> >>=0A>> >>
=0A>> >>- Where R1 is a DR on both the= segments, where as R2 and R3 are in
=0A>> >>DR-other
=0A= >> >>- Now R1 wants to perform GR, R2 and R3 agrees to be its H= elpers.
=0A>> >>- Now after restart R1 will try to form adja= cency with both R2 and R3.
=0A>> >>- Lets say R1 and R2 = ; had become FULL, while R1 and R3 had reached
=0A>>Exstart
=0A= >> >>state. Now at this time(when R1 and R3 are in transition s= tate) the
=0A>> >>adjacency between R1 and  R2  go= es down for some reson.
=0A>> >>
=0A>> >>&nbs= p; Considering above scenario, my doubts are:
=0A>> >>
= =0A>> >>-  As the adjacency between R1 and R2 has gone dow= n(which is a Topology
=0A>> >>change) and R1 is still in GR = mode, can R1 quit GR ? In general can a
=0A>>NBR
=0A>> &g= t;>which was FULL and then later gone down can be treated as one of the<= BR>=0A>> >>conditions for quiting GR ?
=0A>> >><= BR>=0A>> >>
=0A>> >>
=0A>> >>
= =0A>> >>Regards
=0A>> >>Aamir
=0A>> >= ;>
=0A>> >>
=0A>> >>
=0A>> >&g= t;------------------------------
=0A>> >>
=0A>> >= ;>_______________________________________________
=0A>> >>= ;OSPF mailing list
=0A>> >>OSPF@ietf.orghttps://www1.ietf.or= g/mailman/listinfo/ospf
=0A>> >>
=0A>> >>
= =0A>> >>_______________________________________________
=0A&= gt;> >>OSPF mailing list
=0A>> >>OSPF@ietf.org
= =0A>> >>https://www1.ietf.org/mailman/listinfo/ospf
=0A>&= gt; >>
=0A>> >>
=0A>> >>
=0A>>= >>
=0A>> >______________________________________________= _
=0A>> >OSPF mailing list
=0A>> >OSPF@ietf.org
= =0A>> >https://www1.ietf.org/mailman/listinfo/ospf
=0A>><= BR>=0A>>
=0A>><http://adworks.rediff.com/cgi-bin/AdWorks/= sigclick.cgi/www.rediff.com/signature-home.htm/1507191490@Middle5?PARTNER= =3D3>
=0A>>
=0A>>_____________________________________= __________
=0A>>OSPF mailing list
=0A>>OSPF@ietf.org
= =0A>>https://www1.ietf.org/mailman/listinfo/ospf
=0A>>
= =0A>>
=0A>>
=0A=0A

=0A

=0A= =0A --Next_1163396791---0-202.54.124.239-28152-- --===============0649425958== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0649425958==-- From ospf-bounces@ietf.org Mon Nov 13 05:20:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYtQ-00072q-Hl; Mon, 13 Nov 2006 05:18:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYtP-00071X-Ia for ospf@ietf.org; Mon, 13 Nov 2006 05:18:19 -0500 Received: from mail03.imt.uwm.edu ([129.89.7.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjYtO-00009w-8w for ospf@ietf.org; Mon, 13 Nov 2006 05:18:19 -0500 Received: from uwm.edu (pm04.imt.uwm.edu [129.89.7.64]) by mail03.imt.uwm.edu (8.13.1/8.13.1) with ESMTP id kADAIHZK024685; Mon, 13 Nov 2006 04:18:17 -0600 Received: from rrcs-67-52-10-122.west.biz.rr.com (rrcs-67-52-10-122.west.biz.rr.com [67.52.10.122]) by panthermail.uwm.edu (IMP) with HTTP for ; Mon, 13 Nov 2006 04:17:51 -0600 Message-ID: <1163413071.4558464f282ce@panthermail.uwm.edu> Date: Mon, 13 Nov 2006 04:17:51 -0600 From: mukul@uwm.edu To: ospf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: PantherMail 3.2.9-cvs X-Originating-IP: 67.52.10.122 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [OSPF] Priority driven processing of ASE LSAs? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi all, I apologize for this out-of-scope question. I know Cisco's IS-IS implementation supports priority-driven processing of advertised IP prefixes. http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a00801b2285.html I was wondering if some OSPF implementations support similar priority-driven processing of ASE LSAs? Thanks, Mukul Goyal _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 13 08:55:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjcG2-0002qi-BD; Mon, 13 Nov 2006 08:53:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjcFz-0002kI-Ju for ospf@ietf.org; Mon, 13 Nov 2006 08:53:51 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjcFy-0006VN-2N for ospf@ietf.org; Mon, 13 Nov 2006 08:53:51 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 05:53:49 -0800 X-IronPort-AV: i="4.09,416,1157353200"; d="txt'?scan'208"; a="1951927:sNHT78482169" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kADDrmt5032279 for ; Mon, 13 Nov 2006 08:53:48 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kADDrmDM018205 for ; Mon, 13 Nov 2006 08:53:48 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 08:53:48 -0500 Received: from [10.82.208.5] ([10.82.208.5]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 08:53:48 -0500 Message-ID: <455878EB.6010907@cisco.com> Date: Mon, 13 Nov 2006 08:53:47 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: OSPF List Content-Type: multipart/mixed; boundary="------------090703070404010206060404" X-OriginalArrivalTime: 13 Nov 2006 13:53:48.0367 (UTC) FILETIME=[24AD3DF0:01C7072B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1866; t=1163426028; x=1164290028; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20OSPF=20WG=20Minutes |Sender:=20 |To:=20OSPF=20List=20; bh=kxsIASFpgQlzCqfRJt/CujuyP21PB8RJfzM3v+AInOQ=; b=Z2elE5pTFq0eAywFfrn3tqrT4hgr7Dr51J4JmAsAArmYuYKf9WyXCI4XEUX0sWbpX/JVTG9O qZtOGvF5iBrCGTE0vMeLVEtffWA3C1K/m1ft04FMMZeIEuiEY6tdik8B; Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [OSPF] OSPF WG Minutes X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --------------090703070404010206060404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here are the OSPF WG minutes. There was a quite a bit of dialog at the mike after the OSPF MANET presentations. I've appended the Thomas Clausen's jabber log as well so that both are preserved with the proceedings. If you have any corrections, please UNICAST them to me. --------------090703070404010206060404 Content-Type: text/plain; name="IETF_66_Agenda.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="IETF_66_Agenda.txt" Open Shortest Path First WG (ospf) Wednesday, July 12 from 1300-1500 ==================================== CHAIR(s): Rohit Dube Acee Lindem AGENDA: o Administriva 5 minutes - Mailing list: OSPF@PEACH.EASE.LSOFT.COM Subscription/Removal: http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ospf&A=1 - Scribe? - Blue Sheets o Document Status - Acee 10 minutes o OSPF LLS to Standards Track - Alex Zinin, et al 5 minutes draft-ietf-ospf-lls-01.txt (Acee to cover) o OSPF Database Exchange Optimization - Richard Ogier 10 minutes draft-ogier-ospf-dbex-opt-00.txt (Acee to cover) o OSPFv2 MTR MIB - Namita Rawat 15 minutes draft-rawat-ospf-mt-mib-00.txt o OSPF AS Scoped Opaque LSA Validation - Igor Bryskin 15 minutes draft-bryskin-ospf-lsa-type11-validation-00.txt o OSPFv2 Graceful Restart Enhancements - Sujay Gupta 15 minutes draft-holla-ospf-update-graceful-restart-01.txt o OSPF WG Charter Update - Acee 15 minutes --------------090703070404010206060404 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --------------090703070404010206060404-- From ospf-bounces@ietf.org Mon Nov 13 09:00:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjcLu-0005uV-Ep; Mon, 13 Nov 2006 08:59:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjcLs-0005uP-H1 for ospf@ietf.org; Mon, 13 Nov 2006 08:59:56 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjcLo-0007Gs-Vt for ospf@ietf.org; Mon, 13 Nov 2006 08:59:56 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2006 05:59:51 -0800 X-IronPort-AV: i="4.09,416,1157353200"; d="txt'?scan'208"; a="344111167:sNHT166972386" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kADDxp2f002282 for ; Mon, 13 Nov 2006 08:59:51 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kADDxiDO019747 for ; Mon, 13 Nov 2006 08:59:51 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 08:59:50 -0500 Received: from [10.82.208.5] ([10.82.208.5]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 08:59:49 -0500 Message-ID: <45587A54.1090309@cisco.com> Date: Mon, 13 Nov 2006 08:59:48 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: OSPF List Content-Type: multipart/mixed; boundary="------------050308040408040000070004" X-OriginalArrivalTime: 13 Nov 2006 13:59:49.0079 (UTC) FILETIME=[FBAD8670:01C7072B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=37197; t=1163426391; x=1164290391; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20IETF=2067=20OSPF=20WG=20Meeting=20minutes=20-=20Correct=20fil e=20appended=20 |Sender:=20 |To:=20OSPF=20List=20; bh=6W45jL6xqYp7w04mwYaEwZkinL8mhqEYSveZO+LDq1Y=; b=LoBN6e3WJUu5FQyQPnYonnO4fQQkA1k0dM0xkTwQgJRb7CEK9JLnsAODUxhFR/QiZkT0B4oN NCJvC0bPrplscwFS+gsC1dDVT9iqOwgUdoTYWnAD1J8rSY2LFIHkuYSC; Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d4673ea769cc9931269061744af205ce Subject: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --------------050308040408040000070004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here are the minutes from the 67th IETF OSPF WG meeting. Thanks to Steve Nadas from Ericsson for taking them. There was quite a bit of dialog at the mike with respect to the OSPF MANET direction. I've also appended Thomas Clausen's jabber log. Please unicast corrections to me. IETF 67 Please unicast any corrections to me. Thanks, Acee --------------050308040408040000070004 Content-Type: text/plain; name="minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="minutes.txt" Minutes taken by Steve Nadas from Ericsson (stephen.nadas@ericsson.com) Acee: OSPFv3 IPSec Automated key generation no longer on agenda. We need to pass requirements to MSEC WG. Joe Macker: IPSec usage issue is common to MANET protocols. Requirements to be coordinated. Acee: Yes - there are multiple protocols that will have/need similar IPSec automated key requirements. Presentation Acee: Document status - no new RFCs since 66 - see slides Authors to resolve - multi-topo - like to see interop - capabilitils - iesg commetns need impls/interop test - TE extensions for V3 tls from iana requested - wait on AD oks WG LC: rtr's local address in TE xtensions OSPF fot V3 - needs reviewers in rtg area (+ others for clarity/readability ) Multi-area adjacency - Respin and re-Last Call - Will become standards track rather than informational. OSPFv3 mib, traps added OSPFv3 multi-topo - needs rev and impl addr families - simpler but not fate share but adj overhead ospf - ll signalling --> to wg doc New non-wg drafts - See later in minutes OSPF manet drafts - No rough consensus as yet Presentation Michael Barnes : Crypto alg reqmts for OSPFv2 Some discussion on list already Crypto - only md5 to date, can be attacked, some want stronger algs perhaps should specify these How - 2328 can add other algs w/o too much problem This draft - new algorithms should be used and won't change proto fields, there is key-id field which can has an associated algorithm as a property. Adding crypto terms- SA's - will carry key/alg choice, fairly straight forward approach - should not cause backwards compatibility because no change to OSPF proto fields - it's mis-config if one peers has a different algorithm. Acee: IPSec for v3, once done, lacks replay and key dist issues on lan - w/v2 these problems are solved mainly (seq#>=, not monotonic incr). Vishwas present requirements in Paris in both OSPF and RPSEC WGs. Sandy Murphy, Sparta : what is manditory to implement? Michael - Separate doc will discuss what is req'd (ala ISIS approach) Presentation: Manav Bhatia - Crypto Requirements Document NULL, MS5, sha1, cryptographic - refs in this doc more algorithms keep coming eg des was once must, now is should ot What doc must, should, - running doc as algorithms come and go uses 2119 terms should+ = should may become must See slides and draft for specific requirements. Acee: "should not" wording is problematic for NULL and other existing requirements. Russ white: shold may become a must vs. should+ (better to say what is meant) Presentation Lou Berger: berger-ospf-rfc2370bis followon to ietf66 - opaque LSA across areas - problem w/validation - so instead rev'd 2370 Edited Igor's draft into 2370 2370 minor changes - draft format - non-standard MUST etc keywords - and upodated community needs to review to see if it's right - because the wording was once subjective and is now less so. See slides for other changes. Acee wanted MAY or Should added Acee: when we add new info to TE LSAs - scalability issues - give priority to base ospf LSA over the opaque LSAs. Lou: We should take to list whether MAY or SHOULD should be in the final text. Acee: Will validate on list that this is to become a WG document. Presentation Emmanuel Baccelli: presented in dallas - simulations - draft-baccelli-ospf-mpr-ext-02 MPR extension for MANETs, recent, simulations. See slides for presentation. Acee: Didn't make cutoff - draft is queue to be posted Acee: Interesting to compare w/other simulations mdr etc - Emmanuel: yes but much discussed Presentation Russ White: ospf/manet experimental MDR - Design team favored - No field test - Employs neighbor reduction Joe Macker: On list stated that MDR was field tested. OR - implemenmted , tested and getting deployed MPR - New entry - See slides for more info. Emmanuel Baccelli: MPR draft is 1 year old and OLSR is older. What are real requirements? Emmanuel: Use both random walks and boeing framwework using random wavepoint for simulations Russ: No good way to decide what should become draft standard - testing is limited - recommend experimental for multiple proposals and additional work. Tom Henderson: Disagree characterization - flooding reduction - not so easy to untangle where benefits - between flood reduce and neighbor reduction. Unfair to characterize MDR as unfit for life critical applications. Acee: Can use either approach (or all 3) with or without neighbor reduction. Russ: There may be MANETs where there is low density Tom: Agree but MDRs handles multiple topologies. Andrew: low dense vs medium density - there are cases where fixed networks acts like mobile because weather Stan Ratliff - This has been discussed - do we go forward with one or more drafts. Joe Macker - technical points - there has been good work done and have shown good results with adjacency reductino - these can be used in full link state mode - not clear mesh n/w's - there are cases where these techniques are useful Russ: Agrees with Joe. Joe: If things are close, try to pick one - and that was ourstragety initially - perhps reasdon to make decision Emmanuel: Agrees good work done - doesn't see experimental as a failure. Joe: Was dissapointed with failure to pick single solution - need to avoid over optimization Emmanuel: 3 proposals w/different mechanisms - don't see how to judge which is better - consensus simulations are necessary but not sufficient - need to go experimental in order to be able to judge Phillip Jacquet: Should over optimize or over invoated - MPR is based on MANET (OLSR) which has been around for some time - try to adapt these approaches - think 3 proposals are interesting Tom: defends simulations - are advantages to sim - used sharable and tests\ed code - MANET experiments are expensive and hard to reprodice and so there is cost for that approach - thinks all will work want to understand how to get 2 next step - what is looked for and how will we know in 2 years? Acee: happend in pim/cbt and vpn info distribution for VPLA - in 1 case CBTs died to due lack of implementations but for VPLS there are 2 ways to do it deployed. However, I don't see how we get to consensus given everyone who goes to the mike gives a different summary of where we are. Andrew - Some version will get deployed in an experimental network. We will have some results but these will be hard to reproduce. get some info - results are hard to reprodice - need to look for a long time on a real network - simulations are harder on network except that lots of packets are lost in the real network. Tom: This does not imply that we can't do experiments - these are expensive due to the salary cost of the people who are mobile. Thomas Clausen - No critcism for Design Team work - would be good to use test beds from MANET community - not overnight process but there are opportunities - reqmt's are soft so no need to force solution. We can try and get experimental results and would have more information to make decisions. Joe Macker - been doing experiments in MANET for some time - need to have good tools to collect results - network can break but not seen in experiment - traffic flow and mobility abtre both important (done 20-30 nodes) suppplement sims w/experiments some failure modes are only seen in sim Russ: simulations aren't enough. Thomas- Experiments - are necessary but not sufficennt - relatively low hanging fruit Phillipe: Risk for 500x500 node in middle cover 80% - not like real life - mayne solution for simulation. Stan - Don't throw simulatoins away - agree - Design Team has done good work - not enough info with just simulationss - need to proceed with multiple experimental draft. Acee: Asked Tom to discuss Design Team work in a few slides Stan - Like to see hum on 1 or multiple Acee: If one draft - how would we pick it? We've been unsuccessful heretofore to agree on criteria. Presentation: Tom Henderson: Summary of Design history - See slides. Emmanuel: First MPR drafts - 4 yrs old - 2002 time frame (response to timeline). See slides for timeline of design team. Bill Fenner: Echo disappointment on no consensus. We should not ignore simulations. It provides useful info - but more is needed - no opinion on how to proceed. Acee: one alternative: quit. 2nd: Continue trying to agree on single solution. 3rd: Multiple expeimrntal drafts - provide stable point for implementation and further experience. Bill: Are the drafts ready today? How long to refine and then publish? Don't keeping tweaking if since we want experience with various approaches ASAP. Acee: More like refine and publish (ro's) but one is stable - Criteria for publication is less stringent for experimental drafts. Emmanuel: MPRs is pretty close Acee: Show hands on what should be done: - Quit working on OSPF MANET: none - Continue to drive to consensus: none - Refine drafts and publish as experimental: 2/3's of people in room. To be validated on list. Acee: Refining and publishing is clearly the consensus of those here at the meeting. This is difficult for the OSPF WG since we are used to reaching consensus on a single solution and only arguing about encodings and corner cases that need to be documented. Emmanuel: What type milestone are we looking at? Acee: Should proceed ASAP to WG last call and publication as experimental. Bill: Encourage to do this pretty quickly - easy to keep iterating and it better to get a quick snapshot soon for more experience with the approaches. Joe Macker: One experiment MANET draft dragged for years - maybe here want converge - WG chair call to get control of iteration and enhancement creep... Acee: Experimental drafts (even WG) should be treated a bit differently than standards track WG documents. In this case, the authors should retain control over the content and move toward publication rather than making the content the collective property of the OSPF WG. Jabber Comment: Need to see new MPR draft and code before agreeing to publish. Acee: Since lots of good work has been done and we are going to publish more than one draft, we should publish those which meet the implementation and simulation criteria. ----- Presentation Acee: Docs on the Edge Ogier database exchange change draft --> Should move to WG doc. Please read it. Extracted from MDR work. There were no objections to making the draft a WG document. Update to hello (kou) - Vendors have implemented in many different ways. Unlikly to be standardised after the fact No recent discussion. holla-opsf-update-gr - helper criteria changed - explict GR signalling Is there a requirement for these ? Padma: read older draft & thought these were already known - most thought explicit signaling didn't offer much improvement over inconsistent LSA. Acee: If were a true requirement we could respin but author limit would be exceeded. Padm: First is internal operation and no requirement for second. Acee: Discussion in montreal - some thought it was useful - it would be good to discuss on the list again. Helper Criteria Change - No one in room views as required. Explicit Termination - Also no one in room views as required. mirtorabi OSPF tag - extra into for lnks/rts - Acee is author so thinks is needed - more discussion on list - haven't gotten those with requirements to present at IETF> ospf-v2 MTR mib - Since MTR was accepted as a WG requiremet than the MIB should be accepted. Will test on the list. OSPF WG WILL MEET IN PRAGUE JABBER LOG Taken by Thomas Clausen (thomas.clausen@polytechnique.fr). [20:50:05] --- thomas.heide.clausen@gmail.com has joined [20:53:38] (since these logs are kept, I'll try to do some notes, even though there's nobody here yet....) [20:54:20] Acee: agenda-bashing, some minor reorg of the agenda. [20:55:40] Joe Macker: IPSec usage issues - maybe there will be permission to turn seq. no on to do replay protection.... [20:55:50] Where would this be discusseD? [20:56:14] Acee: bis on RFC...ehh, missed the # [20:56:37] Joe: there might be more than one group wanting to do this. [20:57:02] Acee: WG status presentation. [20:57:20] Short time since last IETF, not a lot seems to have happened. Waiting on people to do things. [20:57:28] No new RFCs [20:58:09] ospf-mib in RFC editors queue [20:58:28] Two RFCs in requested publication state - still comments from IESG that need to be addressed. [20:58:38] Should be published in short order. [20:59:06] MT & cap: comments from IESG, worked on. Wanting to do interop, but not done yet. [20:59:37] Traffic engineering: WG last call, waiting for implementation -> std.track. [21:00:10] Seems straight-fwd based on experience with OSPFv2 traffic engineering. [21:00:20] Waiting for AD OK? [21:00:50] te-node-addr: authors will change ever so slightly, last call, then to the IESG. [21:01:16] OPSF for v6: last called, date past. Looking for reviewers from directorate - 100pg document ;( [21:01:49] Looking for clarifications, not changes or enhancements. [21:02:07] Multi Area Adjacency: in publication-requested [21:02:36] Want to pull back since there are implementations upcoming. Off-line requirements, another revision and then last-call again. [21:02:49] Should go std. track, regardless what IETF page says. [21:03:22] [21:03:35] --- Tsubasa has joined [21:04:40] Non-wg documents: discussed at the end of the session to evaluate if it is to go here or there. [21:04:51] Same for MANETs: no rough consensus, will be covered today as well. [21:05:33] Michael Barnes presents "Cryptographic algorithm implementation requirements for OSPF. [21:06:36] http://www3.ietf.org/proceedings/06nov/slides/ospf-6.ppt [21:06:42] --- Tsubasa has left [21:07:21] --- thomas.heide.clausen@gmail.com has left: Logged out [21:08:31] --- Tsubasa has joined [21:09:03] --- Tsubasa has left [21:16:07] --- thomas.heide.clausen@gmail.com has joined [21:16:15] Acee: one comment. Turned this down with the statement that we want to use IPSec. 03:10 Motivation fr doing this: lack of replay protection due to lack of e2e key dist on a lan or maccess network. 03:10 Build-in OSPFv2 auth, people have pretty much solved this problem. Seq# is not monotonically increasing with every packet, >= relation. Use clock-tick as seq#. 03:11 Thinks that we may as well go ahead - discuss a bit more and ask, before it becomes wg-doc, 03:11 Sandy Murphy: ask obvious question - will it be mandatory to implement? 03:12 Barnes: this document is just covering the more general "any algorithm" - there will be another doc. 03:14 Manav: different OSPF Auth Schemes (unscheduled presentation) 03:14 Refers to an I-D.... [21:18:18] Acee: I don't think that an impl can say "you should not implement this sec mechanism" [21:18:54] IPSec will probably die at some point. [21:19:19] Russ White: instead of SHOULD+/-, maybe rather say "this is currently a SHOULD, but may become a MUST in the future", since it's a bit of a codeword. [21:20:07] lou Berger: Update to the OSPF Opaque LSA option [21:20:26] http://www3.ietf.org/proceedings/06nov/slides/ospf-3.ppt [21:20:43] Update to previous discussion. [21:22:09] It's important for those in the community to review 2370bis, since there are things which before were not requirements which are. [21:22:36] Please do a careful review. [21:23:24] Needed input - discussions over a SHOULD and a MAY, see slide "Changes in Draft from 3270" [21:23:26] 2370 [21:24:47] Take it to the list. [21:27:21] Time to bring in any other changes now. [21:27:57] Acee: needs to be wg document, validate on the list.... [21:28:12] Acee: will rather ask "who thinks it should *not* be a wg document. [21:30:20] Emmanuel Baccelli: OSPF extension for MANET based on MPRs [21:30:39] draft-baccelli-ospf-mpr-ext-02.txt [21:31:02] (slides not on line, but since nobody is listening in here in real-time, I won't bother to type the content - check proceedings if consulting jabber logs post-meeting) [21:31:59] --- Tsubasa has joined [21:32:38] Emmanuel presenting MPRs as "subset of links in the network" [21:32:57] Properties: 2-hop coverage, shortest-path coverage. [21:33:06] Allows for flooding optimizations, adjacency reduction, topology reduction. [21:33:23] Validated both experimentally in manets, as well as theoretically [21:33:33] Recent developments: [21:33:41] following discussions in DT: [21:33:54] Modified to match structure of 2740 and 2328 [21:34:03] Newer heuristics...didn't get the rest of the slide. [21:34:35] --- josoinin@jabber.org/Meebo has joined [21:34:37] Simulation code based on GTnet on-line on some-url. Check slides when they appear. [21:34:37] Showing simulations, flooding efficiency etc. [21:34:46] Acee: figures are compared to normal OSPF, right? [21:34:50] EB: Yes. [21:34:55] Simulations show that main overhead is still LSA flooding. [21:35:36] Flooding efficiency, adjacency reduction, topology reduction benefits shown as compared to regular OSPF. [21:35:52] Topology reduction gives a substantial gain in the size of packets.... [21:36:03] 500x500 square, 50% gain. [21:36:22] #links advertised, 75% gain [21:36:41] Simulations confirmed with independant simulations outside of GTnet and common framework. [21:37:01] Consistent results between these simulations and the GTnet results. [21:37:23] Work on analytical model, trying to explain why LSA flooding overhead is larger than synchronization overhead. [21:37:26] Next steps: [21:38:15] Simulations are necessary, but there are no satisfying wireless model, the scenarii are too restrictive and all in all simulations are not sufficient to evaluate what goes on in read deployment scenarios. [21:38:25] Encourages experimental status to move forward with getting real-world experience. [21:38:40] Both for this and other approaches - seems to me to be the way to go. [21:38:43] (done) [21:38:58] Acee: This I-D didn't make the cut-off, so it is posted during this week. [21:39:38] Acee: one thing which would be interesting would be to see how this compares to others in the same scenarios. [21:40:02] Emmanuel: Might be interesting, discussed a lot on mailing-list. [21:40:20] Russ White: OSPF/MANET experimental [21:40:40] Based on what he has seen on list. [21:40:50] MDR: no known field-testing, primarily simulation [21:41:00] Primary reduction is neighbor reduction [21:41:09] http://www3.ietf.org/proceedings/06nov/slides/ospf-4.ppt [21:41:32] Joe: Mentioned on the list, there have been field-testing with MDRs [21:41:42] OR: implemented, tested and deployed [21:41:55] Relies on flooding changes for overhead reduction [21:42:57] EB: MPRs are older, and the MPR draft has been posted for more than a year. [21:43:15] Russ: Requirement issues - do not know which to choose. [21:43:24] We do not know if the simulations mirror the real world [21:43:48] Asks if MPR simulations use random waypoint or random walk? [21:43:51] EB: Both [21:44:11] Russ: We do not know if the simulation scenarios mirror this. Are simulations a good decission point? [21:44:29] We do not know which of these drafts are to become draft-standard. [21:44:41] We do not know if any vendors are requesting actual implementations. [21:45:01] Proposal: move forward to experimental, until we have more data to decide if we move fwd to std. track. [21:45:11] Tom Henderson: [21:45:19] Just wanted to say a few things which he disagrees with. [21:45:55] <<<>>> [21:49:27] Andrew: most common medium density, avg neighbors 4-8, not sensor, somewhat static - these proposals are a major win. [21:49:47] Stan: We've argued or discussed these issues (topology, ...) on the mailing-list [21:50:00] What it boils down to is: go we go forward with one or with more than one draft. [21:50:12] For now, all we know is based on simulations - one simulation scenario, [21:50:46] Supports going forward with multiple experimental drafts, since we *need* more experience. [21:50:49] Joe Macker: technical points. [21:51:10] It's important to not falsely argue [21:51:10] There's been good work done here. [21:51:10] We've showed topology improvements with many approaches. [21:51:24] Adjacency reduction was an additional step - validated what you hypothesised have happend. [21:51:32] Should be studied more, but it is a good first-step. [21:51:41] These proposals can be used in full ls mode, however. [21:52:34] Russ: that's why we should go experimental, [21:52:53] Joe: It's ok to keep optimizing, but we did sit down with the ADs, and this is something that we do not want to optimize. [21:52:57] If it's close, we're not going to pick one. [21:53:03] Feels that the approaches are very close. [21:53:19] Thinks that a decission should be made, since that was the approach they went in with. [21:53:36] Emmanuel Baccelli: agree that good work has been going on in Dt. [21:54:14] Disagree on one point: seems that people think that going experimental is a failure. To the contrary, this is the only reasonable way to go, [21:54:18] Joe: clarify - that's not my point, what I think that we should do is to avoid over-optimization, [21:54:55] Emmanuel: 3 different proposals. Different mechanisms for TR, Flooding Optimization, Adjacency reduction. Hard to judge which is better - there seems some consensus that simulations while necessary are not sufficient. [21:55:06] Supports going experimental. This should be for the three drafts. [21:55:16] Can't see how to judge between two or three [21:55:38] Philippe Jacquet: not a problem of over-optimization. [21:56:20] What we discover is not new, it's out of MANEt. Developed for several years. Could fill several slides with references to experiments with MPR-based solutions, and MPR-OSPF and ORCA are both MPR-based. [21:56:36] First way to work on the solution would be to start with what is out of MANET. MPR-OSPF is out of MANEt. [21:56:48] No use to over-innovate something new, which has no experimental background [21:57:13] tom Henderson [21:58:10] Thinks that we have basis for decission - experiments are notoriously expensive and hard to reproduce [21:58:21] think that all approaches can work [21:58:52] His problem with going experimental is how to then identify the next-step. How can we come back and make a decision later. Rather not have this happen [21:59:03] Acee: this has happened before, will rather not have it happen in his. [21:59:43] This doesn't seem to have enough, right now, marked requirement as if it has got to be there tomorrow. [21:59:50] Hard to say what's going to happen. [22:08:19] <<<< jabber scribe participating in discussion - refer to audiocast or minute-tager >>>> [22:08:24] s/tager/taker/ [22:10:01] Acee: Tom will go through a few slides of the design-team [22:10:30] Stan: wants to see a hum tonight from this group if we proceed on one or multiple [22:10:36] Think that we should proceed with three. [22:11:07] Acee: if we say one draft, then we need to find an agreed way of selecting. I do not believe that we have that. Was the question if now we want to go forward with multiple draft? [22:11:11] Stan: Yes [22:11:40] Tom's presentation: (slides not found) [22:11:50] Timeline: started by OLSR ported to OSPF protocol [22:12:03] Difference from that to what subsequently emerged was reliable or unreliable question [22:12:49] Discussion of when drafts emerged. [22:14:12] Emmanuel Baccell: wanted to reiterate that the first draft was the one working with MPRs. [22:14:57] Tom: continues, simulator, ... [22:17:32] --- josoinin@jabber.org/Meebo has left: Logged out [22:17:53] Acee: Bill Fenner (AD) do you want to say anything? [22:17:56] Bill Fenner: [22:18:07] Wants to echo the disappointment that no consensus solution has come. [22:18:48] Agree that simulation-only isn't sufficient, but simulations shouldn't be disregarded either. [22:19:04] Acee: two alternatives: [22:19:14] 1) Continue to try to come to consensus [22:19:26] Actually [22:19:26] 0) Give up ;) [22:19:30] 1) is to come to a single solution [22:19:53] 2) To, as russ suggests, publish multiple I-Ds as experimental get some stable specifications. [22:20:19] Bill Fenner: are there I-Ds ready to be published today? [22:20:39] Acee: Refined, probably. ORCA hasn't changed for a while. MDR should be simplified. [22:21:26] Emmanuel: OSPF-MPR needs a bit of refinement, but close to finished. [22:21:37] Hum on "quit"? -- none [22:21:53] Hum on "consensus"? -- none [22:22:24] Hum on "go experimental after refinement"? -- some [22:22:37] Oops, people were raising hands, not humming and I am in the front. [22:22:48] So I may not have been getting right on "quit" and "consensus". [22:23:56] OSPF has been fortunate/spoiled since, with the history and legacy solutions have thus far been obvious. [22:24:02] Emmanuel: what is the milestones and timeline? [22:24:14] Acee: when we feel we're ready to implement....we'll WG last-call them. [22:25:11] Bill: encourage that to be pretty quick. One of the thing we saw in old MANET regime was to tweak "one last thing", and go back and forth doing epsilon-improvements each time. Better to get something done quick, snapshot, as long as it is implementable and corresponds to what people are thinking. [22:25:18] Acee: will take this under advice. [22:25:29] Joe: One of our [manet] drafts that was dragging along took years. [22:25:54] Encourage to set up a milestone - this is a WG chair call. [22:26:04] Acee: all authors have been attentive to comments. [22:28:17] The 3 I-Ds should move forward to draft-ietf-ospf to go experimental. Don't think we can exclude one or the other, [22:29:14] But need, of course, to study carefully. [22:29:23] Acee: discussing the "lingering documents". [22:29:39] ogier-dbx - should get consensus to move to wg document. [22:29:49] Update to OSPF hello procedures. [22:30:11] --- Tsubasa has left [22:30:11] Many flavors. [22:30:34] Need to discuss where we want to go. [22:30:48] Acee doesn't feel that it is ready to go to wg doc yet. [22:31:09] Graceful Restart I-D. [22:33:11] Padma: do we see a requirement for this? Acee: we need to ask this question. [22:33:58] Acee: wondering if there's any more discussion. This is basically suggestions for graceful restart [22:34:24] Padma: most are internal optimizations [22:34:46] Acee: that's for termination. for explicit termination, there are ways you can do it which require changes to the protocol. [22:35:08] Padma: I am thinking that the first is internal optimization, and that we do not need the second (explicit signaling for GR helper termination) [22:35:49] Acee: give it one more tour on the mailing-list, to see if we think that either of these requirements are necessary. [22:36:37] Acee: anyone in here seeing the helper criteria as a requirement (none in the room) [22:37:04] Idemn for explicit signaling for gr helper termination? - looks like it echos Padma's feel for the requirements [22:37:18] Extension for advertising optional route / link attributes. [22:37:28] (disclaimer: Acee is co-author) [22:37:34] Thinks it is necessary. [22:38:19] Nobody seems to have read it in the room, need more discussion on it. [22:38:37] Tried to get some of the people who came up with the requirements to get involved, but not succesful. [22:38:48] MIB for MT.... [22:39:13] Anyone who doesn't think it should be wg doc (nobody), sufficient people have read it that Acee should be wg doc. [22:39:37] Conclusion: Ogier-dbx & MIB-MT should be asked to be wg documents, then? [22:40:04] Final question: how many plan to be in Prague? Seems enough to have a meeting. [22:40:26] Done. 3 minutes early. [22:41:14] **** [22:41:38] Scribe apologizes for having gotten names and details wrong. Was trying to participate in the discussion, which made it sometimes difficult.... [22:41:40] **** [22:42:02] --- thomas.heide.clausen@gmail.com has left: Logged out --------------050308040408040000070004 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --------------050308040408040000070004-- From ospf-bounces@ietf.org Mon Nov 13 11:36:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjelw-0006up-QR; Mon, 13 Nov 2006 11:35:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjelv-0006uh-Ec for ospf@ietf.org; Mon, 13 Nov 2006 11:34:59 -0500 Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjelr-0002u5-6v for ospf@ietf.org; Mon, 13 Nov 2006 11:34:59 -0500 Received: from dialup-4.243.140.157.dial1.sanfrancisco1.level3.net ([4.243.140.157] helo=earthlink.net) by pop-savannah.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1Gjelo-00006H-00; Mon, 13 Nov 2006 11:34:53 -0500 Message-ID: <45589EAA.6030305@earthlink.net> Date: Mon, 13 Nov 2006 08:34:50 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Acee Lindem Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended References: <45587A54.1090309@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org > Acee: Show hands on what should be done: > - Quit working on OSPF MANET: none > - Continue to drive to consensus: none > - Refine drafts and publish as experimental: 2/3's of people > in room. To be validated on list. Acee, Correct me if I am wrong, but since the latest version of INRIA's draft was available only last week, and since previous versions did not fully specify the protocol (as pointed out by Phil Spagnolo in his 9/28/06 post to the ospf-manet list), it has not yet been decided that INRIA's draft will be published as experimental. Moreover, since INRIA has not participated in the GTNetS simulation comparison that Boeing has been conducting for the last two years, in which the MDR draft has been compared to Cisco's OR/SP drafts (results can be found at Boeing's OSPF-MANET website http://hipserver.mct.phantomworks.org/ietf/ospf/ ), it is only fair that we should do such a comparison with INRIA's draft before deciding to publish it as experimental. In fact, that has been the plan since the Dallas IETF meeting in March, and Philippe agreed to this in his message of 4/5/06: Philippe Jacquet wrote on 4/5/06: > Yes it would be great to synchronize our efforts on GTNet. > Let's see how to proceed. Now, 7 months later, INRIA has implemented their solution in GTNetS, so the next step would be for Boeing to work with INRIA to make sure the code is debugged and implemented in a manner that allows a fair comparison, just as Boeing has done with the OR/SP and MDR solutions over the last two years. Hopefully, this work can be completed by the next IETF meeting. I think it is reasonable and fair to require such a comparison to be done before INRIA's draft is accepted, especially since they promised to synchronize efforts 7 months ago. Let me know if you agree or disagree. IMO, to give INRIA a free pass and avoid such a comparison would be unfair to those of us who worked hard for the last two years on the GTNetS simulation effort. Richard _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 13 12:27:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfaQ-00081c-Uk; Mon, 13 Nov 2006 12:27:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfaQ-00081O-2N for ospf@ietf.org; Mon, 13 Nov 2006 12:27:10 -0500 Received: from [143.209.238.161] (helo=audl951.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjfaO-0001qR-O1 for ospf@ietf.org; Mon, 13 Nov 2006 12:27:10 -0500 Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id kADHR8JJ013720; Mon, 13 Nov 2006 11:27:08 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.8]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 13 Nov 2006 11:27:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OSPF] Priority driven processing of ASE LSAs? Date: Mon, 13 Nov 2006 11:27:04 -0600 Message-ID: <67FBA6A55FF15B46B8B572062529D26A10ACB3@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <1163413071.4558464f282ce@panthermail.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Priority driven processing of ASE LSAs? Thread-Index: AccHDfLb1UZzQPmQQEO95f3JZo229QAOofWw From: "GOODSPEED Don" To: , X-OriginalArrivalTime: 13 Nov 2006 17:27:07.0954 (UTC) FILETIME=[F1D33920:01C70748] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Mukul, The ordering and such of how routes are installed in a FIB (any forwarding table) is extremely vendor-specific (and vendor-unique). As this is a vendor-agnostic forum, you probably won't be receiving any responses (at least not public ones). Cheers, Don -----Original Message----- From: mukul@uwm.edu [mailto:mukul@uwm.edu]=20 Sent: Monday, November 13, 2006 2:18 AM To: ospf@ietf.org Subject: [OSPF] Priority driven processing of ASE LSAs? Hi all, I apologize for this out-of-scope question. I know Cisco's IS-IS implementation supports priority-driven processing of advertised IP prefixes. http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_ guide09186a00801b2285.html I was wondering if some OSPF implementations support similar priority-driven processing of ASE LSAs? Thanks, Mukul Goyal _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 13 12:40:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfmY-0000Zl-4r; Mon, 13 Nov 2006 12:39:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfmX-0000Zg-Co for ospf@ietf.org; Mon, 13 Nov 2006 12:39:41 -0500 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjfmW-0003Mr-4p for ospf@ietf.org; Mon, 13 Nov 2006 12:39:41 -0500 Received: by wx-out-0506.google.com with SMTP id h29so1345469wxd for ; Mon, 13 Nov 2006 09:39:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PU5YzOVxENHGffNilhafWVIn0eJJHsxbt9zeKzxAfwpoNNoVkuzqpbR3ODuFLb3PnaXoq3a7V4GQuYi6FFAqyGK4DeR1N8IHTEcaILrT3m0gMHLbJL4S/xWjV74SeZNGwQOayRMutMoEZxZ/B6G1sBA9RxOkzyhktoNA4gGtzCo= Received: by 10.70.57.2 with SMTP id f2mr40320wxa.1163439577390; Mon, 13 Nov 2006 09:39:37 -0800 (PST) Received: by 10.70.33.14 with HTTP; Mon, 13 Nov 2006 09:39:37 -0800 (PST) Message-ID: <77ead0ec0611130939j43912fcbkb235628dbd87e3c@mail.gmail.com> Date: Mon, 13 Nov 2006 09:39:37 -0800 From: "Vishwas Manral" To: "Acee Lindem" Subject: Re: [OSPF] OSPF WG Minutes In-Reply-To: <455878EB.6010907@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <455878EB.6010907@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Acee, Something seems wrong with the mail I received. Instead of having the minutes it has the agenda for the meeting on July 12th. Am I seeing it worng? Thanks, Vishwas On 11/13/06, Acee Lindem wrote: > Here are the OSPF WG minutes. There was a quite a bit of dialog > at the mike after the OSPF MANET presentations. I've appended > the Thomas Clausen's jabber log as well so that both are preserved > with the proceedings. If you have any corrections, please UNICAST > them to me. > > > > Open Shortest Path First WG (ospf) > > Wednesday, July 12 from 1300-1500 > ==================================== > > CHAIR(s): Rohit Dube > Acee Lindem > > AGENDA: > > o Administriva 5 minutes > > - Mailing list: OSPF@PEACH.EASE.LSOFT.COM Subscription/Removal: > http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ospf&A=1 > - Scribe? > - Blue Sheets > > o Document Status - Acee 10 minutes > > o OSPF LLS to Standards Track - Alex Zinin, et al 5 minutes > draft-ietf-ospf-lls-01.txt (Acee to cover) > > o OSPF Database Exchange Optimization - Richard Ogier 10 minutes > draft-ogier-ospf-dbex-opt-00.txt (Acee to cover) > > o OSPFv2 MTR MIB - Namita Rawat 15 minutes > draft-rawat-ospf-mt-mib-00.txt > > o OSPF AS Scoped Opaque LSA Validation - Igor Bryskin 15 minutes > draft-bryskin-ospf-lsa-type11-validation-00.txt > > o OSPFv2 Graceful Restart Enhancements - Sujay Gupta 15 minutes > draft-holla-ospf-update-graceful-restart-01.txt > > o OSPF WG Charter Update - Acee 15 minutes > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 13 12:49:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjfvu-0007Tu-B3; Mon, 13 Nov 2006 12:49:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjfvt-0007To-K1 for ospf@ietf.org; Mon, 13 Nov 2006 12:49:21 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjfvs-0004d9-7V for ospf@ietf.org; Mon, 13 Nov 2006 12:49:21 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 09:49:19 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="2160801:sNHT59028084" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kADHnHan002442; Mon, 13 Nov 2006 12:49:17 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kADHnHDM024789; Mon, 13 Nov 2006 12:49:17 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 12:49:17 -0500 Received: from [10.82.208.5] ([10.82.208.5]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 12:49:16 -0500 Message-ID: <4558B01C.8080600@cisco.com> Date: Mon, 13 Nov 2006 12:49:16 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Vishwas Manral Subject: Re: [OSPF] OSPF WG Minutes References: <455878EB.6010907@cisco.com> <77ead0ec0611130939j43912fcbkb235628dbd87e3c@mail.gmail.com> In-Reply-To: <77ead0ec0611130939j43912fcbkb235628dbd87e3c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2006 17:49:16.0789 (UTC) FILETIME=[09DF5A50:01C7074C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2102; t=1163440157; x=1164304157; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20[OSPF]=20OSPF=20WG=20Minutes |Sender:=20 |To:=20Vishwas=20Manral=20; bh=l/PRL8OWhfc1UwP3+A1XkgeiBXSOOiQ5VQnlPkSPsf0=; b=PWiRjUTk5HVFzjXn7SQ7/T82esKPRM5A2YZVodEcNnGvXZ0wdkn57mdLtopis0PjakDKWa33 NY/9zbQ6NfwrCpz05cSsKaMZ92oZw0l7c7baa2+aaXnxbguK5DXnvXWc; Authentication-Results: rtp-dkim-1; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Vishwas Manral wrote: > Hi Acee, > > Something seems wrong with the mail I received. > > Instead of having the minutes it has the agenda for the meeting on > July 12th. Am I seeing it worng? No - you're just not looking at the latest post. Thanks, Acee > > Thanks, > Vishwas > > On 11/13/06, Acee Lindem wrote: >> Here are the OSPF WG minutes. There was a quite a bit of dialog >> at the mike after the OSPF MANET presentations. I've appended >> the Thomas Clausen's jabber log as well so that both are preserved >> with the proceedings. If you have any corrections, please UNICAST >> them to me. >> >> >> >> Open Shortest Path First WG (ospf) >> >> Wednesday, July 12 from 1300-1500 >> ==================================== >> >> CHAIR(s): Rohit Dube >> Acee Lindem >> >> AGENDA: >> >> o Administriva 5 minutes >> >> - Mailing list: OSPF@PEACH.EASE.LSOFT.COM Subscription/Removal: >> http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ospf&A=1 >> - Scribe? >> - Blue Sheets >> >> o Document Status - Acee 10 minutes >> >> o OSPF LLS to Standards Track - Alex Zinin, et al 5 minutes >> draft-ietf-ospf-lls-01.txt (Acee to cover) >> >> o OSPF Database Exchange Optimization - Richard Ogier 10 minutes >> draft-ogier-ospf-dbex-opt-00.txt (Acee to cover) >> >> o OSPFv2 MTR MIB - Namita Rawat 15 minutes >> draft-rawat-ospf-mt-mib-00.txt >> >> o OSPF AS Scoped Opaque LSA Validation - Igor Bryskin 15 minutes >> draft-bryskin-ospf-lsa-type11-validation-00.txt >> >> o OSPFv2 Graceful Restart Enhancements - Sujay Gupta 15 minutes >> draft-holla-ospf-update-graceful-restart-01.txt >> >> o OSPF WG Charter Update - Acee 15 minutes >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf >> >> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 13 13:18:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgNb-00005G-PA; Mon, 13 Nov 2006 13:17:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgNb-000053-01 for ospf@ietf.org; Mon, 13 Nov 2006 13:17:59 -0500 Received: from smtp006.mail.ukl.yahoo.com ([217.12.11.95]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjgNX-00008l-8m for ospf@ietf.org; Mon, 13 Nov 2006 13:17:58 -0500 Received: (qmail 59923 invoked from network); 13 Nov 2006 18:17:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Received:X-YMail-OSG:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:In-Reply-To:X-MimeOLE; b=43sUgbLvsLdkzxdwhDYTzZyP7K3rOLTh1Mu8y3eVB3nz85daQ6kZ9fOGyhkK4+NXijiNO+LutQgCfFmBJdwSoIAc6OaFTcvfFpU4lA10lGObZ5DSjUDxQpC8x0C79XveO1KzW13GfvgBER1HtZyukeeOgDW2y2QhmIiaXvGRVis= ; Received: from unknown (HELO mbhatia) (manav_bhatia06@202.144.106.189 with login) by smtp006.mail.ukl.yahoo.com with SMTP; 13 Nov 2006 18:17:52 -0000 X-YMail-OSG: BtbnHbwVM1man5.AE9PLvNaXNBlj6Ic34WFk.KJxPUrW6_gTIxSVzjd6YaV0zLRilH5JXYJ65VG9ddLFDeWA.rtepYIbdfyk2Sqkt_0z.7kJbAtOZdI- From: "Manav Bhatia" To: "'Acee Lindem'" , "'OSPF List'" Subject: RE: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended Date: Mon, 13 Nov 2006 23:47:45 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccHLA2DesGf7WgrTfCbzZse6bOP7AAI+54g In-Reply-To: <45587A54.1090309@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.9 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Message-Id: Acee, The minutes missed out my replies. > Presentation: Manav Bhatia - Crypto Requirements Document > NULL, MS5, sha1, cryptographic - refs in this doc > more algorithms keep coming eg des was once must, now is should ot > > What doc must, should, - running doc as algorithms come and go > uses 2119 terms should+ = should may become must > > See slides and draft for specific requirements. > > Acee: "should not" wording is problematic for NULL and other > existing requirements. Manav: NULL authentication is a "should NOT" in case an admin requires OSPF security. > Russ white: shold may become a must vs. should+ (better to say > what is meant) Manav: We have used these additional RFC2119 terms since the earlier cryptographic implementation requirement RFCs 4305, 4307 have used a similar language. Cheers, Manav > -----Original Message----- > From: Acee Lindem [mailto:acee@cisco.com] > Sent: Monday, November 13, 2006 7:30 PM > To: OSPF List > Subject: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct > file appended > > Here are the minutes from the 67th IETF OSPF WG meeting. Thanks > to Steve Nadas from Ericsson for taking them. > > There was quite a bit of dialog at the mike with respect to the > OSPF MANET direction. I've also appended Thomas Clausen's > jabber log. Please unicast corrections to me. IETF 67 > > Please unicast any corrections to me. > > Thanks, > Acee > Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 13 13:28:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgY8-0001mr-Us; Mon, 13 Nov 2006 13:28:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgY7-0001mc-MG for ospf@ietf.org; Mon, 13 Nov 2006 13:28:51 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjgY6-0001ib-CE for ospf@ietf.org; Mon, 13 Nov 2006 13:28:51 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 10:28:49 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="2209540:sNHT53737434" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kADISnnO020631; Mon, 13 Nov 2006 13:28:49 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kADISnDO005801; Mon, 13 Nov 2006 13:28:49 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:28:49 -0500 Received: from [10.82.208.5] ([10.82.208.5]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:28:48 -0500 Message-ID: <4558B95F.3060704@cisco.com> Date: Mon, 13 Nov 2006 13:28:47 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended References: <5g6uj4$1f5hn@sj-inbound-c.cisco.com> In-Reply-To: <5g6uj4$1f5hn@sj-inbound-c.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2006 18:28:48.0533 (UTC) FILETIME=[8F8AC450:01C70751] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1730; t=1163442529; x=1164306529; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20[OSPF]=20IETF=2067=20OSPF=20WG=20Meeting=20minutes=20 -=20Correct=20file=20appended |Sender:=20 |To:=20Manav=20Bhatia=20; bh=SYcnwJ4+MFvEFCyWSC0ONL/aKgPfpwuVIM4n41I2bto=; b=hdXGljIDiZWr6HiWVLsmu6uHufMXEpJ9CDFUU7Npk+XVZY+yvrprqstG3Ng/CAWsbknruIUs GL6JHOvbZx1vitJGl8yTg8Q+kQUXnYrbuuP+kzmPGg3xjD+0vz+bdBck; Authentication-Results: rtp-dkim-1; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: 'OSPF List' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Updated... Manav Bhatia wrote: > Acee, > > The minutes missed out my replies. > > >> Presentation: Manav Bhatia - Crypto Requirements Document >> > > >> NULL, MS5, sha1, cryptographic - refs in this doc >> more algorithms keep coming eg des was once must, now is should ot >> >> What doc must, should, - running doc as algorithms come and go >> uses 2119 terms should+ = should may become must >> >> See slides and draft for specific requirements. >> >> Acee: "should not" wording is problematic for NULL and other >> existing requirements. >> > > Manav: NULL authentication is a "should NOT" in case an admin requires OSPF > security. > > >> Russ white: shold may become a must vs. should+ (better to say >> what is meant) >> > > Manav: We have used these additional RFC2119 terms since the earlier > cryptographic implementation requirement RFCs 4305, 4307 have used a similar > language. > > Cheers, > Manav > > >> -----Original Message----- >> From: Acee Lindem [mailto:acee@cisco.com] >> Sent: Monday, November 13, 2006 7:30 PM >> To: OSPF List >> Subject: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct >> file appended >> >> Here are the minutes from the 67th IETF OSPF WG meeting. Thanks >> to Steve Nadas from Ericsson for taking them. >> >> There was quite a bit of dialog at the mike with respect to the >> OSPF MANET direction. I've also appended Thomas Clausen's >> jabber log. Please unicast corrections to me. IETF 67 >> >> Please unicast any corrections to me. >> >> Thanks, >> Acee >> >> > > Send instant messages to your online friends http://uk.messenger.yahoo.com > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 13 13:53:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjguc-00073G-Lx; Mon, 13 Nov 2006 13:52:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjgs3-00067o-Ft for ospf@ietf.org; Mon, 13 Nov 2006 13:49:27 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjgf9-0002fo-45 for ospf@ietf.org; Mon, 13 Nov 2006 13:36:11 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2006 10:35:59 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="344344251:sNHT3683980200" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kADIZxEa007470; Mon, 13 Nov 2006 10:35:59 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kADIZqOt008313; Mon, 13 Nov 2006 10:35:59 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:35:48 -0500 Received: from [10.82.208.5] ([10.82.208.5]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:35:48 -0500 Message-ID: <4558BB03.8090501@cisco.com> Date: Mon, 13 Nov 2006 13:35:47 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Richard Ogier Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended References: <45587A54.1090309@cisco.com> <45589EAA.6030305@earthlink.net> In-Reply-To: <45589EAA.6030305@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2006 18:35:48.0526 (UTC) FILETIME=[89E09CE0:01C70752] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2525; t=1163442959; x=1164306959; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20[OSPF]=20IETF=2067=20OSPF=20WG=20Meeting=20minutes=20 -=20Correct=20file=20appended |Sender:=20; bh=xGmoDeT1CTl+Ovfyn2FUCqkssGelcjENmgrMe76DrX4=; b=I4b9qBL2qh3PNe+OPC/DnYcg14E5JIgy6tOMpOoTu1Jdv1VypUfxaPBEOSgQQqmsQzHOA1IU dYHYPncsLMfXEthVFMXsdJH91z+/h4l54t71MySJZkT0QHf2+tWY6gpW; Authentication-Results: sj-dkim-8; header.From=acee@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Richard, I think we agreed upon a process to move along and we should continue to hold all the drafts to the same experimental publication criteria. I guess the point was that we should not limit the number to 2 if we're going to publish more than 1. Without injecting too much judgment on the MPR draft's maturity, did everyone at the meeting hear the same message? Thanks, Acee Richard Ogier wrote: >> Acee: Show hands on what should be done: >> - Quit working on OSPF MANET: none >> - Continue to drive to consensus: none >> - Refine drafts and publish as experimental: 2/3's of people >> in room. To be validated on list. > > > Acee, > > Correct me if I am wrong, but since the latest version of INRIA's > draft was available only last week, and since previous versions did > not fully specify the protocol (as pointed out by Phil Spagnolo in > his 9/28/06 post to the ospf-manet list), it has not yet been decided > that INRIA's draft will be published as experimental. > > Moreover, since INRIA has not participated in the GTNetS simulation > comparison that Boeing has been conducting for the last two > years, in which the MDR draft has been compared to Cisco's > OR/SP drafts (results can be found at Boeing's OSPF-MANET website > http://hipserver.mct.phantomworks.org/ietf/ospf/ ), > it is only fair that we should do such a comparison with INRIA's draft > before deciding to publish it as experimental. > > In fact, that has been the plan since the Dallas IETF meeting in March, > and Philippe agreed to this in his message of 4/5/06: > > Philippe Jacquet wrote on 4/5/06: > > Yes it would be great to synchronize our efforts on GTNet. > > Let's see how to proceed. > > Now, 7 months later, INRIA has implemented their solution in GTNetS, > so the next step would be for Boeing to work with INRIA to make > sure the code is debugged and implemented in a manner that allows > a fair comparison, just as Boeing has done with the OR/SP and > MDR solutions over the last two years. Hopefully, this work can > be completed by the next IETF meeting. > > I think it is reasonable and fair to require such a comparison > to be done before INRIA's draft is accepted, especially > since they promised to synchronize efforts 7 months ago. > Let me know if you agree or disagree. > IMO, to give INRIA a free pass and avoid such a comparison > would be unfair to those of us who worked hard for the last two > years on the GTNetS simulation effort. > > Richard > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 13 13:57:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgzP-00007d-Ox; Mon, 13 Nov 2006 13:57:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjgs1-0005yF-ES for ospf@ietf.org; Mon, 13 Nov 2006 13:49:25 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjgfb-0002kX-Qm for ospf@ietf.org; Mon, 13 Nov 2006 13:36:39 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 10:36:34 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="2218559:sNHT69381414" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kADIaY0n025210; Mon, 13 Nov 2006 13:36:34 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kADIaYDO008839; Mon, 13 Nov 2006 13:36:34 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:36:34 -0500 Received: from [10.82.208.5] ([10.82.208.5]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:36:33 -0500 Message-ID: <4558BB31.6070208@cisco.com> Date: Mon, 13 Nov 2006 13:36:33 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: GOODSPEED Don Subject: Re: [OSPF] Priority driven processing of ASE LSAs? References: <67FBA6A55FF15B46B8B572062529D26A10ACB3@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <67FBA6A55FF15B46B8B572062529D26A10ACB3@USDALSMBS03.ad3.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2006 18:36:33.0659 (UTC) FILETIME=[A4C75CB0:01C70752] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1314; t=1163442994; x=1164306994; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20[OSPF]=20Priority=20driven=20processing=20of=20ASE=20 LSAs? |Sender:=20 |To:=20GOODSPEED=20Don=20; bh=pXHAJuxLyzM2qj1WW9zX6sV50/j9hJDzhDFfj0Iu264=; b=opyXnJK6t+B3r+DOJez+3AaFFfMpablBiO5zsnPmRLveVGyFN+z1iykk2CHCmqTrGQ3pZzhM aIWdfpKAz1Bo9kfdXiI6af5PK3NnY4KASzw1MGAEW8mAsFsLFAnDLSLA; Authentication-Results: rtp-dkim-1; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Thanks Don - I agree totally, this is not an area subject to standardization. Acee GOODSPEED Don wrote: > Mukul, > > The ordering and such of how routes are installed in a FIB > (any forwarding table) is extremely vendor-specific (and > vendor-unique). As this is a vendor-agnostic forum, you > probably won't be receiving any responses (at least not > public ones). > > Cheers, > Don > > -----Original Message----- > From: mukul@uwm.edu [mailto:mukul@uwm.edu] > Sent: Monday, November 13, 2006 2:18 AM > To: ospf@ietf.org > Subject: [OSPF] Priority driven processing of ASE LSAs? > > Hi all, > > I apologize for this out-of-scope question. I know Cisco's IS-IS > implementation > supports priority-driven processing of advertised IP prefixes. > > http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_ > guide09186a00801b2285.html > > I was wondering if some OSPF implementations support similar > priority-driven > processing of ASE LSAs? > > Thanks, > Mukul Goyal > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 13 14:06:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjh8n-0000lS-OE; Mon, 13 Nov 2006 14:06:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjh8l-0000fO-L1 for ospf@ietf.org; Mon, 13 Nov 2006 14:06:43 -0500 Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjh8k-0007Xs-CG for ospf@ietf.org; Mon, 13 Nov 2006 14:06:43 -0500 Received: from dialup-4.243.137.150.dial1.sanfrancisco1.level3.net ([4.243.137.150] helo=earthlink.net) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1Gjh8d-0001n2-00; Mon, 13 Nov 2006 14:06:35 -0500 Message-ID: <4558C236.4040709@earthlink.net> Date: Mon, 13 Nov 2006 11:06:30 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Acee Lindem Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended References: <45587A54.1090309@cisco.com> <45589EAA.6030305@earthlink.net> <4558BB03.8090501@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Acee, I am not sure I understand what you mean. The MDR and OR/SP drafts have already been evaluated exensively via GTNetS simulations. INRIA's solution has not yet participated in any such evaluation. So if we require all the drafts to participate in the GTNetS evaluation (which was the original plan two years ago), then we *are* holding all drafts to the same experimental publication criteria. Or, are you saying that we should give INRIA a free pass to avoid participating in the GTNetS evaluation? I really don't think this would be fair, and therefore seriously doubt that the consensus would agree with this. I don't think the voting at the meeting clearly distinguished between the two options of accepting 2 versus 3 drafts. This distinction was not made explicit at the meeting. Richard Acee Lindem wrote: > Hi Richard, > I think we agreed upon a process to move along and we should > continue to hold all the drafts to the same experimental publication > criteria. I guess the point was that we should not limit the number to > 2 if we're going to publish more than 1. Without injecting too much > judgment > on the MPR draft's maturity, did everyone at the meeting hear the > same message? > > Thanks, > Acee > > Richard Ogier wrote: > >>> Acee: Show hands on what should be done: >>> - Quit working on OSPF MANET: none >>> - Continue to drive to consensus: none >>> - Refine drafts and publish as experimental: 2/3's of people >>> in room. To be validated on list. >> >> >> >> Acee, >> >> Correct me if I am wrong, but since the latest version of INRIA's >> draft was available only last week, and since previous versions did >> not fully specify the protocol (as pointed out by Phil Spagnolo in >> his 9/28/06 post to the ospf-manet list), it has not yet been decided >> that INRIA's draft will be published as experimental. >> >> Moreover, since INRIA has not participated in the GTNetS simulation >> comparison that Boeing has been conducting for the last two >> years, in which the MDR draft has been compared to Cisco's >> OR/SP drafts (results can be found at Boeing's OSPF-MANET website >> http://hipserver.mct.phantomworks.org/ietf/ospf/ ), >> it is only fair that we should do such a comparison with INRIA's draft >> before deciding to publish it as experimental. >> >> In fact, that has been the plan since the Dallas IETF meeting in March, >> and Philippe agreed to this in his message of 4/5/06: >> >> Philippe Jacquet wrote on 4/5/06: >> > Yes it would be great to synchronize our efforts on GTNet. >> > Let's see how to proceed. >> >> Now, 7 months later, INRIA has implemented their solution in GTNetS, >> so the next step would be for Boeing to work with INRIA to make >> sure the code is debugged and implemented in a manner that allows >> a fair comparison, just as Boeing has done with the OR/SP and >> MDR solutions over the last two years. Hopefully, this work can >> be completed by the next IETF meeting. >> >> I think it is reasonable and fair to require such a comparison >> to be done before INRIA's draft is accepted, especially >> since they promised to synchronize efforts 7 months ago. >> Let me know if you agree or disagree. >> IMO, to give INRIA a free pass and avoid such a comparison >> would be unfair to those of us who worked hard for the last two >> years on the GTNetS simulation effort. >> >> Richard >> > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 13 19:04:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjlm1-0003P1-Rp; Mon, 13 Nov 2006 19:03:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjlm0-0003Oo-Fn for ospf@ietf.org; Mon, 13 Nov 2006 19:03:32 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjllz-0007eI-3f for ospf@ietf.org; Mon, 13 Nov 2006 19:03:32 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2006 16:03:29 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAE03TCh020514; Mon, 13 Nov 2006 19:03:29 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAE03TDM010393; Mon, 13 Nov 2006 19:03:29 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 19:03:29 -0500 Received: from [10.82.208.5] ([10.82.208.5]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 19:03:29 -0500 Message-ID: <455907D0.5010706@cisco.com> Date: Mon, 13 Nov 2006 19:03:28 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: OSPF List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2006 00:03:29.0308 (UTC) FILETIME=[509DDDC0:01C70780] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2912; t=1163462609; x=1164326609; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Comments=20on=20draft-berger-ospf-rfc2370bis-00.txt |Sender:=20 |To:=20OSPF=20List=20; bh=46iV3mtq4HGZvl0Mz0PoOUCqurygaggFyiz4YfFuBTw=; b=yLvQKsch/W+hCmD40cdTveNDXEa3wGHPCWMdyptHwkDUYiy9Nzhw79nM53qfyqzTVUv5ybjh okEnsQCAsEoZ9aSfEo3d733KgCqmeoBr7eyIJp+F661clBapqWNZl1pB; Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Subject: [OSPF] Comments on draft-berger-ospf-rfc2370bis-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Lou, My main comment is on section 5 (6 is your draft). The draft adds mandatory reachability checking for AS scoped opaque LSAs. If we add mandatory reachability checking, it should be for all opaque types rather reading like the constraint is unique to AS scoped opaque LSAs (type 11s). I also think we should put the question as to whether the checking should be madatory or relaxed a bit to allow an application to check less frequently if the opaque data is stale. Detailed comments: Section 2, third paragraph - "aligned" rather than "qaligned". Section 3, "Section 7" rather than "Section 7." Section 3.1 - Type 9 LSA - "keep" rather than "keepk". I believe we should discard a link-local LSA received from a neighbor not on the interface (text similiar to type 11). Section 3.1, Since the area ID is not in the LSA header, the bullet on area flooding is confusing. It should say something to the effect of only flooding type 10 LSAs out interfaces in the LSA's associated area. I don't care if it said this in RFC 2370 and everyone knew what it implied. Section 3.1, 2nd to last paragraph: "An opaque" rather than "a opaque". Swap sections 5 and 6 since "inter-area" is more the "meat" of the draft. In fact, if the opaque MIB objects are all covered in the new MIB, we can probably remove the "management section". Section 6 (will be 5) 5. Opaque LSA Validation Opaque LSAs are not processed during the SPF calculation as described in section 16 of [OSPF]. However, they are subject to the same reachability constraints as the base LSA types. This implies that originating router MUST be reachable for the advertised application specific data to be considered valid. 5.1 Inter-Area Considerations ...... Section 5.1 Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem as a receiving router can detect an a loss of reachability through the intra-area SPF calculation. Section 5.1 To enable OSPF routers in remote areas to check availability of the originator of link-state type 11 opaque LSAs, the orignators of type-11 opaque LSAs are considered Autonomous System Border Routers (ASBRs) and will advertise themselves as such. Section 5.1 - Remove "It is important to note that this solution MUST NOT ..." This is redundant. Remove numbered items (1) and (2), these actions ARE NOT new to opaque LSAs. Make (3) a separate paragraph rather than numbered item. Section 10.1 - Correct NSSA reference to RFC 3101. Section 12.1 - Add D and MT bits with informative references to [RFC 4576] and the [OSPF-MT] drafts. "All eight bit ..." rather than "Six bits..". General - Replace "stub area" with "stub or NSSA areas". Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 13 19:07:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjlpU-0006E2-0L; Mon, 13 Nov 2006 19:07:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjlpS-0006Dx-G4 for ospf@ietf.org; Mon, 13 Nov 2006 19:07:06 -0500 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjlpR-00089U-4W for ospf@ietf.org; Mon, 13 Nov 2006 19:07:06 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XBoRvuFhq6JLsHiQGI8GW0k0uskbk1pww8vboiinKRD5NwqdOOf9jpySDSeNJn/i; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.159.38] (helo=earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GjlpL-0007Og-HR for ospf@ietf.org; Mon, 13 Nov 2006 19:06:59 -0500 Message-ID: <45590834.B988E949@earthlink.net> Date: Mon, 13 Nov 2006 16:05:08 -0800 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ospf@ietf.org Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79a519069e610f6de568fb91be4965c3d5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.159.38 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [OSPF] Comments / questions on RFC3623 and Update GR part 1 : BMA env X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Group, First, I have a few questions to the base and the update. These comments / questions pertain ONLY to BMA envs but are also relevelent to other envs. FYI) IMO, helpers are defined by two major requirements a) the ability to recieve a grace-LSA before a hello "new hello" and not restart the adj b) the ability of a helper "Y" to (re)send a router-LSA, etc upon router "X" exiting graceful restart that are in its retransmit-list. If this "helper" split functionality is supported, then only a limited number of routers within a area need to be in Full-helper mode. Within BMA envs a DR-other above helper "b" functionality is not really necessary for retransmit. We use the DR/BDR for retransmit support. IFFFFFFF, a GR router is the DR, who is in it grace-period, and a DR-other stops sending hellos, if their are no alternate paths thru another router for any forwarding data. Then what benefit is it to prematurely end helper mode? Basicly, most algs can determine ahead of time whether the exiting router has contributed a primary link/path. If it isn't then it has no consequence. Yes, data pkts that have a intermediate dest will be forwarded 1 or two extra hops, before they are dropped. (Update: 2.0 Action on route calculation) If a topology change occurs and the GR restarting router is identified as the next hop. By definition it is in non-stop forwarding mode and should be able to forward packets. If this is identified as a topology change and the ONLY route is thru this GR router, shouldn't packets be forwarded thru it anyway? Not doing so blackholes those routes, IMO. Thus, 1) Helpers should be able to be able to support a, without b If this is the case, router "X", if it is a DR should allow all the DR-others to support a, while only the BDR need be a "Full-Helper". 2) If router "X" is a DR-other only one of a "DR or BDR" need to be a Full-helper. All LSAs can be placed on the retransmit list of the for router "X" by the DR or BDR. 3) Topology change. A LSA aging out of the LSDB, will not necessarily remove a element in the forwarding table? If this can be detected, should it still force the exit of a helper wrt graceful restart? 4) If router "X" is a DR and has entered graceful restart with no BDR present, should the DR-other routers allow the LSAs to become not refreshed and aged out because the grace period has not expired. How can "one" or more "HELPERS" force a new DR election? 5) Even with a 30 min max for the grace period, some routers may only retransmit once every 45 mins or so. How can we guarantee that those retransmited-LSAs are not aged-out if router "X" is the DR and is down for a longer time? Shouldn't recieving the first grace-LSAs from a restarting router initiate a re-send of the LSAs? Mitchell Erblich _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 13 20:02:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjmg5-00053b-8L; Mon, 13 Nov 2006 20:01:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjmg3-00050q-W7 for ospf@ietf.org; Mon, 13 Nov 2006 20:01:28 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjmfz-00080x-Gk for ospf@ietf.org; Mon, 13 Nov 2006 20:01:27 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 17:01:22 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAE11M8L002756; Mon, 13 Nov 2006 20:01:22 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAE11MYJ006082; Mon, 13 Nov 2006 20:01:22 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 20:01:22 -0500 Received: from [10.82.208.5] ([10.82.208.5]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 20:01:21 -0500 Message-ID: <45591561.8060101@cisco.com> Date: Mon, 13 Nov 2006 20:01:21 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Richard Ogier Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended References: <45587A54.1090309@cisco.com> <45589EAA.6030305@earthlink.net> <4558BB03.8090501@cisco.com> <4558C236.4040709@earthlink.net> In-Reply-To: <4558C236.4040709@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2006 01:01:21.0692 (UTC) FILETIME=[66519DC0:01C70788] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4145; t=1163466082; x=1164330082; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20[OSPF]=20IETF=2067=20OSPF=20WG=20Meeting=20minutes=20 -=20Correct=20file=20appended |Sender:=20 |To:=20Richard=20Ogier=20; bh=i5PsgGT4oD3oxkQZ7TtpVL3Mb70fyqOErShLMSwSSXk=; b=jSWRz/FRkhruSUuv6So4goPhUz2u6NCE0xtEa/HUN9RPHxM3Zld5kRS3dU0VEYVquVwnjyKH henCixSXlWSc6gJevQHm5YPDazHKm9Ksw4DesSLePA3XJAZoDiZwH+OL; Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Richard, Richard Ogier wrote: > Acee, > > I am not sure I understand what you mean. The MDR and OR/SP > drafts have already been evaluated exensively via GTNetS > simulations. INRIA's solution has not yet participated > in any such evaluation. So if we require all the drafts > to participate in the GTNetS evaluation (which was the > original plan two years ago), then we *are* holding all > drafts to the same experimental publication criteria. GTNetS Simulation results were presented in San Diego so I believe MPRs have been implemented. The code should be made available for public inspection and comparison with the other drafts. > > Or, are you saying that we should give INRIA a free pass > to avoid participating in the GTNetS evaluation? > I really don't think this would be fair, and therefore > seriously doubt that the consensus would agree with this. I agree. > > I don't think the voting at the meeting clearly distinguished > between the two options of accepting 2 versus 3 drafts. > This distinction was not made explicit at the meeting. You are right that the question of 2 or 3 wasn't the primary focus of the dialog. While we've agreed to allow for more than one experimental draft, I don't think we should lower our standards. I don't think anyone who was at the meeting would disagree. Thanks, Acee > > Richard > > > Acee Lindem wrote: > >> Hi Richard, >> I think we agreed upon a process to move along and we should >> continue to hold all the drafts to the same experimental publication >> criteria. I guess the point was that we should not limit the number to >> 2 if we're going to publish more than 1. Without injecting too much >> judgment >> on the MPR draft's maturity, did everyone at the meeting hear the >> same message? >> >> Thanks, >> Acee >> >> Richard Ogier wrote: >> >>>> Acee: Show hands on what should be done: >>>> - Quit working on OSPF MANET: none >>>> - Continue to drive to consensus: none >>>> - Refine drafts and publish as experimental: 2/3's of >>>> people >>>> in room. To be validated on list. >>> >>> >>> >>> Acee, >>> >>> Correct me if I am wrong, but since the latest version of INRIA's >>> draft was available only last week, and since previous versions did >>> not fully specify the protocol (as pointed out by Phil Spagnolo in >>> his 9/28/06 post to the ospf-manet list), it has not yet been decided >>> that INRIA's draft will be published as experimental. >>> >>> Moreover, since INRIA has not participated in the GTNetS simulation >>> comparison that Boeing has been conducting for the last two >>> years, in which the MDR draft has been compared to Cisco's >>> OR/SP drafts (results can be found at Boeing's OSPF-MANET website >>> http://hipserver.mct.phantomworks.org/ietf/ospf/ ), >>> it is only fair that we should do such a comparison with INRIA's draft >>> before deciding to publish it as experimental. >>> >>> In fact, that has been the plan since the Dallas IETF meeting in March, >>> and Philippe agreed to this in his message of 4/5/06: >>> >>> Philippe Jacquet wrote on 4/5/06: >>> > Yes it would be great to synchronize our efforts on GTNet. >>> > Let's see how to proceed. >>> >>> Now, 7 months later, INRIA has implemented their solution in GTNetS, >>> so the next step would be for Boeing to work with INRIA to make >>> sure the code is debugged and implemented in a manner that allows >>> a fair comparison, just as Boeing has done with the OR/SP and >>> MDR solutions over the last two years. Hopefully, this work can >>> be completed by the next IETF meeting. >>> >>> I think it is reasonable and fair to require such a comparison >>> to be done before INRIA's draft is accepted, especially >>> since they promised to synchronize efforts 7 months ago. >>> Let me know if you agree or disagree. >>> IMO, to give INRIA a free pass and avoid such a comparison >>> would be unfair to those of us who worked hard for the last two >>> years on the GTNetS simulation effort. >>> >>> Richard >>> >> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 13 21:09:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjni4-0006CE-NJ; Mon, 13 Nov 2006 21:07:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjnhL-0005xJ-AK for ospf@ietf.org; Mon, 13 Nov 2006 21:06:51 -0500 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjnZi-0007yr-NA for ospf@ietf.org; Mon, 13 Nov 2006 20:59:00 -0500 Received: by py-out-1112.google.com with SMTP id f31so822957pyh for ; Mon, 13 Nov 2006 17:58:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=UYQiRsDYFCMKpGfI19CwUE4nWLIJpJBewL5JCyFn4N5pGxbUiYleAW3pxqnJIwGhCQQio3gYq9CxZNikark4d85mPKnt5tKi35bKarhZpM7oAqF6VycKSiXgg4CzXz8pgMDgW0Mt575woEYA/Fv6u1PKuh3ZQliLagIktZhLZIU= Received: by 10.35.49.1 with SMTP id b1mr639633pyk.1163469531651; Mon, 13 Nov 2006 17:58:51 -0800 (PST) Received: by 10.35.106.5 with HTTP; Mon, 13 Nov 2006 17:58:51 -0800 (PST) Message-ID: <96a9156a0611131758s7f281111y3eeb0fd309bce47d@mail.gmail.com> Date: Tue, 14 Nov 2006 02:58:51 +0100 From: "U. Nilrebmorf" To: ospf@ietf.org Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended In-Reply-To: <4558C236.4040709@earthlink.net> MIME-Version: 1.0 References: <45587A54.1090309@cisco.com> <45589EAA.6030305@earthlink.net> <4558BB03.8090501@cisco.com> <4558C236.4040709@earthlink.net> X-Spam-Score: 0.5 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0636349981==" Errors-To: ospf-bounces@ietf.org --===============0636349981== Content-Type: multipart/alternative; boundary="----=_Part_39443_27309227.1163469531410" ------=_Part_39443_27309227.1163469531410 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Richard, I was at the meeting. The consensus was that since simulations are not sufficient to decide for one solution over another, simulations are also not sufficient to exclude one solution. So it was decided to move on with 3 experimental. If I am not mistaken, it is read in the minutes from the meeting: "Acee: all authors have been attentive to comments. The 3 I-Ds should move forward to draft-ietf-ospf to go experimental." That's what the working group decided in the end. If you had been there maybe it would be clearer to you? Hope to see you at the next meeting. Nilreb On 11/13/06, Richard Ogier wrote: > > Acee, > > I am not sure I understand what you mean. The MDR and OR/SP > drafts have already been evaluated exensively via GTNetS > simulations. INRIA's solution has not yet participated > in any such evaluation. So if we require all the drafts > to participate in the GTNetS evaluation (which was the > original plan two years ago), then we *are* holding all > drafts to the same experimental publication criteria. > > Or, are you saying that we should give INRIA a free pass > to avoid participating in the GTNetS evaluation? > I really don't think this would be fair, and therefore > seriously doubt that the consensus would agree with this. > > I don't think the voting at the meeting clearly distinguished > between the two options of accepting 2 versus 3 drafts. > This distinction was not made explicit at the meeting. > > Richard > > > Acee Lindem wrote: > > > Hi Richard, > > I think we agreed upon a process to move along and we should > > continue to hold all the drafts to the same experimental publication > > criteria. I guess the point was that we should not limit the number to > > 2 if we're going to publish more than 1. Without injecting too much > > judgment > > on the MPR draft's maturity, did everyone at the meeting hear the > > same message? > > > > Thanks, > > Acee > > > > Richard Ogier wrote: > > > >>> Acee: Show hands on what should be done: > >>> - Quit working on OSPF MANET: none > >>> - Continue to drive to consensus: none > >>> - Refine drafts and publish as experimental: 2/3's of > people > >>> in room. To be validated on list. > >> > >> > >> > >> Acee, > >> > >> Correct me if I am wrong, but since the latest version of INRIA's > >> draft was available only last week, and since previous versions did > >> not fully specify the protocol (as pointed out by Phil Spagnolo in > >> his 9/28/06 post to the ospf-manet list), it has not yet been decided > >> that INRIA's draft will be published as experimental. > >> > >> Moreover, since INRIA has not participated in the GTNetS simulation > >> comparison that Boeing has been conducting for the last two > >> years, in which the MDR draft has been compared to Cisco's > >> OR/SP drafts (results can be found at Boeing's OSPF-MANET website > >> http://hipserver.mct.phantomworks.org/ietf/ospf/ ), > >> it is only fair that we should do such a comparison with INRIA's draft > >> before deciding to publish it as experimental. > >> > >> In fact, that has been the plan since the Dallas IETF meeting in March, > >> and Philippe agreed to this in his message of 4/5/06: > >> > >> Philippe Jacquet wrote on 4/5/06: > >> > Yes it would be great to synchronize our efforts on GTNet. > >> > Let's see how to proceed. > >> > >> Now, 7 months later, INRIA has implemented their solution in GTNetS, > >> so the next step would be for Boeing to work with INRIA to make > >> sure the code is debugged and implemented in a manner that allows > >> a fair comparison, just as Boeing has done with the OR/SP and > >> MDR solutions over the last two years. Hopefully, this work can > >> be completed by the next IETF meeting. > >> > >> I think it is reasonable and fair to require such a comparison > >> to be done before INRIA's draft is accepted, especially > >> since they promised to synchronize efforts 7 months ago. > >> Let me know if you agree or disagree. > >> IMO, to give INRIA a free pass and avoid such a comparison > >> would be unfair to those of us who worked hard for the last two > >> years on the GTNetS simulation effort. > >> > >> Richard > >> > > > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > ------=_Part_39443_27309227.1163469531410 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Richard,

I was at the meeting. The consensus was that since simulations are not sufficient to decide for one solution over another, simulations are also not sufficient to exclude one solution. So it was decided to move on with 3 experimental. If I am not mistaken, it is read in the minutes from the meeting:

"Acee: all authors have been attentive to comments. The 3 I-Ds should move forward to draft-ietf-ospf to go experimental."

That's what the working group decided in the end. If you had been there maybe it would be clearer to you?

Hope to see you at the next meeting.

Nilreb



On 11/13/06, Richard Ogier <ogier@earthlink.net > wrote:
Acee,

I am not sure I understand what you mean.  The MDR and OR/SP
drafts have already been evaluated exensively via GTNetS
simulations.  INRIA's solution has not yet participated
in any such evaluation. So if we require all the drafts
to participate in the GTNetS evaluation (which was the
original plan two years ago), then we *are* holding all
drafts to the same experimental publication criteria.

Or, are you saying that we should give INRIA a free pass
to avoid participating in the GTNetS evaluation?
I really don't think this would be fair, and therefore
seriously doubt that the consensus would agree with this.

I don't think the voting at the meeting clearly distinguished
between the two options of accepting 2 versus 3 drafts.
This distinction was not made explicit at the meeting.

Richard


Acee Lindem wrote:

> Hi Richard,
> I think we agreed upon a process to move along and we should
> continue to hold all the drafts to the same experimental publication
> criteria. I guess the point was that we should not limit the number to
> 2 if we're going to publish more than 1. Without injecting too much
> judgment
> on the MPR draft's maturity, did everyone at the meeting hear the
> same message?
>
> Thanks,
> Acee
>
> Richard Ogier wrote:
>
>>>      Acee: Show hands on what should be done:
>>>            - Quit working on OSPF MANET: none
>>>            - Continue to drive to consensus: none
>>>            - Refine drafts and publish as experimental: 2/3's of people
>>>              in room. To be validated on list.
>>
>>
>>
>> Acee,
>>
>> Correct me if I am wrong, but since the latest version of INRIA's
>> draft was available only last week, and since previous versions did
>> not fully specify the protocol (as pointed out by Phil Spagnolo in
>> his 9/28/06 post to the ospf-manet list), it has not yet been decided
>> that INRIA's draft will be published as experimental.
>>
>> Moreover, since INRIA has not participated in the GTNetS simulation
>> comparison that Boeing has been conducting for the last two
>> years, in which the MDR draft has been compared to Cisco's
>> OR/SP drafts (results can be found at Boeing's OSPF-MANET website
>> http://hipserver.mct.phantomworks.org/ietf/ospf/ ),
>> it is only fair that we should do such a comparison with INRIA's draft
>> before deciding to publish it as experimental.
>>
>> In fact, that has been the plan since the Dallas IETF meeting in March,
>> and Philippe agreed to this in his message of 4/5/06:
>>
>> Philippe Jacquet wrote on 4/5/06:
>> > Yes it would be great to synchronize our efforts on GTNet.
>> > Let's see how to proceed.
>>
>> Now, 7 months later, INRIA has implemented their solution in GTNetS,
>> so the next step would be for Boeing to work with INRIA to make
>> sure the code is debugged and implemented in a manner that allows
>> a fair comparison, just as Boeing has done with the OR/SP and
>> MDR solutions over the last two years.  Hopefully, this work can
>> be completed by the next IETF meeting.
>>
>> I think it is reasonable and fair to require such a comparison
>> to be done before INRIA's draft is accepted, especially
>> since they promised to synchronize efforts 7 months ago.
>> Let me know if you agree or disagree.
>> IMO, to give INRIA a free pass and avoid such a comparison
>> would be unfair to those of us who worked hard for the last two
>> years on the GTNetS simulation effort.
>>
>> Richard
>>
>
>



_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf

------=_Part_39443_27309227.1163469531410-- --===============0636349981== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0636349981==-- From yjchunzdu@dq.fct.unl.pt Tue Nov 14 01:56:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjsDE-0000XC-5P for ospf-archive@lists.ietf.org; Tue, 14 Nov 2006 01:56:04 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjsDE-0007fM-1A for ospf-archive@lists.ietf.org; Tue, 14 Nov 2006 01:56:04 -0500 Received: from dsl-241-229-73.telkomadsl.co.za ([41.241.229.73] helo=ctb-cache4-vif1.saix.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GjsD8-00020R-OS for ospf-archive@lists.ietf.org; Tue, 14 Nov 2006 01:56:03 -0500 Message-ID: <000b01c707b9$a5c035d0$0d00a8c0@ctb-cache4-vif1.saix.net> Reply-To: "emarsoun" From: "emarsoun" To: "urton" Subject: let's go Date: Tue, 14 Nov 2006 08:53:53 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C707B9.A5C035D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Score: 3.3 (+++) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C707B9.A5C035D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C707B9.A5C035D0" ------=_NextPart_001_0008_01C707B9.A5C035D0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable done. I have so ordered it, that no person in the ship shall receiveO = wonder! said Miranda, what noble creatures these are! It mustwent to the = queen's apartment, where the good lady was sitting with Polixenes and Camillo, both in disguise, arrived at the old = shepherd'sClaudio his promised bride and she wore a mask, that Claudio = mightmeaning to take him under his protection. and the true lovers, an unexpected messenger arrived to tell the duke take it, for I have often heard him say his Julia gave it to him. Ito me = as to a friend, but rather lend it to me as to an enemy, that,first = wife.drug going off, she awaked, and easily shaking off the slight Nor was Kent the only friend Lear had. In his degree, and as far asEdgar = the lawful heir from his earldom, and by his wicked practicesafter him. = The thought of this, and that they had defiled their hands moment he saw the countess of Rossilion, he began to talk of Helena, moment he saw the countess of Rossilion, he began to talk of Helena,words = and she said that she had given Bertram the ring he then wore,and tell = her I command her to come to me. The company had scarcelyWhen the married = Antipholis was denied entrance into his own house with Claudio, he would give her her brother's life for, said he,then, = forgetting her determination to go veiled for seven long years,sad looks = were observed by Orsino, who said to her, My life upon it, While he lived in this forlorn state, leading a life more brutal than man, he bore man's detested form and outward feature.even before their = hands were joined. But still more piteous it was tospirit or bad whether = it came for good or for evil but he graduallywhat you are. Nay, then, = said the queen, if you shew me so little her, and proved her to have a headstrong will and when her betterThis = discovery was as a thunderstroke to Othello, who now plainlycried, = Courage, good seamen, to the sailors, galling his princely revelled and feasted, and slew many of them, and recovered the spoil. of your country or did not our present please you we thought we = hadunfortunate mother and wife of Oedipus who ignorant of kin weddedone = that in no extremity would yield to fortune. Nine days was heseawanderer, = and to atone for the uncourteous treatment which those this Phaeacian vessel having put into that haven, by reason of theview = stood Mount Nerytus with all his woods so that now he knew for awere = heard, and a noise of the dogs fawning and leaping about as for remained for them, but that which their great Antinous had tasted! I proposed to draw lots, which formed a little amusement ofpointing = out instances of what he meant by those words, in the manners acquainted with my real parents.the truth, I might have had some = consolation in the praises which somy father's lifetime I never saw her = amuse herself in this way yet, the wonderful stories which were related of Mahomet were called A lady was sitting with mamma, and mamma said, I believe I mustwax to = stand for people that had done them any injury, or they thoughtof a = relation, and all that passed till I went with my father and ------=_NextPart_001_0008_01C707B9.A5C035D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

3D""


done. I have so ordered it, that no = person in the ship shall receiveO wonder! said Miranda, what noble = creatures these are! It mustwent to the queen's apartment, where the good = lady was sitting with
Polixenes and Camillo, both in disguise, arrived at the old = shepherd's  Claudio his promised bride and she wore a mask, = that Claudio might  meaning to take him under his = protection.
and the true lovers, an unexpected messenger arrived to tell the = duke         

take it, for I have often heard him say his Julia gave it to him. Ito = me as to a friend, but rather lend it to me as to an enemy, that,first = wife.drug going off, she awaked, and easily shaking off the slight
Nor was Kent the only friend Lear had. In his degree, and as far = as  Edgar the lawful heir from his earldom, and by his wicked = practices  after him. The thought of this, and that they had = defiled their hands
moment he saw the countess of Rossilion, he began to talk of = Helena,         

moment he saw the countess of Rossilion, he began to talk of = Helena,words and she said that she had given Bertram the ring he then = wore,and tell her I command her to come to me. The company had = scarcelyWhen the married Antipholis was denied entrance into his own = house
with Claudio, he would give her her brother's life for, said = he,  then, forgetting her determination to go veiled for seven = long years,  sad looks were observed by Orsino, who said to = her, My life upon it,
While he lived in this forlorn state, leading a life more brutal = than         

man, he bore man's detested form and outward feature.even before = their hands were joined. But still more piteous it was tospirit or bad = whether it came for good or for evil but he graduallywhat you are. Nay, = then, said the queen, if you shew me so little
her, and proved her to have a headstrong will and when her = better  This discovery was as a thunderstroke to Othello, who = now plainly  cried, Courage, good seamen, to the sailors, = galling his princely
revelled and feasted, and slew many of them, and recovered the = spoil.         
of your country or did not our present please you we thought we = hadunfortunate mother and wife of Oedipus who ignorant of kin weddedone = that in no extremity would yield to fortune. Nine days was heseawanderer, = and to atone for the uncourteous treatment which those
this Phaeacian vessel having put into that haven, by reason of = the  view stood Mount Nerytus with all his woods so that now he = knew for a  were heard, and a noise of the dogs fawning and = leaping about as for
remained for them, but that which their great Antinous had = tasted!          I proposed to draw lots, which formed a little amusement ofpointing = out instances of what he meant by those words, in the = manners       acquainted with my real parents.
the truth, I might have had some = consolation in the praises which so     my = father's lifetime I never saw her amuse herself in this way = yet,   the wonderful stories which were related of Mahomet were = called    
A lady was sitting with mamma, and mamma said, I believe I mustwax to = stand for people that had done them any injury, or they = thought    of a relation, and all that passed till I = went with my father and
------=_NextPart_001_0008_01C707B9.A5C035D0-- ------=_NextPart_000_0007_01C707B9.A5C035D0 Content-Type: image/gif; name="Wkx2Pz6GC9.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhCQIWAcIAAAQCBCSOBNQKLGRenCQSlKSKRAQC5Pz+/CwAAAAACQIWAQAD/ni63P4wykmr vTjrzbv/YCiOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16 v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYfASb mwucnQqfoKChBKWmB6Koog+soQ2opQyuqbG1s7anq7CZvXG2u56vDqS3w6mts8TKyMyywtDF0rnA x7m+2GnVzcPXyLux4cnQzs3U0eTm6uLc3u3Z8Grb88ng5N7b5cH31sym9t3S8XIXr+CXeZ88ufr3 il2thA+LpVul6pg5iN8aWtw3/s6gRzG0OOJ75nAkN1gYz50MhjAguggEP8q8YvLdMmMlO9YsdxFi Tpy6RkmIObOolJ0cBdo8OfEmL2XXGL6EejMfU6NYp+z8trDqqK48t0qlSrbsPU5Ps6pdy7at27dw 48qdS7eu3bt48+rdy7ev37+AAwsebCGAAsMnEBO+IkBFYweKDyAOQJlB5QaUL0vODDmyhMyKOS/Q LBmzZtATPIOebPlw5dWvRVv2bJo25g+oQdheDOQxCt+tRwuffXt4aNMVIh8nPjx46eYPVEN2Lr25 6t3Ps0fHDZ0Ddt41JB4ArkCA+QWP06M/v76xefbQlx+eT396/efftRenL9/6/oXqzmUHoIDB2VZd bvi5Rpps1M332minLQgeDxiV14Bv6o1noYYbkkeecQGydl+DIH4WgXL10aZcfiOuVmKLJPK3XYEl ipjgiARu9qJh8rE44QsVcojekBq6x+F77MEnZHEo7gjhZAzeeOKUTu4HYWpWvqjfiqRJGaCUItoI ZZSbnUbjbLL5+KML4nlIpJFGLslAkhDYKKCLW8r4JJlfUoeninWa2KeXA9oJm31VhqklovHByOia Pri5oZAYEvnmiQA2qZ2YjeK4qX+L5pjio7t1WSionvZY46iidvcpgf1BGgSS6SlZaXu4rhcdl/dx 2Z+hrioY2mVNupgmgyqi/oana2iGeKanZZKoaIpd4qjpsZrKeomaKnCr7bdEeIuCuOCWa+656Kar 7rrstuvuu/DGK++89NZr77345qsvbwP06++/AAcs8MAEF2zwwQgnrPDCDDfs8MMQRyzxxBQbHNgA bWH8lsZ/cayWx2yBzJfIRpGclcl5oSyTykWxbJfLBsH8kcxz0QyPzQXhDJfOZgDAA889+wB0xjAt g5ZCxBwdETVEdQDA0z4vAHXUFlDdgNUHTP0A1lJD3bXWDKCMILLZKrjnCWArkLbTEHDt9ddcq/12 1lPHPXTIRT/FdFrqTNT0BlZHHXjVac+dNQNYP7014mpLYPK1yAX7awmD/h8utQd1f321A5Uzfrnl jl88lDP0WKTPVCgI7vkEPscNOueMx1256wqQjF2xkgebeuOfA/766r/zLnzvltO+wN1rqZxP6Vdt hDrawxt/ueu0U6067J9n3oDtVOqpH6stXD98Bq23jXjhwEcvt+Fhi553P86385XSVo0wd+esU8+5 4sLLnv743AtUr1KFJnIRznr/wwD/sKe+17ktgXZzX96W5w+9xc90lGtgBdgXvOzVzW1rI94BAjij VxlIgLtz4Ac4iD/rhXB9C0wg8j42AZEoxCcWtAYtoKfCqo2vegyMgP/a9yg/5eaEJeQh/nz3uxYu TgJD3J4EYaKSqMSv/hpWtJ/nlgjFHwLvgSIE3RIfJ63pIPFVWsxeAhXoReKBcXxilOEUITCNsZyF FHvjWwjW9sK28bFwHOwh3RLHQbFh63s8MlaEqrVHw/XxAtqDoQtjyL5JXi2QI5zjHKQXgxmGgZMy 8CRWROkFUL6AlKUUmiZLtrNVtqyVgEFlJGQ5CVrOjGgbc+VMbDlLXa4Mlh3DpVt4GbOKGfOYyEym MpfJzGY6M5m+vGUuYynMavaFmIzApiO0eTNrJi+aHuFmNsEZM2D6RZyIQKci1NkLdkLBlC5w5ztV Sc2OnIUnDzEdRXBhgj/GkAIgXOAHuyhJUJosSBWaBj/D50hMsvF8/mAb6P4EGkkKyPMSB3WKNHSi N2D87aG846If3zY7woXRovZ0iPwW+owVlPSkkOyj+Mynxg1c1BIoo+BSSGdBgKRQpLBL3BY3GMcM kGwr69CIS14wU3gGVYgwdSMcLXDTSuSUpzvlRwV9qsQ1bk6oHsSk+CoaOqfgEyBjSQoLmso2IEry iSF9JASqSomrok6tWUVr80BwP69ecqL629xUO+iAg9KvKkldCUMRGNUNBhauUg3iBOhay9HtFK8q 7ZtQUsDWA0ZWsBB9oUEpoFaWsASfKuis0/5J2A6SdbAPoKwklKdDHGo0h5v9qV8Fq1q/Prasls3i PnuitPBpkAO9/pWscltb2Gji0Wgp1SpqMTfUxvK2gZ17I1ClaFaVZjYjesxgTWHrQ0FqULu7JWIw h/Ldf7CiuPA1qwj8acqK0vd/gXMod5MmkYRCN7yUayhrFcjHrTlSc6HFgGx7eQensmDBSHBwCyD8 CAoXQcIqsPCF6bneb06zwzT88Dm9GWIQn8yc1yTxievp4WFe7JkwjrGMZ0zjGtvYYeTMGYpHpuJR 5jgeGt5DkBcxZDsUGQ9HTmePWcniEi/5LkmeQ5TrMOVCVBkOV5ZDlgWxZRxgOAVd9jKHRwyBApjZ zAs4M5oZoGY2t1kBal4znM+cZjkfwM75o6R+lxtI6t3vtbGN/oCtgJOk98yp0EgqD6H5KuAvr5GQ eh7wIPMr6TD/AWUFYDOcNb3pNHv605l+QKg7fecG4Bmq42VuaBlrYMjOlKqCJrSsJ7XoSR16Tius LnkBCkgnmhe7cmyyqTk96lIbm9jIdkCxhw1qDSTXfGBdXBSLpwGTZahIFrp2reWUbUvt8bjkI6yv ufjSqVraD5hOdqeXbexih5rdx1a2uiEJbmhf8sCu3aJc93shWh/p37a+Vb8F/u1fs/G31w1juTt4 7j6kG9Rvjve6iR1nUsvb4vA2MKtV3TXQUnuqIh2tA2odp5In2lK0ytC1MSfQ9EIR4b0jt64ZrsuK T/zTFKez/sVxfvF4ZxzV251oZD8Y0AGLvN+XGo/Kce3vkQ/pQ9Q1OPlYC8IvapyigWw4Hx7O7GOz +92iDnuZ6xzx8gY94TJnHWQjQLKUd2jpKPd23KHONqk/NNpwPPu0j1dzsZPa3TwPPM9HDfau0zSk Lke8wdNud37buttI3zbBva0kJip+1wBtI8hX98Y1al3IEYD3sgmv853PuewRp/PXeR3p+t43iJZM cAVE9qE4MZ1WuXL7kioPuEazvNGCi2SB13dvtv84DY4+wedlkHwULD8Pz2fqz/LQfOUfPxvRN0P2 jfzkXV4fG9snQ/jpMP4vlD8M549D+rmwfi+03w03jr/8/udP//rbX2D7yr/+98///vv//wAYgAI4 gARYgAZ4gAiYgAq4gAw4Qvf3gBAYgRI4gQtjYg0IBu+3Bhl4gYFGZhyIfhb4gewXgiKoBRuYBidY gpnkgSpIAtVnfSyYSmohUZNGVPc2SX8maa/XgSkWYb6XeWu3g4dHgyGAEB7FX+FQXC2FhCjhUaoQ JBC0W9qzcJ81dJ5HgnSkD0e4EVYREwsnPcJHSTNXPRtXAjqFNKeTV+5wht+1V1HYWOVjdfmmcGM4 VxbIexdkDC21hXmodo13OL8VcvaGeR1whn2zV96FQc1TRfY0Ui0Hh8wVfH1Fh6nmOil4BiBzcog1 FVLB/g7MY4NBF4fLtXnYg4MvmENXpBTws1QooUcUsVF3J4VuVYr4VYc8yGOHhodLeIid+DziMVJV 2GprJ0J9BlOneFcVVFu6gIqtkFmYFW5/SHznA3QQ1GuVdod0t4v74FNJ8YsEdXaDpFySFjxEN4qF eEEVwRSndUNKuInPo4jfmF5j5Yd6N4y1g4VZKD+21YkhAY80BY6vhnf2aIwm0F9NkYqreBVsqIpN 84VA+GrAFnN8ZnwxWEPJuFS5dYhu2EMAqXlz2D8MBI4aUEd5mBIXuYhKGF/y5YiyJ0TWiHWUll3/ pF+XqH0Y8InbaEOK9XKtl2etJ4k5yHg1aAnHSAI1/lkGNVmUWaGUInCU4icGTEkvTjkGU9mAVQmC LdgFV4mBWamV+NiVUrCV5geWWyCW7keWJviVaOkEZumV9RKVY1mRgiGEqNaSQ+lxLUmES9CWIzgF GDJ5GzA2C1I22FIqUUI2sIEgsFdvN9hZS2R0MwcFfFmWfnlrj6cBkMMc1tIpzgI+Z2R2vtVEttg4 0waRbKmWR7Bo2gYfcDcoA9Qq4INCX2InukONkGg8UWSas7NvRjCZabkEkvJ0HZJ0KwctJuQqK/IZ A4IfyOJZjDmNh8d5JyWIpymXRgCY6lErhoZttlebuLOZkVMnsUKbxvmP8jiTVQc3LCRTT+CbWdBw /sU5nPEJJ9x2O3tCLEVUnl6yn/pJi9b1cR85kG/YBO6JBVrXnSinbXGXRKoSKpNjJQ36PRLqcc/m n3u3mKAlkkJQoFfweXT3l7nSdLuySK+pSMPCSGVyHWXTn3fZoldnikBJdZyHnuN4BBxqBTfaYOiG mukCl2dpnWspmTwapEmQo1RgpP6HpGFJgUzapE76pDVGpFI6pVRapVZ6pViapVq6pVzapV76pWAa pmI6pmRapmZ6pmiapmq6pmzapm4qZkDoAj4KlrzpUjFFadDJcWNQfRRlgwI6peShoTwUp/P4cXPa BHzqQn5qjlL6IX7GarGXoTAEWNIoqUWlOmAI/pNwFamM1TqQhkD8I2AI5qnFQ1Jew6nFWD6RepeT mKVQN46FWoaXSolFVXwgKTfk1anTWauxmpu4eqvRRqqXF6vj9UCqCqypRoglGJzCOKmkqZ4heavS mXfFWoq+WquxI5GzuqnRE1GPqWvEOqwW+laXKpBBCphPBKnYGq3ryqvsKqtxiF7tCojaqqvcaneh SqHIKq7tej0QuXGPCKiXaYXHBa/VaqnkeLA1Ja+yel77+q7TWq3lFq4A2nkVK63KCpYIeoN2CWks 6aIdF44aB1Eh+ajaKlk/+KhlmIMky5ENJUYBa7Gr6q2CqoLZGAOHCgPHmLMZ+6ZSwLPGlUZr/uWz RFu0Rnu0SJu0Sru0TNu0Tvu0UBu1Uju1VFu1Vnu1WJu1Wru1XNu1UGAAYBu2YNsAY0u2BgABZfsA aesAa4u2Ynu2Ziu2Zuu2cOu1bNC2a9u2B6C3e8u3fVu3cSsBYcsAaTu4C2C4f6u2fmu3ZaC3eQu4 fHu2kdu3aku5EYC3deu4mau5i8u4Y6C5c2u5ZKsAjku6gEu6pnu5pxu6bAu3knu6r+u5awC6hOu6 q7u5o5u6hHu4q8u7gtu7lhu7vtu5sgsGmKu4peu7h1u7u6u8ivu7bou6omu7xZsGb4u4cQu7rAu7 mcu6rQu9z7u3ulu2xFu9XVC4wEu+kHu9/oPLvu3rvr3buX5LvsPrvOZLBo8bvvILvKL7vdGruv+7 ueh7v2ZwvMxrv96bwAesuwzMwLQrvvZbvgScBQ/8wAqMwAvcv9iLvuvbvRHMvxO8BZFLvRfcvyWs wbf7tq0rt837vyH8wmkKvzI8wzRcwzZ8wziMvTC8wzzcwz78w0AcxEI8xG6Bm1wAtEQMsrlGj3+a eIsatFpgsXqapQ1bdwQVnVesBEhMAwBASH9VpjIpO12MpyA7xhXbxQB6dYZqxgjGW2yccCI7q586 PZUKqWhcx6LJrwYriqCarXQ8snE8xp66xfEysRB7eXLIVpxkr/aasP2qxx70rsQar5Z60MfZiqnU JoohS6+QjMifVahTfICGXMnJGpFkfMX+GlaWrLALe7DXqq70qqjk6j+UXMuO7EaCPMu5rK/8GsoG CMu3TLGJHJHUusmNnK7TCcvHXK8nq8meLG4qNDjAzMm1iLDZJa2E/C673MYR+8Z0I3RjhcbTbMxw Y5e9TKGrvMtibMmnTM3erM6D+Kx/7K4eWcwOdMdvPM5Yu8hODI1JTAk1C1L/PNAEXdAGfdAIndAK vdAM3dAO/dAQHdESPdEUXdEWfdEYndEavdEc3dFWmwAAOw== ------=_NextPart_000_0007_01C707B9.A5C035D0-- From ospf-bounces@ietf.org Tue Nov 14 11:52:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk1VF-0001Mg-Lz; Tue, 14 Nov 2006 11:51:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk1VE-0001MZ-2d for ospf@ietf.org; Tue, 14 Nov 2006 11:51:16 -0500 Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk1VB-0008RA-MB for ospf@ietf.org; Tue, 14 Nov 2006 11:51:16 -0500 Received: from dialup-4.243.131.37.dial1.sanfrancisco1.level3.net ([4.243.131.37] helo=earthlink.net) by pop-gadwall.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1Gk1V9-0001N7-00; Tue, 14 Nov 2006 11:51:12 -0500 Message-ID: <4559F3FB.6020402@earthlink.net> Date: Tue, 14 Nov 2006 08:51:07 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: "U. Nilrebmorf" Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended References: <45587A54.1090309@cisco.com> <45589EAA.6030305@earthlink.net> <4558BB03.8090501@cisco.com> <4558C236.4040709@earthlink.net> <96a9156a0611131758s7f281111y3eeb0fd309bce47d@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org U. Nilrebmorf wrote: > Hi Richard, > > I was at the meeting. The consensus was that since simulations are not > sufficient to decide for one solution over another, simulations are > also not sufficient to exclude one solution. I disagree with your reasoning. If we had 100 solutions, and simulations show that 10 of them perform much better than the other 90, then I think that might be a good way to exclude the 90 and keep only 10. Whereas by your reasoning we should keep all 100. Richard > So it was decided to move on with 3 experimental. If I am not > mistaken, it is read in the minutes from the meeting: > > "Acee: all authors have been attentive to comments. The 3 I-Ds should > move forward to draft-ietf-ospf to go experimental." > > That's what the working group decided in the end. If you had been > there maybe it would be clearer to you? > > Hope to see you at the next meeting. > > Nilreb > > > > On 11/13/06, Richard Ogier > wrote: > > Acee, > > I am not sure I understand what you mean. The MDR and OR/SP > drafts have already been evaluated exensively via GTNetS > simulations. INRIA's solution has not yet participated > in any such evaluation. So if we require all the drafts > to participate in the GTNetS evaluation (which was the > original plan two years ago), then we *are* holding all > drafts to the same experimental publication criteria. > > Or, are you saying that we should give INRIA a free pass > to avoid participating in the GTNetS evaluation? > I really don't think this would be fair, and therefore > seriously doubt that the consensus would agree with this. > > I don't think the voting at the meeting clearly distinguished > between the two options of accepting 2 versus 3 drafts. > This distinction was not made explicit at the meeting. > > Richard > > > Acee Lindem wrote: > > > Hi Richard, > > I think we agreed upon a process to move along and we should > > continue to hold all the drafts to the same experimental > publication > > criteria. I guess the point was that we should not limit the > number to > > 2 if we're going to publish more than 1. Without injecting too much > > judgment > > on the MPR draft's maturity, did everyone at the meeting hear the > > same message? > > > > Thanks, > > Acee > > > > Richard Ogier wrote: > > > >>> Acee: Show hands on what should be done: > >>> - Quit working on OSPF MANET: none > >>> - Continue to drive to consensus: none > >>> - Refine drafts and publish as experimental: 2/3's > of people > >>> in room. To be validated on list. > >> > >> > >> > >> Acee, > >> > >> Correct me if I am wrong, but since the latest version of INRIA's > >> draft was available only last week, and since previous versions did > >> not fully specify the protocol (as pointed out by Phil Spagnolo in > >> his 9/28/06 post to the ospf-manet list), it has not yet been > decided > >> that INRIA's draft will be published as experimental. > >> > >> Moreover, since INRIA has not participated in the GTNetS simulation > >> comparison that Boeing has been conducting for the last two > >> years, in which the MDR draft has been compared to Cisco's > >> OR/SP drafts (results can be found at Boeing's OSPF-MANET website > >> http://hipserver.mct.phantomworks.org/ietf/ospf/ ), > >> it is only fair that we should do such a comparison with > INRIA's draft > >> before deciding to publish it as experimental. > >> > >> In fact, that has been the plan since the Dallas IETF meeting > in March, > >> and Philippe agreed to this in his message of 4/5/06: > >> > >> Philippe Jacquet wrote on 4/5/06: > >> > Yes it would be great to synchronize our efforts on GTNet. > >> > Let's see how to proceed. > >> > >> Now, 7 months later, INRIA has implemented their solution in > GTNetS, > >> so the next step would be for Boeing to work with INRIA to make > >> sure the code is debugged and implemented in a manner that allows > >> a fair comparison, just as Boeing has done with the OR/SP and > >> MDR solutions over the last two years. Hopefully, this work can > >> be completed by the next IETF meeting. > >> > >> I think it is reasonable and fair to require such a comparison > >> to be done before INRIA's draft is accepted, especially > >> since they promised to synchronize efforts 7 months ago. > >> Let me know if you agree or disagree. > >> IMO, to give INRIA a free pass and avoid such a comparison > >> would be unfair to those of us who worked hard for the last two > >> years on the GTNetS simulation effort. > >> > >> Richard > >> > > > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > > >------------------------------------------------------------------------ > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > >------------------------------------------------------------------------ > >Internal Virus Database is out-of-date. >Checked by AVG Free Edition. >Version: 7.1.394 / Virus Database: 268.13.22/512 - Release Date: 11/1/2006 > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Nov 14 12:06:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk1js-0008Cc-GU; Tue, 14 Nov 2006 12:06:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk1jr-0008CX-HV for ospf@ietf.org; Tue, 14 Nov 2006 12:06:23 -0500 Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk1jp-0002Bz-6f for ospf@ietf.org; Tue, 14 Nov 2006 12:06:23 -0500 Received: from dialup-4.243.131.37.dial1.sanfrancisco1.level3.net ([4.243.131.37] helo=earthlink.net) by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1Gk1QC-0004QL-00; Tue, 14 Nov 2006 11:46:05 -0500 Message-ID: <4559F2C7.4020800@earthlink.net> Date: Tue, 14 Nov 2006 08:45:59 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Acee Lindem Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended References: <45587A54.1090309@cisco.com> <45589EAA.6030305@earthlink.net> <4558BB03.8090501@cisco.com> <4558C236.4040709@earthlink.net> <45591561.8060101@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Acee Lindem wrote: > Hi Richard, > Richard Ogier wrote: > >> Acee, >> >> I am not sure I understand what you mean. The MDR and OR/SP >> drafts have already been evaluated exensively via GTNetS >> simulations. INRIA's solution has not yet participated >> in any such evaluation. So if we require all the drafts >> to participate in the GTNetS evaluation (which was the >> original plan two years ago), then we *are* holding all >> drafts to the same experimental publication criteria. > > GTNetS Simulation results were presented in San Diego so I believe > MPRs have been implemented. The code should be made available for > public inspection and comparison with the other drafts. We seem to be in agreement. The question is, when will INRIA make their (up-to-date) code available to allow a fair comparison. The reason I am concerned is because I don't want to see a repeat of the MANET debate between OLSR and TBRPF, in which there was no cooperation to allow a fair comparison. (I will avoid giving the details here, since it might result in more arguing.) One of the reasons I decided to work on the MDR design is because there was a good plan for comparing the performance of the different proposals (using GTNetS). Richard > > >> >> Or, are you saying that we should give INRIA a free pass >> to avoid participating in the GTNetS evaluation? >> I really don't think this would be fair, and therefore >> seriously doubt that the consensus would agree with this. > > I agree. > >> >> I don't think the voting at the meeting clearly distinguished >> between the two options of accepting 2 versus 3 drafts. >> This distinction was not made explicit at the meeting. > > You are right that the question of 2 or 3 wasn't the primary > focus of the dialog. While we've agreed to allow for more > than one experimental draft, I don't think we should lower > our standards. I don't think anyone who was at the meeting > would disagree. > Thanks, > Acee > > >> >> Richard >> >> >> Acee Lindem wrote: >> >>> Hi Richard, >>> I think we agreed upon a process to move along and we should >>> continue to hold all the drafts to the same experimental publication >>> criteria. I guess the point was that we should not limit the number to >>> 2 if we're going to publish more than 1. Without injecting too much >>> judgment >>> on the MPR draft's maturity, did everyone at the meeting hear the >>> same message? >>> >>> Thanks, >>> Acee >>> >>> Richard Ogier wrote: >>> >>>>> Acee: Show hands on what should be done: >>>>> - Quit working on OSPF MANET: none >>>>> - Continue to drive to consensus: none >>>>> - Refine drafts and publish as experimental: 2/3's of >>>>> people >>>>> in room. To be validated on list. >>>> >>>> >>>> >>>> >>>> Acee, >>>> >>>> Correct me if I am wrong, but since the latest version of INRIA's >>>> draft was available only last week, and since previous versions did >>>> not fully specify the protocol (as pointed out by Phil Spagnolo in >>>> his 9/28/06 post to the ospf-manet list), it has not yet been decided >>>> that INRIA's draft will be published as experimental. >>>> >>>> Moreover, since INRIA has not participated in the GTNetS simulation >>>> comparison that Boeing has been conducting for the last two >>>> years, in which the MDR draft has been compared to Cisco's >>>> OR/SP drafts (results can be found at Boeing's OSPF-MANET website >>>> http://hipserver.mct.phantomworks.org/ietf/ospf/ ), >>>> it is only fair that we should do such a comparison with INRIA's draft >>>> before deciding to publish it as experimental. >>>> >>>> In fact, that has been the plan since the Dallas IETF meeting in >>>> March, >>>> and Philippe agreed to this in his message of 4/5/06: >>>> >>>> Philippe Jacquet wrote on 4/5/06: >>>> > Yes it would be great to synchronize our efforts on GTNet. >>>> > Let's see how to proceed. >>>> >>>> Now, 7 months later, INRIA has implemented their solution in GTNetS, >>>> so the next step would be for Boeing to work with INRIA to make >>>> sure the code is debugged and implemented in a manner that allows >>>> a fair comparison, just as Boeing has done with the OR/SP and >>>> MDR solutions over the last two years. Hopefully, this work can >>>> be completed by the next IETF meeting. >>>> >>>> I think it is reasonable and fair to require such a comparison >>>> to be done before INRIA's draft is accepted, especially >>>> since they promised to synchronize efforts 7 months ago. >>>> Let me know if you agree or disagree. >>>> IMO, to give INRIA a free pass and avoid such a comparison >>>> would be unfair to those of us who worked hard for the last two >>>> years on the GTNetS simulation effort. >>>> >>>> Richard >>>> >>> >>> >> > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Nov 14 12:36:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2Cs-0003rF-9H; Tue, 14 Nov 2006 12:36:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2Cq-0003r9-So for ospf@ietf.org; Tue, 14 Nov 2006 12:36:20 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk2Cn-0006Vl-Iz for ospf@ietf.org; Tue, 14 Nov 2006 12:36:20 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id kAEHa7a1011073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Nov 2006 09:36:07 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kAEHa6rk018055; Tue, 14 Nov 2006 09:36:07 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kAEHa4TH017957; Tue, 14 Nov 2006 09:36:06 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 09:36:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended Date: Tue, 14 Nov 2006 09:36:05 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F948@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <45591561.8060101@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended Thread-Index: AccHiXRFj1b24hcOSE2Ij020tZ8rQwAiUFAQ From: "Henderson, Thomas R" To: "Acee Lindem" , "Richard Ogier" X-OriginalArrivalTime: 14 Nov 2006 17:36:06.0581 (UTC) FILETIME=[5D48EE50:01C70813] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org =20 > -----Original Message----- > From: Acee Lindem [mailto:acee@cisco.com]=20 > Sent: Monday, November 13, 2006 5:01 PM > To: Richard Ogier > Cc: OSPF List > Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct=20 > file appended >=20 > Hi Richard, > Richard Ogier wrote: > > Acee, > > > > I am not sure I understand what you mean. The MDR and OR/SP > > drafts have already been evaluated exensively via GTNetS > > simulations. INRIA's solution has not yet participated > > in any such evaluation. So if we require all the drafts > > to participate in the GTNetS evaluation (which was the > > original plan two years ago), then we *are* holding all > > drafts to the same experimental publication criteria. > > GTNetS Simulation results were presented in San Diego so I believe > MPRs have been implemented. The code should be made available for > public inspection and comparison with the other drafts. >=20 > > > > Or, are you saying that we should give INRIA a free pass > > to avoid participating in the GTNetS evaluation? > > I really don't think this would be fair, and therefore > > seriously doubt that the consensus would agree with this. > > I agree. > > > > > I don't think the voting at the meeting clearly distinguished > > between the two options of accepting 2 versus 3 drafts. > > This distinction was not made explicit at the meeting. > > You are right that the question of 2 or 3 wasn't the primary > focus of the dialog. While we've agreed to allow for more > than one experimental draft, I don't think we should lower > our standards. I don't think anyone who was at the meeting > would disagree. > Thanks, > Acee >=20 Acee, I agree with all of your above responses. Tom _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Nov 14 15:18:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4hv-0003Hh-BY; Tue, 14 Nov 2006 15:16:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4ht-0003H6-Fk; Tue, 14 Nov 2006 15:16:33 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk4hs-0005A0-Md; Tue, 14 Nov 2006 15:16:33 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 14 Nov 2006 12:16:31 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAEKGV8k003897; Tue, 14 Nov 2006 15:16:31 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAEKGSYL008152; Tue, 14 Nov 2006 15:16:30 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 15:16:30 -0500 Received: from [10.82.208.5] ([10.82.208.5]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 15:16:29 -0500 Message-ID: <455A241B.50906@cisco.com> Date: Tue, 14 Nov 2006 15:16:27 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Peter Psenak References: <20061030165712.GA6104@boskop.local> <45465B70.2040000@cisco.com> <45472FBA.8000705@cisco.com> In-Reply-To: <45472FBA.8000705@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2006 20:16:29.0561 (UTC) FILETIME=[C5072690:01C70829] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14080; t=1163535391; x=1164399391; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20secdir=20review=20of=20draft-ietf-ospf-mt-06.txt |Sender:=20 |To:=20Peter=20Psenak=20; bh=JjR8ZOx9ETfnH6Cr5kYTiymWWYdJ4wfP9VhETxvM9bU=; b=z1DBTMJrvT5Z/y/0r3mWlFhx9CISUtl/VjAkpDaY9AtKSM75LdxqD4SwUBxLa+9lhOgkO5UJ 35cfPaNUZBAlgTUKOqHJ4mrfUbmacoTccHnDWzCGQvQe5MBiO3unEX3n; Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Cc: j.schoenwaelder@iu-bremen.de, secdir@mit.edu, ospf@ietf.org, iesg@ietf.org Subject: [OSPF] Re: secdir review of draft-ietf-ospf-mt-06.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Peter, Juergen, Some additional comments. See inline. Peter Psenak wrote: > Hi Juergen, > > please see inline: > > Peter Psenak wrote: > >> >> >> Juergen Schoenwaelder wrote: >> >>> Hi! >>> >>> As part of the security directorate review effort, I was asked to >>> review draft-ietf-ospf-mt-06 and below is my report. >>> >>> The document specifies how OSPF can be used multiple independent IP >>> topologies. The security considerations simply point to the security >>> considerations in RFC 2328 (the OSPF spec) which explains how OSPF >>> authentication works (by pointing to the relevant portions of the >>> spec). I do not really see a problem with this approach for this OSPF >>> extension and find it adequate. >>> >>> While reviewing the document, I found (besides editorial issues) two >>> things that remain rather unclear to me (and which I would love to get >>> clarified): >>> >>> - The IANA considerations confused me. What is IANA expected to do? > > We have received comment from IANA and we agreed that we will state in > the IANA considerations that we do NOT want IANA to manage the MT space. The 07 version will clearly state the entire range is defined and, therefore, no IANA action is required. > >>> >>> - Question: Will the MIB interfaces still work with the MT extension >>> or are extensions to the OSPF-MIB needed to support OSPF-MT? > > MIB interface should work as today what regards to the base topology. > draft-rawat-ospf-mt-mib-01.txt has been submitted to extend the OSPFv2 > MIB to support multiple topologies. I don't think I need to reference the new OSPF-MT MIB extensions in this document. Of course, the OSPF-MT MIB document references this document. Thanks, Acee > >>> >>> Editorial: > > we will include below comments/corrections in the next version. > > thanks, > Peter > >>> >>> - Avoid acronyms and references in the abstract. >>> >>> - Some references use RFC number style, others to not. You may want to >>> use a consistent approach. >>> >>> - There are a number of missing articles and such things. Rather than >>> writing this up in details, I edited the document and I am attaching >>> a unified context diff with the delta. >>> >>> --- ./draft-ietf-ospf-mt-06.txt 2006-02-01 21:46:37.000000000 +0100 >>> +++ ./draft-ietf-ospf-mt-06-hacked.txt 2006-10-30 >>> 17:33:35.000000000 +0100 >>> @@ -188,10 +188,10 @@ >>> Multi-topology routing differs from RFC 1583 TOS based routing >>> in the >>> following ways: >>> >>> - 1. With RFC 1583 TOS routing, the TOS or DSCP in the IP header is >>> - mapped directly to the the corresponding OSPF SPF >>> calculation and >>> + 1. With RFC 1583 TOS routing, the TOS or DSCP value in the IP >>> header is >>> + mapped directly to the corresponding OSPF SPF calculation and >>> routing table. This limits the number and definition of the >>> - topologies to the 16 TOS values specified is section 12.3 of >>> RFC >>> + topologies to the 16 TOS values specified in section 12.3 of >>> RFC >>> 1583 [RFC1583]. With multi-topology routing, the >>> classification >>> of what type of traffic maps to which topology is not within >>> the >>> scope of the document. >>> @@ -324,9 +324,9 @@ >>> to a set of MTs, it will advertise the corresponding cost for each >>> MT-ID. >>> >>> - By default, all links are included in default topology and all >>> + By default, all links are included in the default topology and all >>> advertised prefixes belonging to the default topology will use the >>> - TOS0 metric the same as in standard OSPF [OSPF]. >>> + TOS0 metric, the same as in standard OSPF [OSPF]. >>> >>> Each MT has its own MT-ID metric field. When a link is not part >>> of a >>> >>> @@ -339,8 +339,9 @@ >>> >>> given MT, the corresponding MT-ID metric is excluded from the LSA. >>> >>> - The Network-LSA does not contain any MT information since the DR is >>> - shared by all MTs. Hence, there is no change to the Network-LSA. >>> + The Network-LSA does not contain any MT information since the >>> + Distinguished Router (DR) is shared by all MTs. Hence, there is no >>> + change to the Network-LSA. >>> >>> 3.4.2 Inter-Area and External Routing >>> >>> @@ -409,7 +410,7 @@ >>> >>> 3.8 Forwarding in MT >>> >>> - It's outside of the scope of this document to specify how the >>> + It is outside of the scope of this document to specify how the >>> information in various topology specific forwarding structures are >>> used during packet forwarding or how incoming packets are >>> associated >>> with the corresponding topology. For correct operation, both >>> @@ -456,7 +457,7 @@ >>> from the default topology and reserve them for some specific >>> classes >>> of traffic. >>> >>> - The multi-topologies extension for default topology link or prefix >>> + The multi-topologies extension for the default topology link or >>> prefix >>> exclusion is described in the following subsections. >>> >>> 4.1 Exclusion of Links in the Default Topology >>> @@ -467,7 +468,7 @@ >>> Router-LSAs in the default topology and to alternately use the MT- >>> ID#0 metric to advertise the metric associated with the default >>> topology. Hence, all routers within an area MUST agree on how the >>> - metric for default topology will be advertised. >>> + metric for the default topology will be advertised. >>> >>> The unused T-bit is defined as the MT-bit in the option field in >>> order to assure that a multi-topology link-excluding capable >>> router >>> @@ -478,7 +479,7 @@ >>> |DN |O |DC |EA |NP |MC |E |MT | >>> +---+---+---+---+---+---+---+---+ >>> >>> - MT-bit: If DefaultExclusionCapability is enable, this bit MUST >>> + MT-bit: If DefaultExclusionCapability is enabled, the MT bit >>> MUST >>> be set in Hello packets and SHOULD be set in Database >>> Description packet (see Section 4.2). >>> >>> @@ -519,10 +520,10 @@ >>> If DefaultExclusionCapability is enabled: >>> >>> o The MT-bit MUST be set in Hello and SHOULD be set in Database >>> - Description packets >>> + Description packets. >>> >>> o The router will only accept a Hello packet if the MT-bit is set >>> - (see Section 4.3) >>> + (see Section 4.3). >>> >>> When DefaultExclusionCapability is set to enabled a router is >>> said to >>> be operating in DefaultExclusionCapability mode. >>> @@ -532,9 +533,9 @@ >>> In order to have a smooth transition from a non-MT area to an MT- >>> area, an MT router with DefaultExclusionCapability disabled will >>> form >>> adjacencies with non-MT routers and will include all links as >>> part of >>> - default topology. >>> + the default topology. >>> >>> - A link may cease participating in default topology if >>> + A link may cease participating in the default topology if >>> DefaultExclusionCapability is set to enabled. In this state, a >>> router will only form adjacency with routers that set the MT-bit in >>> their Hello packets. This will ensure that all routers have >>> @@ -545,7 +546,7 @@ >>> modified as follows: >>> >>> o If the DefaultExclusionCapability in the Area Data structure is >>> - set to enabled, Hello packets are discarded if the the received >>> + set to enabled, Hello packets are discarded if the received >>> packet does not have the MT-bit set in the header options. >>> >>> Receiving OSPF Database Description packets as defined in section >>> @@ -574,13 +575,13 @@ >>> >>> 4.5 OSPF LSA Advertisement and SPF Computation for Excluded Links >>> >>> - When DefaultExclusionCapability is enabled and the link does not >>> + When the DefaultExclusionCapability is enabled and the link does >>> not >>> participate in the default topology, the MT-ID#0 metric is not >>> advertised. The link's TOS0 metric is ignored during the default >>> topology SPF computation. >>> >>> - When DefaultExclusionCapability is enabled and a link >>> participates in >>> - the default topology, MT-ID#0 metric is used to advertise the >>> metric >>> + When the DefaultExclusionCapability is enabled and a link >>> participates in >>> + the default topology, the MT-ID#0 metric is used to advertise >>> the metric >>> associated with the default topology. The link's TOS0 metric is >>> ignored during the default topology SPF computation. >>> >>> @@ -590,7 +591,7 @@ >>> o If the prefix or router does not exist in the default topology, >>> the TOS0 metric is set to infinity (0xFFFFFF). >>> >>> - o If the prefix or router exists in default the topology, the TOS0 >>> + o If the prefix or router exists in the default the topology, >>> the TOS0 >>> metric is used to advertise the metric in the default topology. >>> >>> During the summary and external prefix calculation for the default >>> @@ -698,10 +699,10 @@ >>> interaction required with non-MT routers. In this mode, the >>> default topology can be excluded on links as required. >>> >>> - 3. If there is more than one non-backbone areas where MT is being >>> - used, it is desirable that the backbone area first be >>> upgraded to >>> - be MT capable so that inter-area routing is assured for MT >>> - destinations in different areas. >>> + 3. If there are multiple (more than one) non-backbone areas where >>> + MT is being used, it is desirable that the backbone area first >>> + be upgraded to be MT capable so that inter-area routing is >>> + assured for MT destinations in different areas. >>> >>> 4. Gradually the whole network can be made MT capable. >>> >>> @@ -1019,7 +1020,7 @@ >>> router-LSA. The LSA describes the state and cost of the router's >>> links (i.e., interfaces) to the area. All of the router's links to >>> the area must be described in a single router-LSA. For details >>> - concerning the construction of router-LSAs, see Section 12.4.1 >>> + concerning the construction of router-LSAs, see Section 12.4.1 of >>> [OSPF]. >>> >>> >>> @@ -1078,7 +1079,7 @@ >>> The distance from the network to all attached routers is zero. >>> This >>> is why metric fields need not be specified in the network-LSA. For >>> details concerning the construction of network-LSAs, see Section >>> - 12.4.2 [OSPF]. >>> + 12.4.2 of [OSPF]. >>> >>> >>> 0 1 2 3 >>> @@ -1101,7 +1102,7 @@ >>> | ... | >>> >>> Note that network LSA does not contain any MT-ID fields as the cost >>> - of the network to the attached routers is 0 and DR is shared by all >>> + of the network to the attached routers is 0 and the DR is shared >>> by all >>> topologies. >>> >>> B.3 Summary-LSAs >>> @@ -1109,7 +1110,7 @@ >>> Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are >>> originated by >>> area border routers. Summary-LSAs describe inter-area >>> destinations. >>> For details concerning the construction of summary- LSAs, see >>> Section >>> - 12.4.3 [OSPF]. >>> + 12.4.3 of [OSPF]. >>> >>> Type 3 summary-LSAs are used when the destination is an IP network. >>> In this case the LSA's Link State ID field is an IP network number >>> @@ -1122,7 +1123,7 @@ >>> >>> >>> (if necessary, the Link State ID can also have one or more of the >>> - network's "host" bits set; see Appendix E [OSPF] for details). >>> When >>> + network's "host" bits set; see Appendix E of [OSPF] for >>> details). When >>> the destination is an AS boundary router, a Type 4 summary-LSA is >>> used, and the Link State ID field is the AS boundary router's OSPF >>> Router ID. (To see why it is necessary to advertise the >>> location of >>> @@ -1161,12 +1162,12 @@ >>> AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by >>> AS boundary routers, and describe destinations external to the AS. >>> For details concerning the construction of AS-external-LSAs, see >>> - Section 12.4.3 [OSPF]. >>> + Section 12.4.3 of [OSPF]. >>> >>> AS-external-LSAs usually describe a particular external >>> destination. >>> For these LSAs the Link State ID field specifies an IP network >>> number >>> (if necessary, the Link State ID can also have one or more of the >>> - network's "host" bits set; see Appendix E [OSPF] for details). AS- >>> + network's "host" bits set; see Appendix E of [OSPF] for >>> details). AS- >>> external-LSAs are also used to describe a default route. Default >>> routes are used when no specific route exists to the destination. >>> >>> @@ -1178,7 +1179,7 @@ >>> >>> >>> When describing a default route, the Link State ID is always set to >>> - DefaultDestination (0.0.0.0) and the Network Mask is set to >>> 0.0.0.0. >>> + the DefaultDestination (0.0.0.0) and the Network Mask is set to >>> 0.0.0.0. >>> >>> >>> 0 1 2 3 >>> @@ -1224,7 +1225,7 @@ >>> boundary routers local to an NSSA, and describe destinations >>> external >>> to the AS. The changes to NSSA-LSAs are identical to those for >>> External-LSAs (Appendix A.4.5). For details concerning the >>> - construction of NSSA-LSAs see Section 2.4 [NSSA]. >>> + construction of NSSA-LSAs see Section 2.4 of [NSSA]. >>> >>> /js >>> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Nov 14 17:28:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk6kf-000225-8x; Tue, 14 Nov 2006 17:27:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk6ke-00021z-KK for ospf@ietf.org; Tue, 14 Nov 2006 17:27:32 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk6kd-0001c0-8j for ospf@ietf.org; Tue, 14 Nov 2006 17:27:32 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 14 Nov 2006 14:27:30 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAEMRTsu025377 for ; Tue, 14 Nov 2006 17:27:29 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAEMRSYN017869 for ; Tue, 14 Nov 2006 17:27:29 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 17:27:29 -0500 Received: from [10.82.208.5] ([10.82.208.5]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 17:27:29 -0500 Message-ID: <455A42D0.8090100@cisco.com> Date: Tue, 14 Nov 2006 17:27:28 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: OSPF List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2006 22:27:29.0615 (UTC) FILETIME=[11FC35F0:01C7083C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1996; t=1163543249; x=1164407249; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20OSPF=20Link=20Local=20Signalling=20 |Sender:=20 |To:=20OSPF=20List=20; bh=w3STw3wctFab3lJIFofPpUWEQfn6lx4OslMtqJ4LzYg=; b=L902mPgXqZh3T9YwiR3oFde2JoPzP0PpO9yjionfE+4C0/2iXYIVTLgZgGUxrcADDKFop+4X tzQXBSsxq7RFhYTQ+ipKofgU1mx5NhfM2q/D8ixxXHLhzyw5s1aJ1Fb2; Authentication-Results: rtp-dkim-1; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [OSPF] OSPF Link Local Signalling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org As you all know, we have OSPF Link-local Signaling (draft-ietf-ospf-lls-01.txt) as WG document. However, I don't believe we can get IANA to manage the TLV type number space until the document is published. In the interim, Abhay Roy has volunteered to manage the allocations for LLS TLVs. Please contact him directly if you have a draft that will require a unique code point. I'm more concerned with collisions than having holes in the space due to drafts not making it all the way to RFC. I've excerpted the IANA considerations section from the draft below: LLS TLV types are maintained by the IANA. Extensions to OSPF which require a new LLS TLV type MUST be reviewed by an designated expert from the routing area. Following the policies outlined in [IANA], LLS type values in the range of 0-32767 are allocated through an IETF Consensus action and LLS type values in the range of 32768-65536 are reserved for private and experimental use. This document assigns the following LLS TLV types in OSPFv2/OSPFv3. TLV Type Name Reference 0 Reserved 1 Extended Options [RFCNNNN]* 2 Cryptographic Authentication+ [RFCNNNN]* 3-32767 Reserved for assignment by the IANA 32768-65535 Private Use *[RFCNNNN] refers to the RFC number-to-be for this document. + Cryptographic Authentication TLV is only defined for OSPFv2 This document also assigns the following bits for the Extended Options bits field in the EO-TLV outlined in Section 2.5: Extended Options Bit Name Reference 0x00000001 LSDB Resynchronization (LR) [OOB] 0x00000002 Restart Signal (RS-bit) [RESTART] Other Extended Options bits will be allocated through an IETF consensus action. Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Nov 14 21:28:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkATL-0002BK-K7; Tue, 14 Nov 2006 21:25:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkATI-00025A-68 for ospf@ietf.org; Tue, 14 Nov 2006 21:25:52 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkATE-00075M-W5 for ospf@ietf.org; Tue, 14 Nov 2006 21:25:52 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8R00BN52JR47@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 15 Nov 2006 10:21:27 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8R000BG2JQ3P@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 15 Nov 2006 10:21:27 +0800 (CST) Received: from [127.0.0.1] ([10.111.34.184]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8R00IA72JP40@szxml04-in.huawei.com> for ospf@ietf.org; Wed, 15 Nov 2006 10:21:26 +0800 (CST) Date: Wed, 15 Nov 2006 10:21:25 +0800 From: "Abhay D.S" Subject: Re: [OSPF] OSPF Link Local Signalling In-reply-to: <455A42D0.8090100@cisco.com> To: Acee Lindem Message-id: <455A79A5.5020208@acm.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Pd94eORcs790R2i38s3Kjw)" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) References: <455A42D0.8090100@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: abhayds@acm.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_Pd94eORcs790R2i38s3Kjw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT This draft seems like good reading. Why we might want to waste the TLV space now ? We also have the OSPFv2 router capabilities draft with local LSA's. - Abhay D.S Acee Lindem wrote: > As you all know, we have OSPF Link-local Signaling > (draft-ietf-ospf-lls-01.txt) > as WG document. However, I don't believe we can get IANA to manage the > TLV type number space until the document is published. > > In the interim, Abhay Roy has volunteered to manage the > allocations for LLS TLVs. Please contact him directly if you have a > draft that > will require a unique code point. I'm more concerned with collisions > than having > holes in the space due to drafts not making it all the way to RFC. > > I've excerpted the IANA considerations section from the draft below: > > LLS TLV types are maintained by the IANA. Extensions to OSPF which > require a new LLS TLV type MUST be reviewed by an designated expert > from the routing area. > > Following the policies outlined in [IANA], LLS type values in the > range of 0-32767 are allocated through an IETF Consensus action and > LLS type values in the range of 32768-65536 are reserved for private > and experimental use. > > This document assigns the following LLS TLV types in OSPFv2/OSPFv3. > > TLV Type Name Reference > 0 Reserved > 1 Extended Options [RFCNNNN]* > 2 Cryptographic Authentication+ [RFCNNNN]* > 3-32767 Reserved for assignment by the IANA > 32768-65535 Private Use > > *[RFCNNNN] refers to the RFC number-to-be for this document. > + Cryptographic Authentication TLV is only defined for OSPFv2 > > > This document also assigns the following bits for the Extended > Options bits field in the EO-TLV outlined in Section 2.5: > > Extended Options Bit Name Reference > 0x00000001 LSDB Resynchronization (LR) [OOB] > 0x00000002 Restart Signal (RS-bit) [RESTART] > > > Other Extended Options bits will be allocated through an IETF > consensus action. > > > Thanks, > Acee > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > --Boundary_(ID_Pd94eORcs790R2i38s3Kjw) Content-type: text/x-vcard; charset=utf-8; name=abhayds.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=abhayds.vcf begin:vcard fn:Abhay Rao n:Rao;Abhay email;internet:abhayds@acm.org version:2.1 end:vcard --Boundary_(ID_Pd94eORcs790R2i38s3Kjw) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --Boundary_(ID_Pd94eORcs790R2i38s3Kjw)-- From volleytmckdus@asiman.com Wed Nov 15 01:47:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkEYU-0005LZ-GK for ospf-archive@lists.ietf.org; Wed, 15 Nov 2006 01:47:30 -0500 Received: from [87.249.8.169] (helo=oleg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkEYR-0000z3-L9 for ospf-archive@lists.ietf.org; Wed, 15 Nov 2006 01:47:28 -0500 Message-ID: <000b01c70881$e480fb10$0d12a8c0@oleg> Reply-To: "shemir" From: "shemir" To: "vicentiut" Subject: regarding last night Date: Wed, 15 Nov 2006 09:47:18 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C70881.E480FB10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C70881.E480FB10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C70881.E480FB10" ------=_NextPart_001_0008_01C70881.E480FB10 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable pity, sir I will be his surety. This is the second man I ever saw,the = lovecharm to the wrong person's eyes and now, having foundpresently = opening his eyes, and seeing his dear Hermia, recovered his upon it, he would be almost ready to think it was Hermione = herself.brother.Ganimed, and Celia chose the name of Aliena. here lived in the city of Verona two young gentlemen, whose names discourse of love and admiration to her. And Julia overheard Silvialove. = Hearing this threat, Thurio, who was a great coward, drew back,first = wife.celebrate her funeral with songs and solemn dirges, as was then the servant, and allotted him but five days to make his preparations forthe = meeting, till, by sleep and the operation of herbs which they gavecould = be supposed to have and Duncan's two sons fled. Malcolm, the understood from some words she uttered, she was in love with Bertram, understood from some words she uttered, she was in love with = Bertram,regard her angry words, for they had agreed she should seem = reluctantamaze, exclaimed, Now, by my hollidam, here comes Katherine! and = shewas at length made lady abbess of this convent, and in discharging to go against her for a while. Leaving Isabel sufficiently = instructed,perceived she suffered for the love of him and much it moved = hermet with you again There's for you and struck him a blow. Sebastian compassion and not to let the cries of virgins, babes, or mothers, That same day about noon, Romeo's friends, Benvolio and Mercutio,to her = chamber, from the orchard in which he had heard her confessionthinking = that he would be less an object of suspicion when his unclethe hands of = the prince whom she loved, so affected this tender young by a fellow whom Iago had set on, swords were drawn, and Montano, aOn his = arrival he found the city reduced to the utmost distress and,when she = entered the ship in which her own father sat motionless with parts. He did as great Circe had appointed. He raised his mast, and hoistedas = she slew his sire. It is now no world to trust a woman in.Butwith which = they went through the severest sufferings and the hardestyou may spare = me, and to be shown the way to some neighbouring town. him, that the period of their wars in Troy should then be, when thethe = chief nobility of Ithaca and of the neighbouring isles, who, innumbers, = and how stands the queen thy mother affected to them present at that contest, for he said, It may be, some rougher strife My father is the curate of a village church, about five milesMy father = often left me alone with my uncle sometimes to write his sorrow for having so cruelly deceived her.music gallery, which was at the = end of a ballroom we had chosen forlady Harriot play one long piece of = Haydn's music after another, to the old man in a minute. the frequent repetition of the words, My own, my own, gave my mammathings = in the creation, and the narrative in the Bible, which does notengrossed = my mind ever since though indeed the captain and all ------=_NextPart_001_0008_01C70881.E480FB10 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

3D""


pity, sir I will be his surety. This = is the second man I ever saw,the lovecharm to the wrong person's eyes and = now, having foundpresently opening his eyes, and seeing his dear Hermia, = recovered his
upon it, he would be almost ready to think it was Hermione = herself.  brother.  Ganimed, and Celia chose the name = of Aliena.
here lived in the city of Verona two young gentlemen, whose = names         

discourse of love and admiration to her. And Julia overheard = Silvialove. Hearing this threat, Thurio, who was a great coward, drew = back,first wife.celebrate her funeral with songs and solemn dirges, as = was then the
servant, and allotted him but five days to make his preparations = for  the meeting, till, by sleep and the operation of herbs = which they gave  could be supposed to have and Duncan's two = sons fled. Malcolm, the
understood from some words she uttered, she was in love with = Bertram,         

understood from some words she uttered, she was in love with = Bertram,regard her angry words, for they had agreed she should seem = reluctantamaze, exclaimed, Now, by my hollidam, here comes Katherine! and = shewas at length made lady abbess of this convent, and in discharging
to go against her for a while. Leaving Isabel sufficiently = instructed,  perceived she suffered for the love of him and = much it moved her  met with you again There's for you and = struck him a blow. Sebastian
compassion and not to let the cries of virgins, babes, or = mothers,         

That same day about noon, Romeo's friends, Benvolio and Mercutio,to = her chamber, from the orchard in which he had heard her = confessionthinking that he would be less an object of suspicion when his = unclethe hands of the prince whom she loved, so affected this tender = young
by a fellow whom Iago had set on, swords were drawn, and Montano, = a  On his arrival he found the city reduced to the utmost = distress and,  when she entered the ship in which her own = father sat motionless with
parts.         
He did as great Circe had appointed. He raised his mast, and hoistedas = she slew his sire. It is now no world to trust a woman in.Butwith which = they went through the severest sufferings and the hardestyou may spare = me, and to be shown the way to some neighbouring town.
him, that the period of their wars in Troy should then be, when = the  the chief nobility of Ithaca and of the neighbouring = isles, who, in  numbers, and how stands the queen thy mother = affected to them
present at that contest, for he said, It may be, some rougher = strife          My father is the curate of a village church, about five milesMy father = often left me alone with my uncle sometimes to write = his       sorrow for having so cruelly deceived her.
music gallery, which was at = the end of a ballroom we had chosen for     lady = Harriot play one long piece of Haydn's music after another, to   the old man in a minute.    
the frequent repetition of the words, My own, my own, gave my mammathings = in the creation, and the narrative in the Bible, which does = not    engrossed my mind ever since though indeed the = captain and all
------=_NextPart_001_0008_01C70881.E480FB10-- ------=_NextPart_000_0007_01C70881.E480FB10 Content-Type: image/gif; name="8OCeSJegMe.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhEAIsAcIAAAQCBCSOBNQKLGRenCQSlKSKRAQC5Pz+/CwAAAAAEAIsAQAD/ni63P4wykmr vTjrzbv/YCiOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16 v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqb nJ0jBKCgC6GiCqSlpaYEqqsHp62nD7GmDa2qDLOutrq4u6ywtZ7CbrvAo7QOqbzIrrK4yc/N0bfH 1crXvsXMvsPdZtrSyNzNwLbmztXT0tnW6evv5+Hj8t71Z+D4zuXp4+Dqxvy2RVu1T5y7YPPsKeSC j9SoWQRpxdPlkKIyd7BeMVtX/pGcxI0A0S0c+SVXyH7UJqIMV6sjO5bGGhpsFyEhyZtUVtKDtkyl SJ3qOFb02fMXKgk2cSp9AjTkwZ0sMfIM9oxbRJpVefqLurQrFKDkIGpFJTYo2KtZ06rlF4qq17dw 48qdS7eu3bt48+rdy7ev37+AAwseTLiw4cOOAihQfIIxYi0CVER24PgA4wCYGWRugHmz5c6UK0vo 7Bj0As+WOXsmPUE06cuaF2d+Pdu0ZtGqcXP+wBqE7sdDJqMQHvu08du7j5dWXaHycuTHi6eO/sA1 ZenWo7v+Pb17dd7UOXAHjuPiAeIKBKhfMLk9+/XvI6uHT/354vv4r+efPt57/nL89ml3QXbSdUeg gcXpll1v/MmGmm3Y3Tfbaas9SN4PHaXXgHDunaehhx+ih55yBcK2X4QkjhaBc/nh5lx/J76WYowo Avhdgima2OCJCH42o2L2wXihDBmCyN6RHsoH4nzw0Wdkciz+SOFlEO644pVS/kdha1rO6N+LqFlZ oJUm6khllZ+thuNttgk5ZAzmiYikkko+yUCTEOhooIxf2jglmmNix6eLeaoYqJgH6kmbflmW6SWj 9dEI6ZtByPmhkRwiOeeKBEbpnZmR8vipgI/22OKkv4WZKKmiBpnjqaaGNyqCAVJKBJPtOZlpfLy+ Vx2Y+4EZoKKyOljaZlHK/tgmhC6yxqdsbJa4pqhpouhoi2Hy6OmyntqqiZsqgOvtuEOIi4K55Kar 7rrstuvuu/DGK++89NZr77345qvvvvz26y9cAwQs8MAEF2zwwQgnrPDCDDfs8MMQRyzxxBRXbPHF GCuM2ABdcfyWx4aBjJPIS5E8mMkjoXyTyoCxbI/LC8Hcl8zd0FyPzXrh7InOw/B8l89mAMAD0EH7 QDRdLFtFUS/JtGVUSygAILXQC0xNtQVXN5D1AVY/sHXVU4PdNQMsM8hstw7+ecLYCrDdwddtOxC2 2HBzPbfdbi9w9FxJawX1PyAxbULWVBOONdt3c83A1lJ7vXjcEai8LXPF/g5bguGKV+2B1Vcnnvnj mmsNet1kb4zUNPlsBPhMKRQO+gRC10264XBjTvoBKHOXbOXFRg357xrEDgHmoof+eua3K7C3XC77 kzpXgbPu++fURyC848OHXvvoeeN+4/dkfo/u28AnL8H1ci+O+PHlt9298qbXhLpU8pDlNExrN95+ Bfqnr3X/ncMe8IwHv0nVSEz1AVQI7ka8DfSvePtr4P4gWLrDwOwk9HsJBp9CAtcREHYPHCD3OCe3 920td1ialYIK1boJcsBz1CMeCUsIw+oVMGQT2KBFjjIQthTpci6E3QBn57/zCfCGh8JWb1YIvsEF MXhDPN72jFjECuIw/oca9BtWPOKWBY6OfVRknBSr+LUAflBy1roOE2c1AtuBMQMeJKAEY1jEOXrP ghTABlp8OBFqBAUEbnuf1wKJuBrKMITdKxu3/JOaRXFrfBQgZAjhKEkAJs5znUNkDe94RTuYDwbL E8MnYxBKgOFhlC4oJRhQ+QJVesWVkoAlJWSpFFo+wpaRwCVJdMkIXjrClwoBZiKEuQhiesOYhkAm IpQpDGYOwpmFgCYnpAkIagrCmpnImDa3yc1uevOb4AynOL0Zv1qaEo8lO2cnR6bOwmCzD+/8Qzwt MU891JMP95xEPu+wzzz0ExL/pENA7TDQRhSUB6xkwUERarRydnEb/lthheoyIrgOAuCi6sPoBcp4 0Ux29HYe7WgFVFakDGGjoiv4aEYTekS8idSlGv1fTD8aUwosVBEknco1fkKVk3bwix+0nkrpaMPh mREDKHMe6orB1Ba4MagYoCn2kvdUDdx0mPILCFTm18OCTM+O6ROj9vj3OZYmVSTt8KpTWBDHomLN rWUV4lg3cNVlZlUgW9VqWj/SQqIKUayQk+pU6TbKs05lr1x8BwzaylLNEdF9L6Vg4YZqgboeom9b XGteC7LHNs70jYOkoezqmD2bQsAlfuPsH/N3VLjyb7SlHWMVJ2DZZJ5uq5rto2J5+FXQDrK1U1xp ZKHqAJmtNSYx/lltX8G60ZqKEKqCpSBtHarFHeb2IMhVHRD9GsnAvhGksZWAcbWbXaHcz6lPhGN6 iQvdC9Q2mlh8Smejl1fobQ6ozy0tYydYRjmOFK191G1iOdhG/LqWrNz1a3/X+4D3EuKCAiZILM5L 4cOKgLIuPdxwMcxhMg5XvKc9r0X+ON+kAHLDH6bkhn97SMalGMTo9OTQ8tDYFTj4maeccY57cONr dqydhOmxGYSMBiLL88cfo+4ugXwyJL9SySljsmDGSeUqW/nKWM6ylicG5ZhJOTBGHkOYyzBmfDr5 zEFGszljzM4ks3llX26Zmtu8Tji7uc5zqDEKyszWhr6ZAQUI/nSgFyDoQQNa0IdGtAIKbehFK/oA j4Z0AZpbUwx3l4YtpRthP8kyXRGnSfO5E6iZlJ5Pn7jSL1ZvSzmcalY7V29dhjSgFz1rWhP61rie 9AN0bWtZH/qtc82vaFv7vyO2tbIR8LSoL2XqSy1bUy80sJ5hKjbZzrGqReWzPSPAa193W9fdtvW3 e13rXdc63Ahm7uMAG1ZjCztyEOhQkjQk72bbid7QBiSDuwvbCIIR23DTtj+5fe6CNwDcBj84wXMN xQRnz8UrLqrtLA3vB9R7SRh39q42hKmfOnyjbn3staXd4FiPW9KPRjfCc81ociuc3Og2KnAPJ9nf BVfi/3VA/rPrxHNSawpXHZL35j7L3teG93UjD3a2TV5ohuP63E13udSffnKQf1zm/oXpq6PrWyve 6etLCjrYO67zI43ovlen9GztJluZzpTinHTnwl/u67o7ne7ldgCvGR3zMHa9ePuVbqYPjMT4hDrs IRr7xhV/b7SrO93SXfC7cV5ck5ub6uWOed+rvvK8uzvt/gt82433+MLfu05gt/fioe0kB5Lc8TUn Y1Bv7vU0Q0DzdI/61Pme6L0PWuWRRPGrZY7q4bfY7cjmOMdHlKvDn2fUh//02VVMuFRruPgapWlI ke5c6wscD99fm47vMO09x/oN5S9B+MXP4/PfLM5/Wb8W/uTPBfrPwf5XwH8W9A8H/lPB/1YAgG0g gFFAgFNggGqwZQq4gAzYgA74gAbzLxI4gRRYgRZ4gRiYgRq4gRzYgR74gSAYgiI4giSIgRB4giiY giq4ghCDZyVYfy74gvMXgzKIBQh4Bjf4gTlIZjX4BTtIBj/IgUEoBkO4F+l3AkUIBv53hJKgfZp2 aSu1aU8oWlEIAUnog0ngap/Ub5BVfcPHfXDXAQ3RVC2RCj9kHg9xERT2CrmwdqBHbUR1c5KHPKB1 hV6gM1vhUzCRh1TkXUUHh3hjbb5FdCegVCiFP5s1D4ZYX/b1XV2HPv4me7EHVnbYBSbTevTjR8uw h6sD/nlFB4mjR3uO9YcesIiKZV8Bpl3Qk0UWxmIzZz2uNVmRlXR+mF+VCIOihonSAxBXEQ/P44nv BorsJYp02IVM2EMZRGCpiIovYQ0VFlX7xnZHp3RzKHoNcItbQDI+JwusyEW++DfB94pCNY1DZHzE dYy7iIz1kxFqqIoPgV2qaGKA93eBqD6w+HHRxXW1B2Y6N32aeIpqNVHy+Hrns3UldI/CZZAkoEMa ERXJlYYiVl3SQ2D3WHpxRFXRSIxxN2UZwItl0Ysm4Y76RY/Hxm6Dd44m0I709TzL2IlE8VCfZ5G1 KIik54akg40zeAG/6JHRE1GTSJJR1F41CUGlpwF6/kRfI9aTq1VSO9WKLFaFQjWL+Sh8x5dRMGZ7 FrCTEKWUFNmFUEl8Xph9U1lpHvaFj4COI4CT+ydKhYGWIqCWNsiWIwiX+deDd0iDdvl/eJmXUkCX AciX2biXgPkEflkFhbkvh3mAg7mWclcvbqmEgskXWohgXwl3siOVYXgEidmXVMAhq7cBZvMgaPNI eVIlZ0MbDCKJjydYAFdsqqmXjRkF0pdvGjA50KEtoSItsMJIvOl3n1g9rTmKr6mYsQkFplZv9CF2 XaKbtRIrTSQpawRs6iaMjjiTWaePS7CZBcgElmJ2ifedQkctKiQrLzIaB8IfzKJhWTeO5HhUcniS /poZmUDwme7RfHhCJwYUKs3ZLOYZHnrSOxVJkt3HUQnJUS/2mKAknz8QnonHoPg5IrrzJ8iSn735 KP8pniNJihcJn4SnkfFZnEqAeop3cczGQru5O/+BNmzkKhRKk5NXjB76ROLIBNoJBT02fZ7ZKyVa mhVCLGlSG8eSLcaSG4ciJJNZkJj5Uk4Ye/U4hU1Qo4RpLwh6lyAaL1NqiQq6mEkApU7ApfTipTSq pXXpTixYpmZ6pmiaZWK6pmzapm76pnAap3I6p3Rap3Z6p3iap3q6p3zap376p4AaqII6qIRaqIZ6 qCSxhYuFqMhXA6gkfPb4omOQfm9HmW5Yp+hR/pTTA4UbCqPod2JgY6mCh6mXOoukZ46BlWJDdaDB 5kHUaZVeSVqQNZSxA3EBJJZeWG2Kg1Gy2Ktl9XbmKDweBZWmqqdnZ5adSmxxtaxIB12EmEnB2KqO 45425z4CNFm0SpTSWIzcmqyzt6vdWq02dKUZ2J2hNYXoAwDqqq6yqqzUqq3Mqj3B1ami865m1G+M ta7Y+kFV5a21uGCuqq/iyq70qKWfOVjVqqzNGq/iOq7SWq8idK/tZa9Kt7BgRbDs5q/hyrCe6rDl o7BuyqDXuZ4cK7ERO5QWy6/WuawgK0MDG1uiJ1a3il8aS68qy7I3i6ciSoVOCnHEF6sH2aQy/gWr 3Id1DRt5BBurl5m0PjurujpxSct2w3q0QSm0Amu1d+qPMUCui3phLsC1jDoEYIteBUa2YXu2aJu2 aru2bNu2bvu2cBu3cju3dFu3dnu3eJu3eru3fNu3fvu3gFsPBjC4hDu4DWC4h2sAEIC4D8C4DuC4 i1u4ipu4hZu4kTu5gSsHkOu4kHsAneu5nwu6mEu5EkC4DMC4prsAqSu6jRu6mbsGncu5o/u5iku7 oNu4txsBm4u5scu7veu6r5sGvWu5uXu4ChC7xzu6x5u8uqu8xPu4k1u7yiu9wRsHw3u60eu8vmu8 zHu6quu831u64Ju71Bu+wFu9ZrC7rYu8/uGrutjrve3buuIbuctbvNmLvm8guatLudP7vNPLu88L vfMrv57bvYh7vvg7Bqg7vgc8u/prug8MwREMvsAbugdsvvGbwGoguwRcweNbvAJMv80rwr67wBrM Bur7vhkcwCyswt37wi98vQWcwQh8wl8gwzLcwivswiC8vwvswABMwx9sw2FAu/erwyCMxD2svZIL vZULvyJMxFKsthNcxVZ8xVicxVq8xfs7xV78xWAcxmI8xmRcxmasLuC1BWN7xk/pcb45qhyqai+w xo66dnRcgiAbbXJFjnEsBHcsA1G7rdZaqFXZqE57tVZ5kex6bMgXsFG7rlMFyaGnqzhr/qvCKcnM ismaDJwP667gmrDrFsq/5bQZhsmL2a/tWrGRSDuc+q9Uu7FAZbLII3n7KrHXA1j7Gsquc8ufHKm9 XLPP5bKZLKaoDK+yTJO5useuKq+m7MrziLMrC82V/KuEFcyfLKxxI4wZe7X62qvV+LCEh8coS8sv O5zBKUUUG6DBnM7cmrINq80nO62inM0o28vfCq8K9s7E3MzN/M6PbKDdusj1HKo2Z8qIDM6S9c8Y 28Yx9Mi/Gpb5BYkSPcxUO4dHK8mb/MqAaz6a2nBsrAkdLccfPdIkXdImfdIondIqvdIs3dIu/dIw HdMyPdM0XdM2fdM4ndM6vdM83dM+Lv3TQB3UQj3URF3URn3USJ3USr3UTN3UTv3UUB3VUj3VVF3V Vn3VWJ3VWm3VCQAAOw== ------=_NextPart_000_0007_01C70881.E480FB10-- From MAILER-DAEMON Wed Nov 15 13:08:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPBd-0001ly-AD for ospf-archive@lists.ietf.org; Wed, 15 Nov 2006 13:08:37 -0500 Received: from mta3.prod1.dngr.net ([216.220.209.222] helo=mfe3.prod.danger.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkPBc-00025T-2X for ospf-archive@lists.ietf.org; Wed, 15 Nov 2006 13:08:37 -0500 Subject: Undeliverable mail: Returned mail: Data format error From: MAILER-DAEMON@mfe3.prod.danger.com To: Date: Wed, 15 Nov 2006 10:08:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/report; report-type="delivery-status"; boundary="_===915280749====mfe3.prod.danger.com===_" X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d --_===915280749====mfe3.prod.danger.com===_ Content-Type: text/plain; charset="utf-8" Failed to deliver to 'jpelle@tmail.com' LOCAL module(account jpelle@tmail.com) reports: mail receiving disabled --_===915280749====mfe3.prod.danger.com===_ Content-Type: message/delivery-status Reporting-MTA: dns; mfe3.prod.danger.com Original-Recipient: rfc822; Final-Recipient: LOCAL;<> Action: failed Status: 4.0.0 --_===915280749====mfe3.prod.danger.com===_ Content-Type: text/rfc822-headers Received: from [65.113.94.131] (HELO lists.ietf.org) by mfe3.prod.danger.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 915280618 for jpelle@tmail.com; Wed, 15 Nov 2006 10:08:21 -0800 From: ospf-archive@lists.ietf.org To: jpelle@tmail.com Subject: Returned mail: Data format error Date: Wed, 15 Nov 2006 14:08:21 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_D294475E.505152EF" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: --_===915280749====mfe3.prod.danger.com===_-- From ospf-bounces@ietf.org Wed Nov 15 13:45:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPjf-0000Qx-AQ; Wed, 15 Nov 2006 13:43:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPje-0000Qs-K5 for ospf@ietf.org; Wed, 15 Nov 2006 13:43:46 -0500 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkPje-00084a-0S for ospf@ietf.org; Wed, 15 Nov 2006 13:43:46 -0500 Received: by wx-out-0506.google.com with SMTP id h29so326843wxd for ; Wed, 15 Nov 2006 10:43:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mnKONlN91M1x3maeWA4WWoWSgx5pTxhJFVLfH+V0lNsvQywrDjxxl9j/cmNnDul56fElQKuO/rUy4WTYMAVnz2A9C/nFafnrf+mk5dWmdV1K1W70XmYvXT+HCKOGXVdvzqSH+5W8TRcO/IOuRBs8EunxhjMB6LLNVc5hXUHoqcs= Received: by 10.90.52.2 with SMTP id z2mr2710269agz.1163616225537; Wed, 15 Nov 2006 10:43:45 -0800 (PST) Received: by 10.90.31.17 with HTTP; Wed, 15 Nov 2006 10:43:45 -0800 (PST) Message-ID: Date: Thu, 16 Nov 2006 00:13:45 +0530 From: "sujay gupta" To: Erblichs Subject: Re: [OSPF] Comments / questions on RFC3623 and Update GR part 1 : BMA env In-Reply-To: <45590834.B988E949@earthlink.net> MIME-Version: 1.0 References: <45590834.B988E949@earthlink.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0213609233==" Errors-To: ospf-bounces@ietf.org --===============0213609233== Content-Type: multipart/alternative; boundary="----=_Part_22847_2819852.1163616225432" ------=_Part_22847_2819852.1163616225432 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mitchell, I have some comments inline; On 11/14/06, Erblichs wrote: > > Group, > > First, I have a few questions to the base and the update. > These comments / questions pertain ONLY to BMA envs > but are also relevelent to other envs. > > FYI) IMO, helpers are defined by two major requirements > a) the ability to recieve a grace-LSA before a hello > "new hello" and not restart the adj > b) the ability of a helper "Y" to (re)send a router-LSA, etc > upon > router "X" exiting graceful restart that are in its > retransmit-list. > > > If this "helper" split functionality is supported, then only > a limited number of routers within a area need to be in > Full-helper mode. > > Within BMA envs a DR-other above helper "b" functionality > is not really necessary for retransmit. We use the DR/BDR > for retransmit support. > > > IFFFFFFF, a GR router is the DR, who is in it grace-period, > and a DR-other stops sending hellos, if their are no > alternate paths thru another router for any forwarding > data. Then what benefit is it to prematurely end helper > mode? Basicly, most algs can determine ahead of time whether > the exiting router has contributed a primary link/path. If > it isn't then it has no consequence. Yes, data pkts that have > a intermediate dest will be forwarded 1 or two extra hops, > before they are dropped. > > (Update: 2.0 Action on route calculation) > If a topology change occurs and the GR restarting router > is identified as the next hop. By definition it is in non-stop > forwarding mode and should be able to forward packets. If this > is identified as a topology change and the ONLY route is thru > this GR router, shouldn't packets be forwarded thru it anyway? > Not doing so blackholes those routes, IMO. Suj>> Here topology change also includes routes which are no more valid,if the lsa seeks a route to be removed and that route involves the GR router the helper exits, thus black-holing and circumventing the GR router as router under plain restart.Note here that previously(rfc3623) the helper was exiting for all reasons, which has been curbed now so as you have pointed out if the lsa effects the route which is ONLY through the restarting router will the system exit, which makes sense. Thus, > 1) Helpers should be able to be able to support a, without b > If this is the case, router "X", if it is a DR should allow > all the DR-others to support a, while only the BDR need be > a "Full-Helper". Suj>> I like your analysis in breaking up the helper job into partial and full. IMO "Helper" is a behaviour of a router w.r.t to the GR operation, where as the idea whether the helper is "Full-helper" else a "Partial" depends upon the result of election. In brief a "Helper" is always expected to perform "Full-helper" features as per your describe , if it does less; guess it is plain lucky ! ,( also note Helper support maybe a feature switched on / off by admin, not a partial/full helper). 2) If router "X" is a DR-other only one of a "DR or BDR" > need to be a Full-helper. All LSAs can be placed on the > retransmit list of the for router "X" by the DR or BDR. > > 3) Topology change. A LSA aging out of the LSDB, will not > necessarily remove a element in the forwarding table? > If this can be detected, should it still force the exit > of a helper wrt graceful restart? Suj>> as per the base ospf operation a max aged lsa on the lsa, should trigger it to flood the lsa (-->" which in turn should instigate the originator of the lsa to resend a fresh copy, if fails ends in removal of the corresponding route everywhere! "), thus if the case happens as you have described a GR with "strict lsa checking enabled" i.e catch all topology changes should force the helper to exit as it has to flood this lsa to the GR router, here the update draft would tell you prohibit your exit only if the lsa somehows affects a route through the GR router, else let peace prevail, no need to exit. 4) If router "X" is a DR and has entered graceful restart > with no BDR present, should the DR-other routers allow the > LSAs to become not refreshed and aged out because the > grace period has not expired. > How can "one" or more "HELPERS" force a new DR election? Suj>> IMO the DR-other allows normal aging to continue, if the lsa age's out before grace period expiry, the helpers would exit GR(see above) , again applying the same logic. A new election would disturb all previous adjacencies, do we need it? 5) Even with a 30 min max for the grace period, some routers > may only retransmit once every 45 mins or so. How can we > guarantee that those retransmited-LSAs are not aged-out if > router "X" is the DR and is down for a longer time? > > Shouldn't recieving the first grace-LSAs from a restarting > router initiate a re-send of the LSAs? Suj>> With the LSRefreshtime is 30 min , the MaxAge double(60min), the max grace period is same as LSRefreshtime 30 min, I dont see how we reach a stage where the problem will come, you might want to consider some border cases i guess there the previous arguments(see above) hold good. Mitchell Erblich Best Regards, Sujay _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > ------=_Part_22847_2819852.1163616225432 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mitchell,
I have some comments inline;

On 11/14/06, Erblichs < erblichs@earthlink.net> wrote:
Group,

        First, I have a few questions to the base and the update.
        These comments / questions pertain ONLY to BMA envs
        but are also relevelent to other envs.

        FYI) IMO, helpers are defined by two major requirements
           a) the ability to recieve a grace-LSA before a hello
              "new hello" and not restart the adj
           b) the ability of a helper "Y" to (re)send a router-LSA, etc upon
              router "X" exiting graceful restart that are in its
              retransmit-list.


        If this "helper" split functionality is supported, then only
        a limited number of routers within a area need to be in
        Full-helper mode.

        Within BMA envs a DR-other above helper "b" functionality
        is not really necessary for retransmit. We use the DR/BDR
        for retransmit support.


        IFFFFFFF, a GR router is the DR, who is in it grace-period,
        and a DR-other stops sending hellos, if their are no
        alternate paths thru another router for any forwarding
        data. Then what benefit is it to prematurely end helper
        mode? Basicly, most algs can determine ahead of time whether
        the exiting router has contributed a primary link/path. If
        it isn't then it has no consequence. Yes, data pkts that have
        a intermediate dest will be forwarded 1 or two extra hops,
        before they are dropped.

        (Update: 2.0 Action on route calculation)
        If a topology change occurs and the GR restarting router
        is identified as the next hop. By definition it is in non-stop
        forwarding mode and should be able to forward packets. If this
        is identified as a topology change and the ONLY route is thru
        this GR router, shouldn't packets be forwarded thru it anyway?
        Not doing so blackholes those routes, IMO.

 
Suj>> Here topology change also includes routes which are no more valid,
if the lsa seeks a route to be removed and that route involves the GR router
the helper exits, thus black-holing and circumventing the GR router as router
under plain restart.Note here that previously(rfc3623) the helper was exiting
for all reasons, which has been curbed now so as you have pointed out if the
lsa effects the route which is ONLY through the restarting router will the system
exit, which makes sense.

        Thus,
        1) Helpers should be able to be able to support a, without b
           If this is the case, router "X", if it is a DR should allow
           all the DR-others to support a, while only the BDR need be
           a "Full-Helper".

 
Suj>> I like your analysis in breaking up the helper job into partial and full.
IMO  "Helper" is a behaviour of a router w.r.t to the GR operation, where as
the idea whether the helper is "Full-helper" else a "Partial" depends upon the result
of election. In brief a "Helper" is  always expected to perform "Full-helper" features as per your describe , if it does less; guess it is plain lucky ! ,( also note Helper support maybe a feature switched on / off by admin, not a partial/full helper).

 

        2) If router "X" is a DR-other only one of a "DR or BDR"
           need to be a Full-helper. All LSAs can be placed on the
           retransmit list of the for router "X" by the DR or BDR.

        3) Topology change. A LSA aging out of the LSDB, will not
           necessarily remove a element in the forwarding table?
           If this can be detected, should it still force the exit
           of a helper wrt graceful restart?

Suj>> as per the base ospf operation a max aged lsa on the lsa, should trigger
it to flood the lsa (-->" which in turn should instigate the originator of the lsa to resend a fresh copy, if fails ends in removal of the corresponding route everywhere! "),
thus if the case happens as you have described a GR with "strict lsa checking
enabled" i.e catch all topology changes should force the helper to exit as it has to
flood this lsa to the GR router, here the update draft would tell you prohibit your
exit only if the lsa somehows affects a route through the GR router, else let peace
prevail, no need to exit.


        4) If router "X" is a DR and has entered graceful restart
           with no BDR present, should the DR-other routers allow the
           LSAs to become not refreshed and aged out because the
           grace period has not expired.
           How can "one" or more "HELPERS" force a new DR election?

Suj>> IMO the DR-other allows normal aging to continue, if the lsa age's out
before grace period expiry, the helpers would exit GR(see above) , again
applying the same logic.

A new election would disturb all previous adjacencies, do we need it?

 

        5) Even with a 30 min max for the grace period, some routers
           may only retransmit once every 45 mins or so. How can we
           guarantee that those retransmited-LSAs are not aged-out if
           router "X" is the DR and is down for a longer time?

            Shouldn't recieving the first grace-LSAs from a restarting
            router initiate a re-send of the LSAs?

Suj>>  With the LSRefreshtime is 30 min , the MaxAge double(60min), the max grace period is same as LSRefreshtime 30 min, I dont see how we reach a stage where
the problem will come, you might want to consider some border cases i guess there the previous arguments(see above) hold good.



        Mitchell Erblich


Best Regards,
Sujay

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf

------=_Part_22847_2819852.1163616225432-- --===============0213609233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0213609233==-- From postmaster@unifiedemail.net Wed Nov 15 16:48:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSck-0006dq-Fe for ospf-archive@lists.ietf.org; Wed, 15 Nov 2006 16:48:50 -0500 Received: from fw1.unifiedemail.net ([69.64.173.82] helo=mx.mg1.unifiedemail.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSch-000550-8I for ospf-archive@lists.ietf.org; Wed, 15 Nov 2006 16:48:50 -0500 From: "Postmaster" To: ospf-archive@lists.ietf.org Subject: Warning - eMail Blocked due to VIRUS detected in message Date: Wed, 15 Nov 2006 16:48:41 -0500 Message-ID: <8FD6F1616501484CB172A1BE38A64CDB.MAI@unifiedemail.net> X-AVAgent: MEAVCAEZAVR71 Precedence: bulk X-MEFilter: 1 X-ME-Bayesian: 0.000000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 We are sorry, but a message apparently sent by you was received by our Mail Servers and blocked due to a VIRUS. Virus Information: The virus was detected by the Anti-Virus agent: MEAVCAEZAVR71 This agent returned a result of: 32 We use industry leading anti-virus software to protect our customers from harmful eMails. If you would like to know more about our Anti-Virus vendor, please visit: http://www.ca.com Regards, Customer Service Unified eMail, llc. “Providing Hosting Messaging Services for reliable communications…” http://www.unifiedemail.net Postmasters, the original message was sent by ospf-archive@lists.ietf.org from 69.17.49.19 and had the following header information: Received: from lists.ietf.org ([69.17.49.19]) by unifiedemail.net with MailEnable ESMTP; Wed, 15 Nov 2006 16:48:36 -0500 From: ospf-archive@lists.ietf.org To: canders@itsa.ucsf.edu Subject: Canders@itsa.ucsf.edu Date: Wed, 15 Nov 2006 13:46:36 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_F5745B44.B8939BF1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Received-SPF: none (unifiedemail.net: lists.ietf.org does not designate permitted sender hosts) X-ME-Bayesian: 0.000000 From mailer-daemon@cryptonomicon.mit.edu Thu Nov 16 03:07:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkcHG-0006KU-KR for ospf-archive@lists.ietf.org; Thu, 16 Nov 2006 03:07:18 -0500 Received: from cryptonomicon.mit.edu ([18.7.14.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkcHC-0007ea-85 for ospf-archive@lists.ietf.org; Thu, 16 Nov 2006 03:07:18 -0500 Received: (from root@localhost) by cryptonomicon.mit.edu (8.12.9.20060308) id kAG87B6n014340; Thu, 16 Nov 2006 03:07:11 -0500 (EST) Date: Thu, 16 Nov 2006 03:07:11 -0500 (EST) Message-Id: <200611160807.kAG87B6n014340@cryptonomicon.mit.edu> To: ospf-archive@lists.ietf.org From: PGP Key Server Administrator Subject: Your command, Hi, was invalid In-Reply-To: <200611160807.kAG870CI014324@cryptonomicon.mit.edu> Precedence: list MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---PKSD-----" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e -----PKSD----- Content-Type: text/plain; charset=us-ascii OpenPGP Public Key Server For questions or comments regarding this key server site, contact PGP Key Server Administrator Current version: 0.9.6 NOTE! This service is provided to facilitate public-key cryptography for demonstration and educational purposes. It is the responsibility of users of public-key cryptography to ensure that their activities conform to legal requirements. -----PKSD----- Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cryptonomicon.mit.edu id kAG87B6n014340 [ Czech: Pro ziskani ceske verze tohoto textu poslete prosim e-mail s= e "Subject" radkou "HELP CZ" na adresu pgp-public-keys@keys.cz.pgp.net, nebo pristupte na URL http://www.pgp.net/pgpnet/email-help-cz.html Danish: For at faa en dansk version af denne text skal du sende en e-mail med en subject-tekst: "HELP DK" til pgp-public-keys@keys.dk.pgp.net eller slaa op paa URL http://www.pgp.net/pgpnet/email-help-dk.html German: F=FCr eine deutschsprachige Fassung dieses Textes senden Sie eine Mail mit dem Subject "HELP DE" an die folgende Adresse pgp-public-keys@keys.de.pgp.net oder URL: http://www.pgp.net/pgp/email-help-de.html English: For an English version of this message, send an e-mail with = a subject line of "HELP" to pgp-public-keys@keys.pgp.net, or access the URL http://www.pgp.net/pgpnet/email-help-en.html Spanish: Para obtener una versi=F3n en castellano de este texto, env=ED= e un mail a pgp-public-keys@keys.nl.pgp.net con el "Subject" HELP ES Finnish: Saadaksesi taman tekstin suomeksi, laheta osoitteeseen pgp-public-keys@keys.nl.pgp.net tyhja viesti, jonka Subject-kentta on "HELP FI". French: Pour une version fran=E7aise de =E7e texte, envoyez un message au sujet de "HELP FR" =E0 pgp-public-keys@keys.ch.pg= p.net Croatian: Za hrvatsku verziju ovoga teksta posaljite poruku koja ce u Subject imati "HELP HR" na adresu pgp-public-keys@keys.nl.pg= p.net Japanese: Nihongo no setumei ga hosii baai wa Subject: ni "HELP JA" to kaite, pgp-public-keys@keys.pgp.net ni e-mail. Korean: =BE=C6=B7=A1=C0=C7 =B3=BB=BF=EB=C0=BB =C7=D1=B1=DB=B7=CE =BA= =B8=BD=C3=B7=C1=B8=E9 =C1=A6=B8=F1(Subject)=C0=CC "HELP KR" =C0=CE =C0=FC=C0=DA=BF=EC=C6=ED=C0=BB pgp-public-keys@keys.kr.pgp.n= et =C0=B8=B7=CE =BA=B8=B3=BB=C1=D6=BD=CA=BD=C3=BF=C0. Polish: Zeby uzyskac polska wersje tej strony, wyslij list z linia "HELP PL" w polu Subject na adres pgp-public-keys@keys.pl.pgp.net lub zajrzyj pod URL http://www.pgp.net/pgpnet/email-help-pl.html Portuguese:Para obter uma vers=E3o em portugu=EAs deste texto, deve env= iar um mail para pgp-public-keys@keys.pt.pgp.net com o "Subject" HELP PT Norwegian: For aa faa dette dokumentet paa norsk, send "HELP NO" til pgp-public-keys@keys.nl.pgp.net Swedish: For a Swedish version of this message, send an e-mail with a subject line of "HELP SE" to pgp-public-keys@keys.se.pgp.net= , or access the URL http://www.pgp.net/pgpnet/email-help-se.html Chinese: =B9=EF=A8=FA=B1o=A6=B9=A4@=A4=A4=A4=E5=AA=A9 PGP =A6=F8=AAA=BE= =B9=B4=A3=A8=D1=BDu=A4W=BB=B2=A7U=BB=A1=A9=FA, =BD=D0 E-mail =B5=B9 pgp-public-keys@keys.tw.pgp.net, =A9=F3 Subject: =B5=F9=A9=FA "HELP= TW" =A7Y=A5i. ] OpenPGP Public Email Keyservers ------------------------------- There are OpenPGP public email key servers which allow one to exchange=20 public keys running using the Internet and UUCP mail systems. Those=20 capable of accessing the WWW might prefer to use the WWW interface=20 available via http://www.pgp.net/pgpnet/www-key.html and managers of=20 sites which may want to make frequent lookups may care to copy the=20 full keyring from the FTP server at ftp://ftp.pgp.net/pub/pgp/keys/ This service exists only to help transfer keys between PGP users.=20 It does NOT attempt to guarantee that a key is a valid key;=20 use the signatures on a key for that kind of security. Each keyserver processes requests in the form of mail messages. The commands for the server are entered on the Subject: line. ---------------------------------------------- =3D=3D=3D=3D=3D=3D=3D=3D -= ---- Note that they should NOT be included in the body of the message. --------------------- =3D=3D=3D --------------------------------------- To: pgp-public-keys@keys.pgp.net From: johndoe@some.site.edu Subject: help Sending your key to ONE server is enough. After it processes your=20 key, it will forward your add request to other servers automagically. For example, to add your key to the keyserver, or to update your key=20 if it is already there, send a message similar to the following to any=20 server: To: pgp-public-keys@keys.pgp.net From: johndoe@some.site.edu Subject: add -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 -----END PGP PUBLIC KEY BLOCK----- COMPROMISED KEYS: Create a Key Revocation Certificate (read the PGP=20 docs on how to do that) and mail your key to the server once again,=20 with the ADD command. Valid commands are: Command Result ---------------------- ------------------------------------------------- HELP Returns this message HELP language Localized help text (DE, EN, ES, FI, FR, HR, NO) ADD Add PGP public key from the body of your message INDEX userid List all PGP keys containing the words in userid VERBOSE INDEX userid Verbose list of all keys containing userid GET userid Get the key(s) matching userid LAST days Get the keys updated in the last `days' days ------------------------------------------------------------------------ LIMITATIONS: Most keyservers have a limit on the number of keys they return in=20 queries, in order not to swamp you with too many keys in case you=20 made a typo (the full database at the keyservers exceeds 2GB). If you *REALLY* need the whole index file or key ring, *PLEASE*=20 ftp it from a key server such as "ftp://ftp.pgp.net/pub/pgp/keys/"=20 or one of the national servers. NOTE: PGP is extremely slow when operating on large keyrings. Adding the full ring of the keyserver to your own ring will take several *MONTHS* to complete. ADDRESSES TO USE: Users should normally use the email address=20 "pgp-public-keys@keys.pgp.net" or your national servers using one of: pgp-public-keys@keys.at.pgp.net pgp-public-keys@keys.au.pgp.net pgp-public-keys@keys.cz.pgp.net pgp-public-keys@keys.de.pgp.net pgp-public-keys@keys.es.pgp.net pgp-public-keys@keys.fi.pgp.net pgp-public-keys@keys.hr.pgp.net pgp-public-keys@keys.hu.pgp.net pgp-public-keys@keys.kr.pgp.net pgp-public-keys@keys.nl.pgp.net pgp-public-keys@keys.no.pgp.net pgp-public-keys@keys.pl.pgp.net pgp-public-keys@keys.se.pgp.net pgp-public-keys@keys.tw.pgp.net pgp-public-keys@keys.uk.pgp.net pgp-public-keys@keys.us.pgp.net for the email interface, "ftp://ftp.pgp.net/pub/pgp/" for FTP,=20 and "http://www.pgp.net/pgpnet/" for WWW access. Users are recommended to use the "*.pgp.net" addresses above as=20 these are stable and reliable. -----PKSD------- From ospf-bounces@ietf.org Thu Nov 16 10:44:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkjNV-0000PT-1T; Thu, 16 Nov 2006 10:42:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkjNT-0000PJ-Ij for ospf@ietf.org; Thu, 16 Nov 2006 10:42:11 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkjNS-00050c-7V for ospf@ietf.org; Thu, 16 Nov 2006 10:42:11 -0500 Received: by ug-out-1314.google.com with SMTP id 72so426007ugd for ; Thu, 16 Nov 2006 07:42:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Fq0QzmtVYlXGucF/McQdWX1mfVucX4kK7QbckpFvh2o5mBRO2G6wfDXFWg24PMiLDg/m4+E9mrgueMrotP1TtM8GLlstLKdwZjIxjPUKCNr0Wc5zhUP719imIuuig3U6QSb498A69BUUP268DZVPeCvyoYSc/4ZsG4mtvJuqBYI= Received: by 10.78.170.17 with SMTP id s17mr689548hue.1163691728860; Thu, 16 Nov 2006 07:42:08 -0800 (PST) Received: by 10.78.200.20 with HTTP; Thu, 16 Nov 2006 07:42:08 -0800 (PST) Message-ID: <6e6ce9380611160742o11c0991axf41f9c04782ef001@mail.gmail.com> Date: Thu, 16 Nov 2006 21:12:08 +0530 From: "Phil Cowburn" To: "Acee Lindem" Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended In-Reply-To: <45587A54.1090309@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45587A54.1090309@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Acee, > Presentation Michael Barnes : Crypto alg reqmts for OSPFv2 > > Some discussion on list already > > Crypto - only md5 to date, can be attacked, some want stronger algs > perhaps should specify these > > How - 2328 can add other algs w/o too much problem Yes it does, but debugging would be a nightmare! :-) Let me not trigger a discussion again, i am ok with using the existing type code! > > This draft - new algorithms should be used and won't change > proto fields, there is key-id field which can has an associated > algorithm as a property. > > Adding crypto terms- SA's - will carry key/alg choice, fairly > straight forward approach - should not cause backwards compatibility > because no change to OSPF proto fields - it's mis-config if one peers > has a different algorithm. > > Acee: IPSec for v3, once done, lacks replay and key dist issues > on lan - w/v2 these problems are solved mainly (seq#>=, not > monotonic incr). Vishwas present requirements in Paris in both > OSPF and RPSEC WGs. > > Sandy Murphy, Sparta : what is manditory to implement? > Michael - Separate doc will discuss what is req'd (ala ISIS approach) > > Presentation: Manav Bhatia - Crypto Requirements Document > > NULL, MS5, sha1, cryptographic - refs in this doc > more algorithms keep coming eg des was once must, now is should ot > > What doc must, should, - running doc as algorithms come and go > uses 2119 terms should+ = should may become must > > See slides and draft for specific requirements. > > Acee: "should not" wording is problematic for NULL and other > existing requirements. > > Russ white: shold may become a must vs. should+ (better to say > what is meant) I dont see any show stopper comments, so what is the status of the auth drafts? There was a discussion on these drafts some time back and the consensus was that the drafts would not be changed and we would reuse the existing type code for additional authentication types. If there are no further comments then should these be taken up as a new items? > > Presentation Lou Berger: berger-ospf-rfc2370bis followon to ietf66 - opaque > LSA across areas - problem w/validation - so instead rev'd 2370 .. > > Acee wanted MAY or Should added > Acee: when we add new info to TE LSAs - scalability issues - > give priority to base ospf LSA over the opaque LSAs. > Lou: We should take to list whether MAY or SHOULD should be in > the final text. SHOULD sounds too strong to me. This is an implementation specific issue and not all implementations may be able to prioritize OSPF pkts. In view of this, a MAY should be sufficient as a recommendation from the WG. Lets not word it any stronger than this. > > Acee: Will validate on list that this is to become a WG document. I am in favor of this. Phil _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 16 14:11:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkmcu-0003A1-9k; Thu, 16 Nov 2006 14:10:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkmct-00039r-Dg for ospf@ietf.org; Thu, 16 Nov 2006 14:10:19 -0500 Received: from [216.246.62.14] (helo=esc91.midphase.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkmcp-0007Au-Sk for ospf@ietf.org; Thu, 16 Nov 2006 14:10:19 -0500 Received: from [216.246.62.14] (helo=LC1.labn.net) by esc91.midphase.com with esmtpa (Exim 4.52) id 1GkmcX-0002fo-Fj; Thu, 16 Nov 2006 14:09:57 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 16 Nov 2006 14:06:39 -0500 To: djoyal@nortel.com,pgalecki@airvana.com,spencer.giacalone@csfb.com From: Lou Berger Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ospf@ietf.org Subject: [OSPF] inconsistency in draft-ietf-ospf-mib-update-11.txt? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Message-Id: Hi, So, the following is taken from your draft: ospfOpaqueLsaSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The router's support for Opaque LSA types. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." REFERENCE "The OSPF Opaque LSA Option" ::= { ospfGeneralGroup 16 } The access and description seem inconsistent. The description implies that acess should be "read-write". Am I missing something? Lou _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 16 14:48:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknDq-0004su-IK; Thu, 16 Nov 2006 14:48:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknDo-0004so-Lt for ospf@ietf.org; Thu, 16 Nov 2006 14:48:28 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GknDn-0008DN-Ew for ospf@ietf.org; Thu, 16 Nov 2006 14:48:28 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAGJmLs13649; Thu, 16 Nov 2006 14:48:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Nov 2006 14:48:19 -0500 Message-ID: <4B7DAC3FEFD35D4A96BDD011699050140A42410C@zrtphxm1.corp.nortel.com> In-reply-to: <200611161910.kAGJAF403992@zrtps0kk.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: inconsistency in draft-ietf-ospf-mib-update-11.txt? Thread-Index: AccJstsEjrUFtc/8SL2+WYNnQ+OfBAABDHdw From: "Daniel Joyal" To: "Lou Berger" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ospf@ietf.org Subject: [OSPF] RE: inconsistency in draft-ietf-ospf-mib-update-11.txt? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Lou, It is inconsistent. Thanks for catching this. I don't think there is a reason to make Opaque LSA support configurable as it is a backwards compatible extension to OSPF, so the verbiage about persistence should be deleted. Any objections? -Dan=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: Thursday, November 16, 2006 2:07 PM > To: Joyal, Daniel (BL60:SF23); pgalecki@airvana.com;=20 > spencer.giacalone@csfb.com > Cc: ospf@ietf.org > Subject: inconsistency in draft-ietf-ospf-mib-update-11.txt? >=20 > Hi, >=20 > So, the following is taken from your draft: > ospfOpaqueLsaSupport OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The router's support for Opaque LSA types. >=20 > This object is persistent and when written > the entity SHOULD save the change to non-volatile > storage." > REFERENCE > "The OSPF Opaque LSA Option" > ::=3D { ospfGeneralGroup 16 } >=20 > The access and description seem inconsistent. The=20 > description implies that acess should be "read-write". Am I=20 > missing something? >=20 > Lou >=20 >=20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 16 14:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknIZ-0000tK-5y; Thu, 16 Nov 2006 14:53:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknIX-0000tB-Ui for ospf@ietf.org; Thu, 16 Nov 2006 14:53:21 -0500 Received: from [216.246.62.14] (helo=esc91.midphase.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GknIW-00015M-Ci for ospf@ietf.org; Thu, 16 Nov 2006 14:53:21 -0500 Received: from [216.246.62.14] (helo=LC1.labn.net) by esc91.midphase.com with esmtpa (Exim 4.52) id 1GknIU-0000kb-Me; Thu, 16 Nov 2006 14:53:19 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 16 Nov 2006 14:53:16 -0500 To: Acee Lindem From: Lou Berger In-Reply-To: <455907D0.5010706@cisco.com> References: <455907D0.5010706@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: OSPF List Subject: [OSPF] Re: Comments on draft-berger-ospf-rfc2370bis-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Message-Id: Acee, See responses in-line below. Should the corrected version go in as draft-berger or draft-ietf? Lou At 07:03 PM 11/13/2006, Acee Lindem wrote: >Hi Lou, > >My main comment is on section 5 (6 is your draft). The draft adds >mandatory reachability checking for AS scoped opaque LSAs. >If we add mandatory reachability checking, it should be for all >opaque types rather reading like the constraint is unique to AS scoped >opaque LSAs (type 11s). valid point. >I also think we should put the question as to whether the checking >should be madatory or relaxed a bit to allow an application to check >less frequently if the opaque data is stale. What benefit would this have? >Detailed comments: > >Section 2, third paragraph - "aligned" rather than "qaligned". yes. >Section 3, "Section 7" rather than "Section 7." okay. >Section 3.1 - Type 9 LSA - "keep" rather than "keepk". yes. Also I added the following to the beginning of the section: Section 13 of [OSPF] describes the OSPF flooding procedure. Those procedures MUST be followed as defined except where modified in this section. >I believe we > should discard a link-local LSA received from a > neighbor not > on the interface (text similiar to type 11). okay, updated as follows: o If the Opaque LSA is type 9 (the flooding scope is link-local) and the interface that the LSA was received on is not the same as the target interface (e.g., the interface associated with a particular target neighbor), the Opaque LSA SHOULD be discarded and not acknowledged, and MUST NOT be flooded out that interface (or to that neighbor). An implementation SHOULD keep track of the IP interface associated with each Opaque LSA having a link-local flooding scope. >Section 3.1, Since the area ID is not in the LSA header, the bullet on > area flooding is confusing. It should say something to the > effect of only flooding type 10 LSAs out interfaces in the > LSA's associated area. okay, updated as follows: o If the Opaque LSA is type 10 (the flooding scope is area-local) and the area associated with Opaque LSA (as identified during origination or from a received LSA's associated OSPF packet header) is not the same as the area associated with the target interface, the Opaque LSA MUST NOT be flooded out the interface. An implementation SHOULD keep track of the OSPF area associated with each Opaque LSA having an area-local flooding scope. >I don't care if it said this in RFC 2370 > and everyone knew what it implied. I don't know how to interpret the text otherwise... >Section 3.1, 2nd to last paragraph: "An opaque" rather than "a opaque". okay. >Swap sections 5 and 6 since "inter-area" is more the "meat" of the draft. done. >In fact, if the opaque MIB objects are all covered in the new MIB, we can >probably remove the "management section". done, section will read: The updated OSPF MIB provides explicit support for opaque LSAs and SHOULD be used to support implementations of this document. See Section 12.3 of [MIB-UPDATE] for details. In addition to this section, implementation supporting [MIB-UPDATE] will include opaque LSAs in all appropriate generic LSA objects, e.g., ospfOriginateNewLsas, ospfOriginateNewLsas and ospfLsdbTable. BTW just sent WG mail on one inconsistency between 2370 and the updated MIB. >Section 6 (will be 5) > >5. Opaque LSA Validation > >Opaque LSAs are not processed during the SPF calculation as described in >section 16 of [OSPF]. However, they are subject to the same reachability >constraints as the base LSA types. This implies that originating router >MUST be reachable for the advertised application specific data to be >considered valid. > >5.1 Inter-Area Considerations > >...... > > >Section 5.1 > > Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem > as a receiving router can detect an a loss of reachability > through the intra-area > SPF calculation. > >Section 5.1 > > To enable OSPF routers in remote areas to check availability of the > originator of link-state type 11 opaque LSAs, the orignators of > type-11 opaque LSAs are considered Autonomous System Border > Routers (ASBRs) and will advertise themselves as such. > >Section 5.1 - Remove "It is important to note that this solution MUST NOT ..." >This is redundant. which part is redundant, just the sentence you are asking to be removed? I agree that it is redundant with 2328, but I thin mentioning it is still useful. Will rephrase to remove directive. >Remove numbered items (1) and (2), these actions ARE NOT new to >opaque LSAs. Make (3) a separate paragraph rather than numbered >item. But inclusion of type-11 originate routers as ASBR is new. Will rephrase to make clear that existing ospf requirements apply. How about: The procedures related to inter-area opaque LSAs are as follows: (1) An OSPF router that is configured to originate AS-scope opaque LSAs advertise themselves as ASBRs and MUST follow the related requirements related to setting of the Options field E-bit in OSPF Hello packets and LSA headers as specified in [OSPF]. (2) When .... >Section 10.1 - Correct NSSA reference to RFC 3101. thanks. >Section 12.1 - Add D and MT bits with informative references to [RFC 4576] >and the [OSPF-MT] drafts. "All eight bit ..." rather than "Six bits..". done. >General - Replace "stub area" with "stub or NSSA areas". sure. >Thanks, >Acee > Great comments. Much thanks. Lou _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 16 14:54:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknJY-0001Jt-Uh; Thu, 16 Nov 2006 14:54:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknJX-0001Jo-Pu for ospf@ietf.org; Thu, 16 Nov 2006 14:54:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GknJW-0001O9-F8 for ospf@ietf.org; Thu, 16 Nov 2006 14:54:23 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 16 Nov 2006 11:54:21 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAGJsKua002099; Thu, 16 Nov 2006 14:54:20 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAGJsKYJ028011; Thu, 16 Nov 2006 14:54:20 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 14:54:20 -0500 Received: from [10.82.208.5] ([10.82.208.5]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 14:54:19 -0500 Message-ID: <455CC1EB.4010508@cisco.com> Date: Thu, 16 Nov 2006 14:54:19 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Daniel Joyal Subject: Re: [OSPF] RE: inconsistency in draft-ietf-ospf-mib-update-11.txt? References: <4B7DAC3FEFD35D4A96BDD011699050140A42410C@zrtphxm1.corp.nortel.com> In-Reply-To: <4B7DAC3FEFD35D4A96BDD011699050140A42410C@zrtphxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2006 19:54:19.0880 (UTC) FILETIME=[014D6E80:01C709B9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1579; t=1163706860; x=1164570860; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20[OSPF]=20RE=3A=20inconsistency=20in=20=20draft-ietf-o spf-mib-update-11.txt? |Sender:=20 |To:=20Daniel=20Joyal=20; bh=jELWdO5mltZUKEj7uGnff9bx+gjK18wr5456BA2JYJo=; b=JDYr1borF5iUARmdr/zLDGGAsc9pDx1+rXPua+OENg5pUCFvlgFSYk+zB7fWIgzphQryVWed 8eWEb5GYHT5BWw2ipkF48btmAxxjY9WqGIQNNS0rJiToUS41LbzrJKp8; Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: pgalecki@airvana.com, ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Dan, Daniel Joyal wrote: > Lou, > > It is inconsistent. Thanks for catching this. > I don't think there is a reason to make Opaque > LSA support configurable as it is a backwards > compatible extension to OSPF, so the verbiage > about persistence should be deleted. > > Any objections? > FWIW, this would be my preference. Thanks, Acee > -Dan > > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Thursday, November 16, 2006 2:07 PM >> To: Joyal, Daniel (BL60:SF23); pgalecki@airvana.com; >> spencer.giacalone@csfb.com >> Cc: ospf@ietf.org >> Subject: inconsistency in draft-ietf-ospf-mib-update-11.txt? >> >> Hi, >> >> So, the following is taken from your draft: >> ospfOpaqueLsaSupport OBJECT-TYPE >> SYNTAX TruthValue >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The router's support for Opaque LSA types. >> >> This object is persistent and when written >> the entity SHOULD save the change to non-volatile >> storage." >> REFERENCE >> "The OSPF Opaque LSA Option" >> ::= { ospfGeneralGroup 16 } >> >> The access and description seem inconsistent. The >> description implies that acess should be "read-write". Am I >> missing something? >> >> Lou >> >> >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 16 14:56:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknLg-0003L2-3m; Thu, 16 Nov 2006 14:56:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknLe-0003Kw-U8 for ospf@ietf.org; Thu, 16 Nov 2006 14:56:34 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GknLd-0001oK-Bt for ospf@ietf.org; Thu, 16 Nov 2006 14:56:34 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2006 11:56:32 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAGJuWZM029673; Thu, 16 Nov 2006 14:56:32 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAGJuVYb028597; Thu, 16 Nov 2006 14:56:32 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 14:56:27 -0500 Received: from [10.82.208.5] ([10.82.208.5]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 14:56:27 -0500 Message-ID: <455CC26A.9080202@cisco.com> Date: Thu, 16 Nov 2006 14:56:26 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Lou Berger References: <455907D0.5010706@cisco.com> <5bg6vi$2pimgv@sj-inbound-f.cisco.com> In-Reply-To: <5bg6vi$2pimgv@sj-inbound-f.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2006 19:56:27.0315 (UTC) FILETIME=[4D427830:01C709B9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6275; t=1163706992; x=1164570992; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20Comments=20on=20draft-berger-ospf-rfc2370bis-00.txt |Sender:=20 |To:=20Lou=20Berger=20; bh=QIyCvp9/Yh8VzclUu5i/0jBm1X0E3c5DC+53z1h6piY=; b=PO8JfJt7twfbF6YP82fNlaax8bW6qsIz4RrCiEJydJPYbVw+rMgNcQwLQnv2KOGNVfUN99v8 BR73iRh3TAZul7mOWq6GsmYJyXEySBVGZiHkCKS/EnAEin6UGxFqecTQ; Authentication-Results: rtp-dkim-1; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: OSPF List Subject: [OSPF] Re: Comments on draft-berger-ospf-rfc2370bis-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Lou, Lou Berger wrote: > Acee, > See responses in-line below. > > Should the corrected version go in as draft-berger or draft-ietf? Let me poll the WG right now in a separate thread. I'll look at this more deeply later. Thanks, Acee > > Lou > > At 07:03 PM 11/13/2006, Acee Lindem wrote: > >> Hi Lou, >> >> My main comment is on section 5 (6 is your draft). The draft adds >> mandatory reachability checking for AS scoped opaque LSAs. >> If we add mandatory reachability checking, it should be for all >> opaque types rather reading like the constraint is unique to AS scoped >> opaque LSAs (type 11s). > > valid point. > >> I also think we should put the question as to whether the checking >> should be madatory or relaxed a bit to allow an application to check >> less frequently if the opaque data is stale. > > What benefit would this have? > >> Detailed comments: >> >> Section 2, third paragraph - "aligned" rather than "qaligned". > > yes. > >> Section 3, "Section 7" rather than "Section 7." > okay. > > >> Section 3.1 - Type 9 LSA - "keep" rather than "keepk". > > yes. Also I added the following to the beginning of the section: > Section 13 of [OSPF] describes the OSPF flooding procedure. > Those procedures MUST be followed as defined except where > modified in this section. > >> I believe we >> should discard a link-local LSA received from a >> neighbor not >> on the interface (text similiar to type 11). > > okay, updated as follows: > o If the Opaque LSA is type 9 (the flooding scope is link-local) > and the interface that the LSA was received on is not the same > as the target interface (e.g., the interface associated with a > particular target neighbor), the Opaque LSA SHOULD be discarded > and not acknowledged, and MUST NOT be flooded out that interface > (or to that neighbor). An implementation SHOULD keep track of > the IP interface associated with each Opaque LSA having a > link-local flooding scope. > > >> Section 3.1, Since the area ID is not in the LSA header, the bullet on >> area flooding is confusing. It should say something >> to the >> effect of only flooding type 10 LSAs out interfaces >> in the >> LSA's associated area. > > okay, updated as follows: > o If the Opaque LSA is type 10 (the flooding scope is area-local) > and the area associated with Opaque LSA (as identified during > origination or from a received LSA's associated OSPF packet > header) is not the same as the area associated with the target > interface, the Opaque LSA MUST NOT be flooded out the interface. > An implementation SHOULD keep track of the OSPF area associated > with each Opaque LSA having an area-local flooding scope. > >> I don't care if it said this in RFC 2370 >> and everyone knew what it implied. > > I don't know how to interpret the text otherwise... > >> Section 3.1, 2nd to last paragraph: "An opaque" rather than "a opaque". > > okay. > >> Swap sections 5 and 6 since "inter-area" is more the "meat" of the >> draft. > > done. > >> In fact, if the opaque MIB objects are all covered in the new MIB, we >> can >> probably remove the "management section". > > done, section will read: > > The updated OSPF MIB provides explicit support for opaque LSAs and > SHOULD be used to support implementations of this document. See > Section 12.3 of [MIB-UPDATE] for details. In addition to this section, > implementation supporting [MIB-UPDATE] will include opaque LSAs in > all appropriate generic LSA objects, e.g., ospfOriginateNewLsas, > ospfOriginateNewLsas and ospfLsdbTable. > > BTW just sent WG mail on one inconsistency between 2370 and the > updated MIB. > >> Section 6 (will be 5) >> >> 5. Opaque LSA Validation >> >> Opaque LSAs are not processed during the SPF calculation as described in >> section 16 of [OSPF]. However, they are subject to the same reachability >> constraints as the base LSA types. This implies that originating router >> MUST be reachable for the advertised application specific data to be >> considered valid. >> >> 5.1 Inter-Area Considerations >> >> ...... >> >> >> Section 5.1 >> >> Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem >> as a receiving router can detect an a loss of reachability through >> the intra-area >> SPF calculation. >> >> Section 5.1 >> >> To enable OSPF routers in remote areas to check availability of the >> originator of link-state type 11 opaque LSAs, the orignators of >> type-11 opaque LSAs are considered Autonomous System Border >> Routers (ASBRs) and will advertise themselves as such. > > > >> >> Section 5.1 - Remove "It is important to note that this solution MUST >> NOT ..." >> This is redundant. > > which part is redundant, just the sentence you are asking to be > removed? I agree that it is redundant with 2328, but I thin > mentioning it is still useful. Will rephrase to remove directive. > > >> Remove numbered items (1) and (2), these actions ARE NOT new to >> opaque LSAs. Make (3) a separate paragraph rather than numbered >> item. > > But inclusion of type-11 originate routers as ASBR is new. Will > rephrase to make clear that existing ospf requirements apply. > > How about: > The procedures related to inter-area opaque LSAs are as follows: > > (1) An OSPF router that is configured to originate AS-scope opaque > LSAs advertise themselves as ASBRs and MUST follow the related > requirements related to setting of the Options field E-bit in > OSPF Hello packets and LSA headers as specified in [OSPF]. > > (2) When .... > >> Section 10.1 - Correct NSSA reference to RFC 3101. > > thanks. > >> Section 12.1 - Add D and MT bits with informative references to [RFC >> 4576] >> and the [OSPF-MT] drafts. "All eight bit ..." rather than "Six bits..". > > done. > > >> General - Replace "stub area" with "stub or NSSA areas". > sure. > >> Thanks, >> Acee >> > > Great comments. > > Much thanks. > Lou _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 16 15:01:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknQg-0005Ae-Ro; Thu, 16 Nov 2006 15:01:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknQf-00057X-Eh for ospf@ietf.org; Thu, 16 Nov 2006 15:01:45 -0500 Received: from [216.246.62.14] (helo=esc91.midphase.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GknQe-0002dU-7x for ospf@ietf.org; Thu, 16 Nov 2006 15:01:45 -0500 Received: from [216.246.62.14] (helo=LC1.labn.net) by esc91.midphase.com with esmtpa (Exim 4.52) id 1GknQU-0001y2-Nw; Thu, 16 Nov 2006 15:01:34 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 16 Nov 2006 15:01:24 -0500 To: "Daniel Joyal" From: Lou Berger In-Reply-To: <4B7DAC3FEFD35D4A96BDD011699050140A42410C@zrtphxm1.corp.nor tel.com> References: <200611161910.kAGJAF403992@zrtps0kk.us.nortel.com> <4B7DAC3FEFD35D4A96BDD011699050140A42410C@zrtphxm1.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: pgalecki@airvana.com, ospf@ietf.org Subject: [OSPF] RE: inconsistency in draft-ietf-ospf-mib-update-11.txt? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Message-Id: Dan, Not from me. This would also be consistent with 2370 which states: An Opaque-option-enabled object is needed to indicate if the Opaque option is enabled on the router. Lou PS Blame this on Acee, his comment to me forced me to reread your draft! At 02:48 PM 11/16/2006, Daniel Joyal wrote: >Lou, > >It is inconsistent. Thanks for catching this. >I don't think there is a reason to make Opaque >LSA support configurable as it is a backwards >compatible extension to OSPF, so the verbiage >about persistence should be deleted. > >Any objections? > >-Dan > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Thursday, November 16, 2006 2:07 PM > > To: Joyal, Daniel (BL60:SF23); pgalecki@airvana.com; > > spencer.giacalone@csfb.com > > Cc: ospf@ietf.org > > Subject: inconsistency in draft-ietf-ospf-mib-update-11.txt? > > > > Hi, > > > > So, the following is taken from your draft: > > ospfOpaqueLsaSupport OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The router's support for Opaque LSA types. > > > > This object is persistent and when written > > the entity SHOULD save the change to non-volatile > > storage." > > REFERENCE > > "The OSPF Opaque LSA Option" > > ::= { ospfGeneralGroup 16 } > > > > The access and description seem inconsistent. The > > description implies that acess should be "read-write". Am I > > missing something? > > > > Lou > > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 16 15:03:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknSA-0006XF-DV; Thu, 16 Nov 2006 15:03:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknS8-0006S0-Lh for ospf@ietf.org; Thu, 16 Nov 2006 15:03:16 -0500 Received: from [216.246.62.14] (helo=esc91.midphase.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GknS7-0002xm-9w for ospf@ietf.org; Thu, 16 Nov 2006 15:03:16 -0500 Received: from [216.246.62.14] (helo=LC1.labn.net) by esc91.midphase.com with esmtpa (Exim 4.52) id 1GknS4-0002F7-3U; Thu, 16 Nov 2006 15:03:12 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 16 Nov 2006 15:03:09 -0500 To: Acee Lindem From: Lou Berger In-Reply-To: <455CC26A.9080202@cisco.com> References: <455907D0.5010706@cisco.com> <5bg6vi$2pimgv@sj-inbound-f.cisco.com> <455CC26A.9080202@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: OSPF List Subject: [OSPF] Re: Comments on draft-berger-ospf-rfc2370bis-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Message-Id: Acee, okay. I have a version updated based on your comments ready to go, so just let me/the WG know. Lou At 02:56 PM 11/16/2006, Acee Lindem wrote: >Hi Lou, > >Lou Berger wrote: >>Acee, >> See responses in-line below. >> >>Should the corrected version go in as draft-berger or draft-ietf? >Let me poll the WG right now in a separate thread. I'll look at this more >deeply later. > >Thanks, >Acee >> >>Lou >> >>At 07:03 PM 11/13/2006, Acee Lindem wrote: >> >>>Hi Lou, >>> >>>My main comment is on section 5 (6 is your draft). The draft adds >>>mandatory reachability checking for AS scoped opaque LSAs. >>>If we add mandatory reachability checking, it should be for all >>>opaque types rather reading like the constraint is unique to AS scoped >>>opaque LSAs (type 11s). >> >>valid point. >> >>>I also think we should put the question as to whether the checking >>>should be madatory or relaxed a bit to allow an application to check >>>less frequently if the opaque data is stale. >> >>What benefit would this have? >> >>>Detailed comments: >>> >>>Section 2, third paragraph - "aligned" rather than "qaligned". >> >>yes. >> >>>Section 3, "Section 7" rather than "Section 7." >>okay. >> >> >>>Section 3.1 - Type 9 LSA - "keep" rather than "keepk". >> >>yes. Also I added the following to the beginning of the section: >> Section 13 of [OSPF] describes the OSPF flooding procedure. >> Those procedures MUST be followed as defined except where >> modified in this section. >> >>>I believe we >>> should discard a link-local LSA received from >>> a neighbor not >>> on the interface (text similiar to type 11). >> >>okay, updated as follows: >> o If the Opaque LSA is type 9 (the flooding scope is link-local) >> and the interface that the LSA was received on is not the same >> as the target interface (e.g., the interface associated with a >> particular target neighbor), the Opaque LSA SHOULD be discarded >> and not acknowledged, and MUST NOT be flooded out that interface >> (or to that neighbor). An implementation SHOULD keep track of >> the IP interface associated with each Opaque LSA having a >> link-local flooding scope. >> >> >>>Section 3.1, Since the area ID is not in the LSA header, the bullet on >>> area flooding is confusing. It should say >>> something to the >>> effect of only flooding type 10 LSAs out >>> interfaces in the >>> LSA's associated area. >> >>okay, updated as follows: >> o If the Opaque LSA is type 10 (the flooding scope is area-local) >> and the area associated with Opaque LSA (as identified during >> origination or from a received LSA's associated OSPF packet >> header) is not the same as the area associated with the target >> interface, the Opaque LSA MUST NOT be flooded out the interface. >> An implementation SHOULD keep track of the OSPF area associated >> with each Opaque LSA having an area-local flooding scope. >> >>>I don't care if it said this in RFC 2370 >>> and everyone knew what it implied. >> >>I don't know how to interpret the text otherwise... >> >>>Section 3.1, 2nd to last paragraph: "An opaque" rather than "a opaque". >> >>okay. >> >>>Swap sections 5 and 6 since "inter-area" is more the "meat" of the draft. >> >>done. >> >>>In fact, if the opaque MIB objects are all covered in the new MIB, we can >>>probably remove the "management section". >> >>done, section will read: >> >> The updated OSPF MIB provides explicit support for opaque LSAs and >> SHOULD be used to support implementations of this document. See >> Section 12.3 of [MIB-UPDATE] for details. In addition to this section, >> implementation supporting [MIB-UPDATE] will include opaque LSAs in >> all appropriate generic LSA objects, e.g., ospfOriginateNewLsas, >> ospfOriginateNewLsas and ospfLsdbTable. >> >>BTW just sent WG mail on one inconsistency between 2370 and the updated MIB. >> >>>Section 6 (will be 5) >>> >>>5. Opaque LSA Validation >>> >>>Opaque LSAs are not processed during the SPF calculation as described in >>>section 16 of [OSPF]. However, they are subject to the same reachability >>>constraints as the base LSA types. This implies that originating router >>>MUST be reachable for the advertised application specific data to be >>>considered valid. >>> >>>5.1 Inter-Area Considerations >>> >>>...... >>> >>> >>>Section 5.1 >>> >>> Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem >>> as a receiving router can detect an a loss of reachability >>> through the intra-area >>> SPF calculation. >>> >>>Section 5.1 >>> >>> To enable OSPF routers in remote areas to check availability of the >>> originator of link-state type 11 opaque LSAs, the orignators of >>> type-11 opaque LSAs are considered Autonomous System Border >>> Routers (ASBRs) and will advertise themselves as such. >> >> >> >>> >>>Section 5.1 - Remove "It is important to note that this solution >>>MUST NOT ..." >>>This is redundant. >> >>which part is redundant, just the sentence you are asking to be >>removed? I agree that it is redundant with 2328, but I thin >>mentioning it is still useful. Will rephrase to remove directive. >> >> >>>Remove numbered items (1) and (2), these actions ARE NOT new to >>>opaque LSAs. Make (3) a separate paragraph rather than numbered >>>item. >> >>But inclusion of type-11 originate routers as ASBR is new. Will >>rephrase to make clear that existing ospf requirements apply. >> >>How about: >>The procedures related to inter-area opaque LSAs are as follows: >> >>(1) An OSPF router that is configured to originate AS-scope opaque >> LSAs advertise themselves as ASBRs and MUST follow the related >> requirements related to setting of the Options field E-bit in >> OSPF Hello packets and LSA headers as specified in [OSPF]. >> >>(2) When .... >> >>>Section 10.1 - Correct NSSA reference to RFC 3101. >> >>thanks. >> >>>Section 12.1 - Add D and MT bits with informative references to [RFC 4576] >>>and the [OSPF-MT] drafts. "All eight bit ..." rather than "Six bits..". >> >>done. >> >> >>>General - Replace "stub area" with "stub or NSSA areas". >>sure. >> >>>Thanks, >>>Acee >> >>Great comments. >> >>Much thanks. >>Lou > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 16 15:03:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknSd-0006qm-Al; Thu, 16 Nov 2006 15:03:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknSc-0006qh-7Z for ospf@ietf.org; Thu, 16 Nov 2006 15:03:46 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GknSa-00032V-TG for ospf@ietf.org; Thu, 16 Nov 2006 15:03:46 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 16 Nov 2006 12:03:44 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAGK3hOF000558 for ; Thu, 16 Nov 2006 15:03:43 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAGK3hDM014893 for ; Thu, 16 Nov 2006 15:03:43 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 15:03:43 -0500 Received: from [10.82.208.5] ([10.82.208.5]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 15:03:43 -0500 Message-ID: <455CC41E.8040607@cisco.com> Date: Thu, 16 Nov 2006 15:03:42 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: OSPF List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2006 20:03:43.0251 (UTC) FILETIME=[51190630:01C709BA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=741; t=1163707423; x=1164571423; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20draft-berger-ospf-rfc2370bis-00.txt |Sender:=20 |To:=20OSPF=20List=20; bh=NBlXrpSo12Eo9Wuqj70tSEFfCWMpb+iF5Xq98fmLqqw=; b=gVsARZMQesfgzBLdhlavbwESGvstfp0W9pIEdfc+FKxkfvt5453JqByHstHhDqafau3gc49L G7l8qO3kKrYkUCvPTwkZS4DZwkwfxVUKqvaa6FbmzzI0HqHqF8m91ssZ; Authentication-Results: rtp-dkim-1; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [OSPF] draft-berger-ospf-rfc2370bis-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org The authors of the subject draft presented a problem with AS scoped opaque LSA reachability validation Montreal and we asked them to go back and respin Rob Coltun's RFC 2370 since it is preferable to have a single draft tha covers opaque LSAs comprehensively than an addendum. The result of this work is the subject draft and it was presented in San Diego. Does anyone have objections to this being a WG document? The requirement has to fix the validation has been discussed for approximately 6 months and, heretofore, no one has disputed it. Consequently, I ask for objections prior to Nov 22, 2006. Note that once it is a WG document, the content is still subject to review, discussion, and modification. Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 16 19:15:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkrMi-0002Tx-Hl; Thu, 16 Nov 2006 19:13:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkrMh-0002Tc-4j for ospf@ietf.org; Thu, 16 Nov 2006 19:13:55 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkrMg-0003Yo-Cb for ospf@ietf.org; Thu, 16 Nov 2006 19:13:55 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZCv+2hyGb5n9oQ975G8zdAr3jNQZdmmZtchIjJmlGBbOJKLbkkvWXQu+mgOYtdSU; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.152.240] (helo=earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GkrMd-00048J-LQ; Thu, 16 Nov 2006 19:13:52 -0500 Message-ID: <455CFFAA.E39D6B25@earthlink.net> Date: Thu, 16 Nov 2006 16:17:46 -0800 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: sujay gupta Subject: Re: [OSPF] Comments / questions on RFC3623 and Update GR part 1 : BMA env References: <45590834.B988E949@earthlink.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79cadbe2db9f4d8a678740e6ec3d9be163350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.152.240 X-Spam-Score: 0.1 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Sujay Gupta, Let me give you some insight on part of this thinking. IMO, GR has added a few holes in our converged routing assumptions and that your update might be able to close a couple.. There is alot here!!!! Summary says to think multiple times before you exit prematurely based on a topology change (LSDB) and assume that you need router "X" no matter what. So... Why don't you tell me how a LSDB change is going to be communicated iff the env is BMA and GR router "X" is the DR and no BDR exists? I consider this a huge hole.. I don't really see a DR-other communicating LSAs to other DR-others to allow them to understand about a topology change. Second, lets assume that router X's is an extremely important router within our area with the connection to the internet, etc.. If it weren't we would / COULD just take it down. thus, we have router "X" is a DR, and is the ONLY path to a set of routes and end-systems within this area.. Then lets conservatively look that a topology change is a removal of a single router LSA that has no effect after a SPF calculation. If router "X" has sucessfully entered its grace period / GR interval, aren't we ... .... black holing the routers, routes, end-systems that reside on the other end of router "X"? .... since router "X" CAN not probe to verify that a topology change has occured. It is in non-stop forwarding mode.. It will still forward pkts to the removed LSA routes until... so what... The pkts that are forwarded by router "X" to say non-reach Z will cause minimal harm.. They will be dropped and most likely a ICMP message will be sent on the reverse path... The ICMP message might be interpreted by X, but if it is just forwarded, So,,, what we have here is the unability is to allow router "X" to state that its routes are of a level of imporantance that most topology changes should be balanced against a delay in making the change. New LSAs or changed LSAs that don't show up as primary LSAs after the SPF calculation COULD in theory IMO, also be ignored. The originator could in theory check out whether the LSA is needed to be communicated. (This says just because a minor toplogy change has occured do we need to go thru all the work and possibly isolate router's "X"'s dependencies). If we feel that the new / changed / or removed LSA should be communicated ... router X still isn't going to be in convergence until it resync it's LSDB If the change of LSA results in a better route, is it worth isolating router's X's entities???... Third, most large OSPF router vendors support the ability to set the LSA refresh time on non-DNA LSAs. If we are in a normal environment that the admin does this to decrease the number of LSA refreshes versus the drastic steps to using DNA LSAs. Then assuming having a 45 min LSA refresh would not be unreasonable. Going with this logic we have a few simple steps to take. One is that all HELPERS that originate LSAs, re-originate their LSAs upon first seeing a grace LSA in addition to router "X" doing the same. This allows us to take almost the full hour of the grace-time. If we could communicate a wished grace-time in excess of 1 hour, we could in theory send out DNA LSAs which would allow a static environment to support grace times in excess of 1 hour. :: Part of this logic follows the damand circuit support. Part of this is can, should we figure out a way to stop router "X" in his grace-period/interval from forwarding pkts based on obsolete OSPF control information.????? The other part says, why don't we just run in a degraded mode if we -realize that router "X" is so important that we would just isolate ourselves or so many routes/routers that we REALLY need to keep router "X" alive as long as feasibly possible. Third minor item is I didn't see any suggestion of removing entitites from HELPERS forwarding table based on removing the GR router because of a LSDB change. Mitchell Erblich ------------------ Hi Mitchell, I have some comments inline; On 11/14/06, Erblichs < erblichs@earthlink.net> wrote: Group, First, I have a few questions to the base and the update. These comments / questions pertain ONLY to BMA envs but are also relevelent to other envs. FYI) IMO, helpers are defined by two major requirements a) the ability to recieve a grace-LSA before a hello "new hello" and not restart the adj b) the ability of a helper "Y" to (re)send a router-LSA, etc upon router "X" exiting graceful restart that are in its retransmit-list. If this "helper" split functionality is supported, then only a limited number of routers within a area need to be in Full-helper mode. Within BMA envs a DR-other above helper "b" functionality is not really necessary for retransmit. We use the DR/BDR for retransmit support. IFFFFFFF, a GR router is the DR, who is in it grace-period, and a DR-other stops sending hellos, if their are no alternate paths thru another router for any forwarding data. Then what benefit is it to prematurely end helper mode? Basicly, most algs can determine ahead of time whether the exiting router has contributed a primary link/path. If it isn't then it has no consequence. Yes, data pkts that have a intermediate dest will be forwarded 1 or two extra hops, before they are dropped. (Update: 2.0 Action on route calculation) If a topology change occurs and the GR restarting router is identified as the next hop. By definition it is in non-stop forwarding mode and should be able to forward packets. If this is identified as a topology change and the ONLY route is thru this GR router, shouldn't packets be forwarded thru it anyway? Not doing so blackholes those routes, IMO. Suj>> Here topology change also includes routes which are no more valid, if the lsa seeks a route to be removed and that route involves the GR router the helper exits, thus black-holing and circumventing the GR router as router under plain restart.Note here that previously(rfc3623) the helper was exiting for all reasons, which has been curbed now so as you have pointed out if the lsa effects the route which is ONLY through the restarting router will the system exit, which makes sense. Yes, and no.. Router X, once he has entered GR, is not in the mode to accept topology changes.. He will forwarded no-matter what based on his old information. Thus, any routing inconsistencies done by him until his GR time period ends CAN result in him routing pkts improperly. This is basic IP forwarding. The originator of the change will be the one who can make the correct IP forwarding decisions with reciving or forwarding IP pkts based on the LSA change. However, because router X is no longer in sync, should he inform others not to send or allow reciept of data pkts from router X? At the end of the grace-period or when router X re-enables his OSPF control code, he can be resync'ed. Until then, yes we SHOULD have some level of AI that determines the benefit of keeping router X in GR. Second, most environments have most of the LSA changes not result in any primary path alterations.. Thus, 1) Helpers should be able to be able to support a, without b If this is the case, router "X", if it is a DR should allow all the DR-others to support a, while only the BDR need be a "Full-Helper". Suj>> I like your analysis in breaking up the helper job into partial and full. IMO "Helper" is a behaviour of a router w.r.t to the GR operation, where as the idea whether the helper is "Full-helper" else a "Partial" depends upon the result of election. In brief a "Helper" is always expected to perform "Full-helper" features as per your describe , if it does less; guess it is plain lucky ! ,( also note Helper support maybe a feature switched on / off by admin, not a partial/full helper). 2) If router "X" is a DR-other only one of a "DR or BDR" need to be a Full-helper. All LSAs can be placed on the retransmit list of the for router "X" by the DR or BDR. 3) Topology change. A LSA aging out of the LSDB, will not necessarily remove a element in the forwarding table? If this can be detected, should it still force the exit of a helper wrt graceful restart? Suj>> as per the base ospf operation a max aged lsa on the lsa, should trigger it to flood the lsa (-->" which in turn should instigate the originator of the lsa to resend a fresh copy, if fails ends in removal of the corresponding route everywhere! "), thus if the case happens as you have described a GR with "strict lsa checking enabled" i.e catch all topology changes should force the helper to exit as it has to flood this lsa to the GR router, here the update draft would tell you prohibit your exit only if the lsa somehows affects a route through the GR router, else let peace prevail, no need to exit. 4) If router "X" is a DR and has entered graceful restart with no BDR present, should the DR-other routers allow the LSAs to become not refreshed and aged out because the grace period has not expired. How can "one" or more "HELPERS" force a new DR election? Suj>> IMO the DR-other allows normal aging to continue, if the lsa age's out before grace period expiry, the helpers would exit GR(see above) , again applying the same logic. A new election would disturb all previous adjacencies, do we need it? 5) Even with a 30 min max for the grace period, some routers may only retransmit once every 45 mins or so. How can we guarantee that those retransmited-LSAs are not aged-out if router "X" is the DR and is down for a longer time? Shouldn't recieving the first grace-LSAs from a restarting router initiate a re-send of the LSAs? Suj>> With the LSRefreshtime is 30 min , the MaxAge double(60min), the max grace period is same as LSRefreshtime 30 min, I dont see how we reach a stage where the problem will come, you might want to consider some border cases i guess there the previous arguments(see above) hold good. Mitchell Erblich Best Regards, Sujay _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From efbkchnd@aerotech.com Thu Nov 16 21:11:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GktCl-0006ut-53 for ospf-archive@lists.ietf.org; Thu, 16 Nov 2006 21:11:47 -0500 Received: from [220.78.107.128] (helo=mycom) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GktCg-0002na-Qi for ospf-archive@lists.ietf.org; Thu, 16 Nov 2006 21:11:45 -0500 Message-ID: <000b01c709ed$b39257c0$6401a8c0@mycom> Reply-To: "zev" From: "zev" To: "karem" Subject: tell me whatcha think Date: Fri, 17 Nov 2006 11:11:32 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C709ED.B39257C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.2 (+++) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C709ED.B39257C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C709ED.B39257C0" ------=_NextPart_001_0008_01C709ED.B39257C0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Into something rich and strange.me with mock praises and your other = lover Demetrius, who used almostfind. in the king's heir, his longlost daughter, being found. When Leonteswas = proceeding to marry them, when he was interrupted by Benedick, whothought = would certainly be killed. Protheus was greatly delighted at receiving this favourable answer he had prevailed upon Silvia to leave her father's palace that night,have = done, and leave her on such slight conditions. Then turning toThis is = true, said Posthumus but this you might have heard spokenwas kept = inviolate many years. Cordelia then told her father, that he was her father, that he hadknow = what he did but that to be sure she had great cause not to lovefrom this = time the thoughts of Macbeth were all bloody and dreadful. would no more disturb him and he was preparing to return home, when would no more disturb him and he was preparing to return home, whenshould = have free leave to address young Bianca.countrymen was in this danger, = but he little thought this old merchantseparated in the storm in his = infancy but while the poor old AEgeon again. I pray you answer him. Isabel then went out to Lucio, andBut the = duke was absent only while he threw off his royal robes andto the rough = and unbending cynic, who affecting a contempt of men's be a thankless and ungrateful people, giving disgust to their generals of lord Capulet, who knew him by his voice to be Romeo. And thiswhich she = was he appeared to her eyes as one dead in the bottom of alittle about = life to fear the losing of it and as to his soul, heput in the names of = those two courtiers, who had the charge of him, demanded the handkerchief, which when she could not produce, she trieda = thing too young for such a place. This is the child of your deadsaid, = replied Marina, and said no more than what my thoughts did them, no trade or commerce, or wish to visit other shores yet they sails, and sit in your ship in peace the north wind shall waft youblood, = without restraint from her son, and now she knew him to be hernever die, = with shame and when he pledged his vows to his Penelope,stream till it = reached the sea, where the fair hands of Ino Leucothea the feast was ended, Demodocus being called, as was the custom, = toinevitably perish. He answered in a low whisper, 'Hush, lest any = GreekFrom the house of Eumaeus the seeming beggar took his way, leaning on heaven, than that which hung over them this day by secret destination slaughtered bodies of the suitors dragged forth of the hall. And theyto = study by some other means there would no longer be a pretence for A hen, she said, was a hospitable bird, and always laid more = eggsconsidered myself as transformed into the dependant person. Indeed = sirkindly, and say, How do you do, little Margaret But I do not particular, who hung by the side of a glass door which opened into the brought quite to London, do you not expect some perilous end of = thischurch, or that could satisfy me about its form. Sometimes I = thoughtthan that which we had passed together, and he should never come = back ------=_NextPart_001_0008_01C709ED.B39257C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

3D""


Into something rich and strange.me = with mock praises and your other lover Demetrius, who used almostfind.
in the king's heir, his longlost daughter, being found. When = Leontes  was proceeding to marry them, when he was interrupted = by Benedick, who  thought would certainly be killed.
Protheus was greatly delighted at receiving this favourable = answer         

he had prevailed upon Silvia to leave her father's palace that = night,have done, and leave her on such slight conditions. Then turning = toThis is true, said Posthumus but this you might have heard spokenwas = kept inviolate many years.
Cordelia then told her father, that he was her father, that he = had  know what he did but that to be sure she had great cause = not to love  from this time the thoughts of Macbeth were all = bloody and dreadful.
would no more disturb him and he was preparing to return home, = when         

would no more disturb him and he was preparing to return home, = whenshould have free leave to address young Bianca.countrymen was in this = danger, but he little thought this old merchantseparated in the storm in = his infancy but while the poor old AEgeon
again. I pray you answer him. Isabel then went out to Lucio, = and  But the duke was absent only while he threw off his royal = robes and  to the rough and unbending cynic, who affecting a = contempt of men's
be a thankless and ungrateful people, giving disgust to their = generals         

of lord Capulet, who knew him by his voice to be Romeo. And thiswhich = she was he appeared to her eyes as one dead in the bottom of alittle = about life to fear the losing of it and as to his soul, heput in the = names of those two courtiers, who had the charge of him,
demanded the handkerchief, which when she could not produce, she = tried  a thing too young for such a place. This is the child of = your dead  said, replied Marina, and said no more than what my = thoughts did
them, no trade or commerce, or wish to visit other shores yet = they         
sails, and sit in your ship in peace the north wind shall waft youblood, = without restraint from her son, and now she knew him to be hernever die, = with shame and when he pledged his vows to his Penelope,stream till it = reached the sea, where the fair hands of Ino Leucothea
the feast was ended, Demodocus being called, as was the custom, = to  inevitably perish. He answered in a low whisper, 'Hush, = lest any Greek  From the house of Eumaeus the seeming beggar = took his way, leaning on
heaven, than that which hung over them this day by secret = destination          slaughtered bodies of the suitors dragged forth of the hall. And theyto = study by some other means there would no longer be a pretence = for       A hen, she said, was a hospitable bird, and always laid more = eggs
considered myself as transformed into the dependant person. = Indeed sir     kindly, and say, How do you do, = little Margaret But I do not   particular, who hung by the side of a glass door which opened into = the    
brought quite to London, do you not expect some perilous end of = thischurch, or that could satisfy me about its form. Sometimes I = thought    than that which we had passed together, = and he should never come back
------=_NextPart_001_0008_01C709ED.B39257C0-- ------=_NextPart_000_0007_01C709ED.B39257C0 Content-Type: image/gif; name="0j138fd5fO.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhIAIyAcIAAAQCBCSOBNQKLGRenCQSlKSKRAQC5Pz+/CwAAAAAIAIyAQAD/ni63P4wykmr vTjrzbv/YCiOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16 v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqb nJ2en6ChoqM0BKamC6eoCqqrq6wEsLEHrbOtD7esDbOwDLm0vMC+wbK2u6TIcsHGqboOr8LOtLi+ z9XT173N29DdxMvSxMnjauDYzuLTxrzs1NvZ2N/c7/H17efp+OT7a+b+1OvepTMHj5nAcNdiBURH 71g+fhDB+FOVKpdCXfeAUdQI/o2erVrS4m1UhzGkQXcRU475dXKgtowuz+0aKU8ms4kM50V4qLIn lpj6rEWDiRIoPJEbiQ4t5koCT59Qpxg92TCoTI9Cj1UTd1HnVqEEr0YdS8WoOotgXaE9arbr17dw BZ7SSrau3bt48+rdy7ev37+AAwseTLiw4cOIEytezLixoAAKIJ+Q7JiMABWXHVA+IDmAZwafG3gO zXm05s0SRlM2vYA0Z9GkVU9Arboz6Mifa+dmDRo1bN+iP8gGAbxyk8wokN9uzbx38OarYVfYHN15 8+Wvrz+grRk79+u0i2cfv124dg7ijQvpeEC5AgHwF2SeLz9+/cvw7WuvHrm//v/u/2WXHnnP+ccf eBd8h914CjK4HHDfDScgbq7x5l1/ubUWW4XqJTHSew0gR197IJJYonvuQbegbQFeqGJqEVD3n2/U DdhibS/e6KKB5T34IosTtuhgaTlCxp+NHfLwoYnyNUkifibmZ59+TD4nY5EadmZhkDF2iWWBGs4G Zo4E1ugalwtyySKQWm5ZWmw+9sYbkknuwB6KTkIJZZUMTAkBkAziWCaPWbqZpneC0vgnjIei2SCg ugH45ZpkSrqfjpbWuQSeJTIpopN5xqjgleSxeamQpSJY6ZAzZlrcmY+qiuqRP7bK6nmpOnigpk5I OR+Vn94nbH3bmRmgmQdC/oorhauFdiWOc1pIo2yC4ibninGi+qaLlM54ppCkRksqr6TQqYK55KZ7 BLoosKvuu/DGK++89NZr77345qvvvvz26++/AAcs8MAEGzbAwQgnrPDCDDfs8MMQRyzxxBRXbPHF GGes8cYcd+wxxOkOkJLIPZHMq8n8oByRykmyPI7L+8BsnMyk0JyMzY3hHIrOo/CsmM+eAA2K0IcR bQYAPBh9tA9KEyYzVxoN88xcTM2EAgBYI71A1lpb0HUDXx/A9QNhb5212WMzILOE0o5LYaEnpK2A 3B2UPbcDZ6Ntt9h58033Ak0P9jRYVhdkktQmfK214l7L3bfYDISNNdmR/t8dAczhSrdssiUwDvnW HnDd9eOfVw462KbvrXbITmXzT0iG55TC4qZPgPTeqjNut+eqH+CyeM9uvuzVlhevwe0QeI766bV/ 3rsCgQtGM0Gvi3W47MSXrn0EyFOe/Om7p/637z2Wr2b57tZt/PMSdI935I43v/7c40PP+k6uY4WP WlTbFPfk86sAAN8HtgGOznvGY579MrUjNO3HUCHom/I2MMDlBXCCAbTg6shls5boryYerAoJaKdA 21UwgeITHd7qF7bfeSlXEFrU7DLIAdJpT3kqXKENt7fAk00ghBxpSkLksqTO0dB2CcwdAduHwB42 ylvDiaH5EnfE4yWx/nnhY+ISN+jDH4KQcF4hCV0imDr5aVFyWNxi2Q5YQsxxqztSzNUIeGfGDJBQ gRi84RLzSD4OUsAbbiFiRrRxFBDQrX5kO6TjdojDE45vbeIi0GsiJa70UUCRJ7QjJg34ONKNzpE7 7GMX7cA+GERPDKWMwSkBs8ovpNIFrXQl0+4HkVhWwpZ8wSUkdCkJXubFl40A5iOEaRdiKsKYjEDm WJR5CGYmwpk+gSYhpGkIao7smiUL2ce2yc1uevOb4AynOMfpTVqmLJrmjBk6/biydY7ynNlkZy3d qSlrBsKeg8AnPOcZz3fS4ZUt0KcSAArLdFaFHWGRBew+grgRAuCh/vCD6AXW+NBPVrR3Fq1oBWC2 pA95o6EruGhECdpEv2nUpBItYEovmlIKCJQcHM1KN4qilY+OsIwl5J5I9cjD5LERAy6jnuuWQdQW 0DGnGGCp9553VA289GX4O4hV8jfEhWSPj+9DI/gEWDqSBhUl87AqVVhwx556zaxdReJWN/DUm0UV IVOValhLMkOeIlGrllPqUvWWyq9mZa5irAcMykpS0CmRfifV4OJ2aoG2ImNwYRxrXBcSyDmutI6J 1CHu9vg9l0KAJoSjbCH/91O0CnCznU3jFifg2Jq1bqqSHaRghXhVzCaytFkcaWKR6gCcjfUmNxlt XbE60ZaiEKl6/tUgaw06RKbEtiHAhZ0R7XrJvNYRo6mVgG+lG12k9M+oVbRjeHmL3Au0tmdePKj1 hMrd6VqXvAQkbAbXiMeNgnWQsg2sCOeI0+Mm9Yg45Cx8G3BeUXQwvwq5xXcX/FcRMNakjdvtgyes xt1q97Pf5UghK2s9h7b0wcejsGZrZ2EQL1eedShsCgosBBWrgMVDw4OLTwBjIMwYBTUOGjZVkuNO 9DgOP55DkDUxZDcUGQ5HvkSS17DkNjSZEk9GQ5TVMOVIVLkMVz5Dlh1Bzi57+ctgDrOYx5wx5rq1 n/XcsZrrtGUxtJkMb15EnL8w5zDUGRF35kKevbDnQvQ5C3/e/kKgBTFoKxQaC4f+Q6KnsOgqNJoP j6Zg0vJwYxqb+QAFyHSmF6DpTTOg058GtQI67elRa5rTpcZ0AYr7YQurVaUl1RtfSykzYClnSvnp E66l9J5bG1LCrrZiSSccbAjL+gGR1oPMVs3pUX+62dDG9LOl/QBmO/vaqD7rWv2r2dIWsIllbWwE bK3rTvm6U+UGVQ37a9pLMlbC7Kbvtnua7Dwse9rWpna+r51vZu8b2w7oN8C1TdzK4TWr4Ob25SAw oieBqOHn5tPD1W3I8XIVtRc0Y1PpfWmBU5vfAQe4v6sdAY//u7rU5d72kuu8hKNU3A+AeJRmju5g hchTN035/n8xHl+NxxvZHce3qD8ObZOTeuDTJvrJb1vf0yq2eLntKa1j3qeJO7w9vAaVr0bU8NBd dsAmzC6JfT5vu9UbD8se+sijXXS1kxwC1vb4RC2uw6az1LgvXy0EXHbuX52o6uamutUdTPfTyht+ qlXpSk0syjTD/e0f//faG3DypUf+6P/VucpbnlP2RX3hDtj6ibgOeJyHvkkpCl3hUX5wHhZc6kBH MeUhH/mkV/7x0Z48213+epzm8fdNP3HpUX/6Ktk89bdOfebfq3Curvy6Y1euf89+h3uH3Pan3r2p h67qUp9a8u5uNd59CuzxN1Jyxe5t8aueol/lutfuf3/y/n8t/hmzXK93PzbUjZt+6tvB/86nAwAY gDswgEImY5OGgD1ggHLAgEbggEgAgW8ggUNAgUVggWyAgUCggULAgWnggQtIT2y2Zvx0MmR2giiY giq4giy4MAXzgjAYgzI4gzRYgzZ4gziYgzq4gzzYgz74g0AYhELYAS1YhEZ4hEiYhBbjT0NoaEzY hFQAglgGhYD2hFQYBVIIZ1d4BVk4Bl2YL19oZ1uoerPkeGBQaZOQf4hVShS1eO9WbMQ2fk7UIUcW h2wodnb4amooAhNRVDPxCkXEHhXREQtWC7+gd5qnWxmnRoyYiGEIBkATFjZlE5KoRczXbskFb2Wn U2DX/gHsVRFjZBDfkA+fmF8dBn3w5T6L+HSsiFWPSGehp3yS6IeUGDvOV3CqmHiwRzneRgKfKFgd hl/StV41BVbk93UKl4vLk4lkd4l784p8FiLvB0ay0xX3UD23aFuQw3PSt4sZhYbF+EH7JYzBWBPc wGCZ93pyaFby1YqYBY1doDJZhwtfRFfXWDjhF3w+JXYlFGy92HwaAETAiFAfQYjDCIoLNYxP0XNg V2KHxUeZyHiNR4ex6BT1aA9hFA1zl4gRpXfr2IYmBo6RNYhUU49EVUThmJEHuXm9d0dMVXifBzhW GFUEWZL2yBIruVcNeUXaaFrcGAIGeT3+YxUJNZRE/mmMvNeTnBd17eh6sSaTZlgB2CiKIVSUqtWS PHlcAWZBvReQJymUGnY9VtlRM9VgxzhSJpRYe5iHzOOQvQOPeoYBUxkOVSlc+mdsOlV+ErWWmohF 6ecIIkkCcCloqFQYgTkCg6kFiXaY9ZKYVTiGUTiTkLkEjolok8loknmZEZiZmvmAnNmZRFCZXAia TyCaTlgvjAmJn7kXbPlqd8l4uKOWLEeZq2kEImJzHcA2FeI2lfQnW9I2uiEhjaiOO7Vx6JeUmBmV TzB/6LYBmWMd4HIq2GIrklSdZ6SNuWicBoecUmCajjYFvgZx+kF6YzKdu3IrU4QpcURw2OmTCBRu /hckkZupnEfAKcRHczTXddoCQ7hSI6nRIAIiLRGmj5nFj2mllajYBN4ZmUyAm38Xf/ShJwx0Kuc5 Lf95HoAyPCyplA65QrqFd7MJkBVYmz6gnw/anA63J08UKFE0odZZKRm6n52FlQfajTuJiPM5gsch cZ4ic4FnPrSyKpwDJkFanTainWoFn5jYjF3ZgST6A8p3m8Pyo8WyIcryJrvRLN/CLL/RKEgCAGCq OGGalmA6a2tYpqzoN4oHBQuanPSSmrBIn/ACp9Eop6R5BG3anXeqoE+6pwVogkoYqII6qIQaZn56 qIiaqIq6qIzaqI76qJAaqZI6qZRaqZZ6qZia/qmauqmc2qme+qmgGqqiOqpecIcvQKeNGqaoinKG 15Fm04mF+QFoyjcEaKOV6h5NGjfaxnlLKaKx6nWvyqo4SqkpEps/ZVHvuYYjpqYCxka0w1SzqqrJ ilhteTezqqzWulhiiqzb2D3SCmHcipfb6T5jqn/l2m6RmnrXuozbdnguKWBSF61tqaTVWqPbCXX4 SqvNeqxZeTvO2q752ovI460A65TEenOcaK5d9a3RJ7D12rCdRz/T+o/kWrAYR1jfeq0H964H+q8o RELaiqbO2nrpSnEzWq3/WK8Om68Q+7G8qrLlxa8dm1pN+W3PZ7E467K9ypWI56uIaqJ2p48r/sur 7hqxzKdV8Omx7NiyL8u09kq0PKW0HDu0R8uyPsuoKnpb24pB57qm4tqzXeuq1MqVxvqwytW1GXuW SRStGiuyKSSmCyuz8hOuxoa2mKp8MrCqg8Vf4EWqbKC3LhCYgIuuflu4hnu4iJu4iru4jNu4jvu4 kBu5kju5lFu5lnu5mJu5mru5nNu5nmsIBhC6ohu6DUC6pWsACjC6qpu6qiu6E9C6pwu7D9C6qPu5 oFu7C2C6rOsApqu7vIu7FeC6uau7vnsAxSu8w2u7hVC8xgu8vku8wHu6GMC80Pu7DEC90au8f4C9 0tu815u9yWsBzLu73tu95au9isC930u+/uxrveILvuWrvueLvohwvOA7urG7uqwru7MLv70bvc8L v/QrCLTrv8jbvuZLAeMbv7SbwPo7wH5Qvf3bvgs8v69rwOwrv+sLwRHsvPdbuwEcARXsvu4bwhuc wBysB/brwLhbwSNswie8wiccvim8B/Krvi4swPN7wMirwQdswTV8B+P7vyVcwPvLv9iLvzNMw0f8 w0H8xJRbwFI8xVRcxVZ8xVcMxVq8xVzcxV78xWAcxmJMg9i1BYM7xoZ3mJ6HoLVKhqeKxjqQsuvm msNqq0RwxnBsiXGrta7KsGhDtGVKr8oKsmi7rnkVtkcrr9aFfvKqrQ97rpB8s1D7tNtY/qOFXLbW iq2V2lRFO7PDOT9r/F5Sy5AGO7Xg08luu8hNO7II96wtp4yNDLM66zwcu8n9hcrzFrQ3ZMjNGrB+ XLXs6slNG7AwS67fiKAEm8wGi0cZ+8vCLMeOKre4fIm6jKR+Kcsnq5Uyq7RMy6/ydnioozv3aq8V K33bbLaT+suIbMltW3cuGcjoLLH717aGXMuKRc9KyrDbOs6XTK+q+M+W/MiQXK77vD7rzMWhfLXL Jwl4vLm5Kl6RcNB5PNEUXdEWfdEYndEavdEc3dEe/dEgHdIiPdIkXdImfdIondIqvdIs3dIu/dIw HdMyPdM0XdM2fdM4ndM6vdM83dM+IP3TQB3UQj3URF3URn3USJ3USr3UTN3UTv3UUB3VPpAAADs= ------=_NextPart_000_0007_01C709ED.B39257C0-- From ospf-bounces@ietf.org Fri Nov 17 04:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkzc5-0007bA-DP; Fri, 17 Nov 2006 04:02:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkzc3-0007ae-QS for ospf@ietf.org; Fri, 17 Nov 2006 04:02:19 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkzbz-0000lp-Tt for ospf@ietf.org; Fri, 17 Nov 2006 04:02:17 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kAH92Etk027338; Fri, 17 Nov 2006 03:02:14 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 03:02:13 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 14:31:25 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 17 Nov 2006 14:31:24 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD42419651210D1@INEXC1U01.in.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended Thread-Index: AccJlzpElgH+Mi0rTSuqxTpmNFJkpAAjNS9w From: "Bhatia, Manav \(Manav\)" To: "Phil Cowburn" , "Acee Lindem" X-OriginalArrivalTime: 17 Nov 2006 09:01:25.0467 (UTC) FILETIME=[F5F222B0:01C70A26] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Phil, > > Some discussion on list already > > > > Crypto - only md5 to date, can be attacked, some want=20 > stronger algs > > perhaps should specify these > > > > How - 2328 can add other algs w/o too much problem >=20 > Yes it does, but debugging would be a nightmare! :-) > > Let me not trigger a discussion again, i am ok with using the existing > type code! We had posted the revised text based on the comments that we had received both on the list and offline and there was quite a discussion that followed! http://www1.ietf.org/mail-archive/web/ospf/current/mail6.html The consensus that we all had reached on was that before this draft one could only have a key mismatch. From this draft onwards we will have a key/algorithm mismatch. [clipped] >=20 > > >=20 > I dont see any show stopper comments, so what is the status of the > auth drafts? There was a discussion on these drafts some time back and > the consensus was that the drafts would not be changed and we would > reuse the existing type code for additional authentication types. >=20 > If there are no further comments then should these be taken=20 > up as a new items? Yes we would like to progress these drafts as a WG items.=20 Cheers, Manav _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Nov 17 12:34:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7aM-0007b2-Gv; Fri, 17 Nov 2006 12:33:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7aK-0007aw-Jd for ospf@ietf.org; Fri, 17 Nov 2006 12:33:04 -0500 Received: from web27204.mail.ukl.yahoo.com ([217.146.182.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gl7Zq-00005R-Gm for ospf@ietf.org; Fri, 17 Nov 2006 12:33:04 -0500 Received: (qmail 65584 invoked by uid 60001); 17 Nov 2006 17:32:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kZHdWuxstH3Fu3qHep84qSEzzcn0VUTVMJ4x0XuH6HEsj2T4z2V0b1QkTjWyajglOpp6c343VxNcPJpWfMmmVrB4fmnwViku7eyL84E22z+0fpTEYYBoCjQdNqkLK7p9PEVCaTyVoaRkxlmHh1D6sHcGZTg4y3vWDNId/9X0bj0= ; Message-ID: <20061117173223.65582.qmail@web27204.mail.ukl.yahoo.com> Received: from [59.144.51.93] by web27204.mail.ukl.yahoo.com via HTTP; Fri, 17 Nov 2006 17:32:23 GMT Date: Fri, 17 Nov 2006 17:32:23 +0000 (GMT) From: John Smith Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended To: "Bhatia, Manav \(Manav\)" , Phil Cowburn , Acee Lindem MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org I am willing to accept the SHA authentication draft as a WG item. =0A=0ATha= nks,=0AJohn=0A=0A----- Original Message ----=0AFrom: "Bhatia, Manav (Manav)= " =0ATo: Phil Cowburn ; Acee Lind= em =0ACc: OSPF List =0ASent: Friday, 17 Nove= mber, 2006 2:31:24 PM=0ASubject: RE: [OSPF] IETF 67 OSPF WG Meeting minutes= - Correct file appended=0A=0A=0AHi Phil,=0A=0A> > Some discussion on li= st already=0A> >=0A> > Crypto - only md5 to date, can be attacked, some = want =0A> stronger algs=0A> > perhaps should specify these=0A> >=0A= > > How - 2328 can add other algs w/o too much problem=0A> =0A> Yes it d= oes, but debugging would be a nightmare! :-)=0A>=0A> Let me not trigger a d= iscussion again, i am ok with using the existing=0A> type code!=0A=0AWe had= posted the revised text based on the comments that we had=0Areceived both = on the list and offline and there was quite a discussion=0Athat followed!= =0A=0Ahttp://www1.ietf.org/mail-archive/web/ospf/current/mail6.html=0A=0ATh= e consensus that we all had reached on was that before this draft one=0Acou= ld only have a key mismatch. From this draft onwards we will have a=0Akey/a= lgorithm mismatch.=0A=0A[clipped]=0A=0A> =0A> >=0A> =0A> I dont see any sho= w stopper comments, so what is the status of the=0A> auth drafts? There was= a discussion on these drafts some time back and=0A> the consensus was that= the drafts would not be changed and we would=0A> reuse the existing type c= ode for additional authentication types.=0A> =0A> If there are no further c= omments then should these be taken =0A> up as a new items?=0A=0AYes we woul= d like to progress these drafts as a WG items. =0A=0ACheers,=0AManav=0A=0A_= ______________________________________________=0AOSPF mailing list=0AOSPF@i= etf.org=0Ahttps://www1.ietf.org/mailman/listinfo/ospf=0A=0A=0A=09=09=0A____= _______________________________________________________ =0ATry the all-new = Yahoo! Mail. "The New Version is radically easier to use" =96 The Wall Stre= et Journal =0Ahttp://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Nov 17 13:07:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl87f-0000DX-AK; Fri, 17 Nov 2006 13:07:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl87e-0000DS-Gc for ospf@ietf.org; Fri, 17 Nov 2006 13:07:30 -0500 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl87a-0004RH-6s for ospf@ietf.org; Fri, 17 Nov 2006 13:07:30 -0500 Received: by wx-out-0506.google.com with SMTP id h29so1027462wxd for ; Fri, 17 Nov 2006 10:07:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MeR4UT4v59xKksvYpAQl9WzUBaQmhf1P81PiDkNpBrmwBwIRolzJYvehkxyhMtskX8cBsxVN5ypAzmZcaCjo3ls+D5BNNPYq4UlcwfjyG8BxeHiCPmm8ugtpPNuhHiWSa76Q71lXv8wp52HSufA9Pynp3m6/OX64MHCIaX65oZM= Received: by 10.70.52.1 with SMTP id z1mr3552979wxz.1163786845514; Fri, 17 Nov 2006 10:07:25 -0800 (PST) Received: by 10.70.33.14 with HTTP; Fri, 17 Nov 2006 10:07:25 -0800 (PST) Message-ID: <77ead0ec0611171007m6c12e615m5daeadcefdf73bb8@mail.gmail.com> Date: Fri, 17 Nov 2006 10:07:25 -0800 From: "Vishwas Manral" To: "John Smith" Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended In-Reply-To: <20061117173223.65582.qmail@web27204.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20061117173223.65582.qmail@web27204.mail.ukl.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Thanks for the support John. I guess we need to ask the WG chairs what they want us to do. As far as I see it there has been some consensus on the drafts on this list. Thanks, Vishwas On 11/17/06, John Smith wrote: > I am willing to accept the SHA authentication draft as a WG item. > > Thanks, > John > > ----- Original Message ---- > From: "Bhatia, Manav (Manav)" > To: Phil Cowburn ; Acee Lindem > Cc: OSPF List > Sent: Friday, 17 November, 2006 2:31:24 PM > Subject: RE: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file append= ed > > > Hi Phil, > > > > Some discussion on list already > > > > > > Crypto - only md5 to date, can be attacked, some want > > stronger algs > > > perhaps should specify these > > > > > > How - 2328 can add other algs w/o too much problem > > > > Yes it does, but debugging would be a nightmare! :-) > > > > Let me not trigger a discussion again, i am ok with using the existing > > type code! > > We had posted the revised text based on the comments that we had > received both on the list and offline and there was quite a discussion > that followed! > > http://www1.ietf.org/mail-archive/web/ospf/current/mail6.html > > The consensus that we all had reached on was that before this draft one > could only have a key mismatch. From this draft onwards we will have a > key/algorithm mismatch. > > [clipped] > > > > > > > > > > I dont see any show stopper comments, so what is the status of the > > auth drafts? There was a discussion on these drafts some time back and > > the consensus was that the drafts would not be changed and we would > > reuse the existing type code for additional authentication types. > > > > If there are no further comments then should these be taken > > up as a new items? > > Yes we would like to progress these drafts as a WG items. > > Cheers, > Manav > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > > > ___________________________________________________________ > Try the all-new Yahoo! Mail. "The New Version is radically easier to use"= =96 The Wall Street Journal > http://uk.docs.yahoo.com/nowyoucan.html > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From debian-devel-admin@debian.or.jp Sat Nov 18 06:45:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlOdX-0008VL-Bx for ospf-archive@lists.ietf.org; Sat, 18 Nov 2006 06:45:31 -0500 Received: from osdn.debian.or.jp ([61.215.208.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlOdW-0004LR-00 for ospf-archive@lists.ietf.org; Sat, 18 Nov 2006 06:45:31 -0500 Received: from lists.debian.or.jp (osdn.debian.or.jp [61.215.208.41]) by osdn.debian.or.jp (Postfix) with ESMTP id 53CEEC3410 for ; Sat, 18 Nov 2006 20:45:15 +0900 (JST) Date: Sat, 18 Nov 2006 20:45:15 +0900 From: debian-devel-admin@debian.or.jp Reply-To: debian-devel-ctl@debian.or.jp Subject: Subscribe request result (debian-devel ML) To: ospf-archive@lists.ietf.org Message-Id: <200611182045.FMLAAA21177.debian-devel@debian.or.jp> References: <20061118114509.732FAAFDB6@hp.debian.or.jp> X-MLServer: fml [fml 4.0.3 release (20011202/4.0.3)] X-ML-Info: If you have a question, please contact debian-devel-admin@debian.or.jp; Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp List-Subscribe: X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Hi, I am the fml ML manager for the ML . --debian-devel@debian.or.jp, Be Seeing You! ************************************************************ If you have any questions or problems, please contact debian-devel-admin@debian.or.jp ************************************************************ From emccabesss@fleshco.com Sat Nov 18 07:43:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlPXO-0005ew-9W for ospf-archive@lists.ietf.org; Sat, 18 Nov 2006 07:43:14 -0500 Received: from m2373p007.adsl.highway.telekom.at ([80.123.40.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlPXM-00023a-7x for ospf-archive@lists.ietf.org; Sat, 18 Nov 2006 07:43:14 -0500 Message-ID: <000b01c70b0f$1c8483d0$c27ba8c0@M2373P007.adsl.highway.telekom.at> Reply-To: "jegger" From: "jegger" To: "lowther" Subject: cant believe it Date: Sat, 18 Nov 2006 13:43:13 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C70B0F.1C8483D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-Spam-Score: 2.3 (++) X-Scan-Signature: e367d58950869b6582535ddf5a673488 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C70B0F.1C8483D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C70B0F.1C8483D0" ------=_NextPart_001_0008_01C70B0F.1C8483D0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable same melancholy posture.to address lovespeeches to her and just at that = moment Lysander,poor friend. to Perdita, he said to her, O hear me, Perdita, before this = ancientuncertain fortune of a duel.the fashion of these times. We will go = along together, and before your his newlyconceived penitence was to send a messenger to his brother it is hardly possible to be believed, but so it was, that = Protheussuspicious people these Christians are! Their own hard dealings = teachhim to make a merry jest when she saw her Bassanio again, that = madeBellarius again, there is an angel in the cave, or if not, an earthly she did, for the hundred knights were all men of choice behaviourdaughter = to see the struggles between the joy of this poor old kingthou hast = served, tell thee, that Macduff was never born of woman, daughter. daughter.denied he had made any such promise, and then Diana produced the = ringAntipholis of Syracuse went to the inn, and found Dromio with = theAntipholis knew the goldsmith never gave him the chain, and, so like said Isabel, as she went towards the dreary prison where her brotherbut = the forlorn and unprotected state of Viola, who was young and ofThough = Sebastian was as much surprised at the courtesy of this lady as the representations of this faithful steward. Money must be had and and too courtly saints have hands, which pilgrims may touch, but kissthis = one, one poor loving child to rejoice and solace in, cruel deathdelivered = it with a broken voice and real tears. This put Hamlet upongo about = giving flowers away to the ladies of the court, and saying darling as precious as your eye. Is it possible said the frightedPericles = had not been many months married to Thaisa, before heSailing from Tharsus = to Tyre, the ship in its course passed by draught of goat's milk down his prodigious throat, and lay down and unchanged, and as the had directed him, boldly charged the witchtwo = brave brothers, Castor and Pollux, who obtained this grace fromuseless to = describe over again what has been so well told alreadythe cisterns of the = river at which the whole company, in merry his heart overflowing with admiration and grateful recollections ofdess = told him but of the particulars of his son's adventures, ofwas thin of = hair and bald, as an old man's. And Eurymachus, a suitor, him, and they reviled and spurned at him with their feet. Only there to our house I pointed to the churchyard, and said, that was the waysight = I saw that day for while I was telling mamma about the cows, I foible, said miss Withers, and was going to proceed, when littlefrom the = music gallery, of Oh, it's all true! it's all true! Thisbe better friends. author of it did not mean to give the fabulous stories here related as and then I knew what a pretty sight it was to see a number of happymyself = with having discovered this fault in her, for I thought mycontinued to do = so, till, by a still further change for the better in ------=_NextPart_001_0008_01C70B0F.1C8483D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

3D""


same melancholy posture.to address = lovespeeches to her and just at that moment Lysander,poor friend.
to Perdita, he said to her, O hear me, Perdita, before this = ancient  uncertain fortune of a duel.  the fashion of = these times. We will go along together, and before your
his newlyconceived penitence was to send a messenger to his = brother         

it is hardly possible to be believed, but so it was, that = Protheussuspicious people these Christians are! Their own hard dealings = teachhim to make a merry jest when she saw her Bassanio again, that = madeBellarius again, there is an angel in the cave, or if not, an = earthly
she did, for the hundred knights were all men of choice = behaviour  daughter to see the struggles between the joy of = this poor old king  thou hast served, tell thee, that Macduff = was never born of woman,
daughter.         

daughter.denied he had made any such promise, and then Diana produced = the ringAntipholis of Syracuse went to the inn, and found Dromio with = theAntipholis knew the goldsmith never gave him the chain, and, so = like
said Isabel, as she went towards the dreary prison where her = brother  but the forlorn and unprotected state of Viola, who = was young and of  Though Sebastian was as much surprised at the = courtesy of this lady as
the representations of this faithful steward. Money must be had = and         

and too courtly saints have hands, which pilgrims may touch, but = kissthis one, one poor loving child to rejoice and solace in, cruel = deathdelivered it with a broken voice and real tears. This put Hamlet = upongo about giving flowers away to the ladies of the court, and = saying
darling as precious as your eye. Is it possible said the = frighted  Pericles had not been many months married to Thaisa, = before he  Sailing from Tharsus to Tyre, the ship in its course = passed by
draught of goat's milk down his prodigious throat, and lay down = and         
unchanged, and as the had directed him, boldly charged the witchtwo = brave brothers, Castor and Pollux, who obtained this grace fromuseless to = describe over again what has been so well told alreadythe cisterns of the = river at which the whole company, in merry
his heart overflowing with admiration and grateful recollections = of  dess told him but of the particulars of his son's = adventures, of  was thin of hair and bald, as an old man's. And = Eurymachus, a suitor,
him, and they reviled and spurned at him with their feet. Only = there          to our house I pointed to the churchyard, and said, that was the waysight = I saw that day for while I was telling mamma about the cows, = I       foible, said miss Withers, and was going to proceed, when little
from = the music gallery, of Oh, it's all true! it's all true! = This     be better friends.   author of it did not mean to give the fabulous stories here related = as    
and then I knew what a pretty sight it was to see a number of happymyself = with having discovered this fault in her, for I thought = my    continued to do so, till, by a still further = change for the better in
------=_NextPart_001_0008_01C70B0F.1C8483D0-- ------=_NextPart_000_0007_01C70B0F.1C8483D0 Content-Type: image/gif; name="KD9pQ2vIXD.gif" Content-Transfer-Encoding: base64 Content-ID: <6i0pksHE1sCXYmuSogaM> R0lGODdhBwIoAcIAAAQCBCSOBNQKLGRenCQSlKSKRAQC5Pz+/CwAAAAABwIoAQAD/ni63P4wykmr vTjrzbv/YCiOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16 v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgSEEhIQLhYYKiImJigSOjweLkYsPlYoNkY4M l5KanpyfkJSZgqang5yYh6uZn42aoq2SDq+ztIe2rKC5oaW7sajCwxm6xpa4j8G3s7LHqqvL0cm4 1MytssTa283d1aqk0tm60NPlpN7KmMvStd/c8NrGiLn0tOG7nvad5cmT6fburUsnIVu8g6Y6obtG aWE7YBAU/no2z5xFZAgzohqX/o8jL3EY3zGceAnkx1GMCmpcKcjjxXwdYcJ0FnJgqWfg3H0jx7Ln HpfrSuoshHLhLaACbypdeo5oP59Qo0qdSrWq1atYs2rdyrWr169gw4odS7as2bNo06pdy3ZEAAVv T8Rta0aACrsO5h6IG6AvA78N+gLeKzivXgmC5xZeMHhv4MGJJxxOzPcvXL+UMS/+e/hx58AfIoP4 TPcJXhSnLTNezRk0a8WPK+iF3Zq1ase2H0zOe3u37cmkcQvXHTo3h+CliTRakFqBgOfMnUt3Dp05 9OfVc9OGy707b++4kQ933X377wu+bwtPv171Z9+iw19uvLk3d8yMIdNPviTg/vTo0+El4H8DMtDc a+pVBp59CCIWwWzedTabeAtS1mCFDJZHnHsNKijfgu0RduFb21HInw/+HdDcaQPa5SJ12FFnIAQe DuehYoDFp6GDNHIIooTisXfheBM29iF5O35443xGEgaZj/ltZuKJPSz3H4HSvVigA9UdmOR6FhL5 ZWY8bujkYhL2+CCSQ7JXI5lsLqnkkN8liGGdVDqxIoAq8sliA1saRh6E4Mlpo3GFnkdniBHiOV5+ cWZI6KCKKkibeT9CSSKieeqJnYDZ9XlljDAa6CV9OSYoJZSMeobjm0ySqN9+rspaH6qTHqqrYZNa 2uh8ZmoX5bCcdsrVlCog/mvssmQoi4KzzEYr7bTUVmvttdhmq+223Hbr7bfghivuuOSWa+656GI1 wLrstuvuu/DGK++89NZr77345qvvvvz26++/AAcsML3RDnCWwWkhvKzCZDFslsN5QhyWxGNRzJ/F XmEMlsZ0cbyVx12BvJbI6qpFcsJ4AMDDyWio3APLB0dAk1ObuAJLilaOAMDOLivAc88VAM2A0D8/ IPQCRfv8s9AWx3drrsAyeULSSu8MwtE+O8Dz0Fsb3fUBS2MN88MyD+XKLxe9YtAHQLvctgVLI201 0kM3MLfddYMtAcW9xsapedBO8LbedHcQd9V4J5614oRj3cDYZWFMDk4G/k1+DQlu5y044VpH8DbW gzuugMTBEYrpry1kXvgGKjs+OONHh04B5A2rFBNEl1suUgmqL765654XDnrehzNA+pojmhk4B71z rkHrELRN9eurN0714wXbjs1M2DASEE863029BHczjrjvw1ev/vFq6voeZ02K8PX4GZSvufPNx36/ +qNnb7vuL0EHT9YWgvxd4Gv8E17YtHa99QWLUot6FIgw5zvnsc5++NNc8biGwATSrmITMEoshAIN cfDDBAaEWwUtuD8Wdu6FC2Cf8sL0vgfyroKiU6EFqZe+4MHQeP4riCiMkrZu0ERnxGuhD4l2P/3x r2fj4xuD0lTDXckv/okJxEDzMvjEFkJRiR8UC8eWQ5Qj6uMhOSPgBcvXQM9dr3ht5CLY7NfGpkkJ P6Ah0x3jdzUExvGAb5yeH+koN6J1MIZBrEMOZRDGMCxyBo3cWMpWlodHMjKRIEQZsyLJEk76xJMh i5kmFyZKtICSK6dESCo1ssqstBIerzxILK0yS23Ukhu3nMrAdsnLXvryl8AMpjCH+UtMitFkxpwY MjdZymZ2KpfCgCYxpAkVaprCmqjAZiedGblkSnKUxtLmEiz5AnGO0wfmzAjFzEjGWqSkhGpD4SAx SD4Gim+DMFzg7CJCs1H4ohcAZUEg6Vk/ux1Onwa95x8fkE5VRkQn/rwYyVFqRtErCk+JXuua7IL2 xQxIDIDVIGM8BYrFFdYvjlv8YUot0FBZlu12D9leCamhRrbhMGg7LGk9O4qBj9ZkGvh4CUnl+DwX om9zF91AS+NhMd3FNKQToakKUvg72FWNoL3DZwR8ClGIBNUaL6BqUUUHRZQSb6EM9eZOCALRIdpE HfLkqVEZaE/gKc6uE1gnzY4I174+BQXzwyjc8PrDmxZ2b2oFK07OEdWTpECsghOfEmOH0CxiL4TM EKAA/zpVwxoOg2TNKD3JeYClwvJ/9XCKS9zqj8tZlH5L9KxgjWrJMWY2GppN0QogW1SiHtZ8Jt1q YiM6s5qYhLMe/thocKO3OOVyzom+hQBXZUpdVphxajolLXN9+zrowla6w4WFO/7Rz/J2VX7zJOcG B0o/6RHUAXq1kn+KizbApje5bxStBul4SMQy8w7aZYFpixDgFgx4GwcWQoFVkGAFo3O4qFwmKckG zmdys3b/7WaFI3bhTE5Yw6YsGDFHTOISm/jEKE4xvyD8MQmHs8PHzDCGQyxjD8M4OQ2uQ47vsONs 3vibH57xjzs25IyxeA0LTkGPfZBkBqu1AFCG8gKiLGUGUNnKV1YAlaus5ShPmcsHAHNk2dhfHybU aNGbn1bTCoFQuRlUb4YzqdzcRzK/94DbLaR7XXdfNge5AQWw/rKWBT3oKRv60IF+QKILHWZALxqp zZ0tByWbZjQntacReLOpsOSnB9A5udnFr5p5KFvDwnbJ14zAoxO9akYjmtCPPrSiYd3b7+KNiczt YeM0QLEtvahPvp7RlaLzJyRGF8+EdS50d+3BJ9P61YB2NatnDYFWN7qgx+6cIf0Y3NChFYiexlKL OE3uGRX7tZLeaZ5f2N5Qw9fZiM7ytZ9d6C1Pu9qynveYq6deXEe625OtgMRSM25gw+jTKvpUgQL1 Wbk2eY7r1qAX3X3ZP2PZy/UmNKzlHWtXR1va2La1Pfl91UOuubbhBhCoAiRsUbm85b9Gt2UHu2yl NVG0Ze0v/qoFYbGOz3vRHb/3x4fuAKBvOeTpTmq7IZ30gSs8QAuHOZ+k7iXDlbrW5lv2InWNyBpr /OtA17jPfa7vsOvb4yq9emyju/RsV3zqWeLSqDotd+vY9NJz1aG/Xdjd3zpu54HoObVlLe+zd7nw HJdy0CnAXprbWdc5Tyg5IXagmKv8U9aRc5c2zbY+M4+9boMjt89XSOF6XQ4PNwHgdZD6E6z+D6+/ QetJEHvZP/j0QC4yW2qvBt6zwfd6AP4ZhJ8G4vNY9xHG/VeMP3wRq/j50I++9KdPfXel6/rYz772 t8/97nv/++APv/jHT/7ym//86E+/+tfPhOq7//3wj7/8/vVlcfa3gflzwL/9XV///fe+//6HBvoX BwMYgCJQgG+AgAb4AQp4fwtYA7OnegCYBRGoEQj1bSYlSBrIZ49nehaGBI3HeBEXgmZWWSAwDyMV CjeTRmuDMyI1CbqVQCI3RxqlUyRnVdnWgL+HAQOUgim4VmbGbMulZ5F3g7ZGaScAUhHFVu+QM94A VRJVT2kXPHu3Um0nhEalg2tAeVXXg/+0EwOEZ26nN8kWcGgmVyUAUg7xUEzIWayFFDh3g7kmhXA0 cXj3d3+GeRhBOYrVhiI4htBjaYJohjl3ZxwgQjOVO9yzO0vYhP4kE384g+9lV1fIW/3zYqYSKmeT iEnB/g6byHhImHcQN4j7019oOHMbgIi4E1LeI1+uRVyNVV84NYakZ3PbBVuiV2Za+H+AUnUV1YdJ AVa/GInpZnJ0FXE02EYVWERFMVHC+A+oxYnItXZDeGlbp3Zm+G6YeAEOQUJ9JRGMeIvFuEJ7R4rA VY2HyFpACITHJRIA9FQ1pWzEyHcUV3NDuIvFx4PS2I1tSEDyiFRVOIin6HAm8IJPeEaLCD6PWA9u yFEdSD4bqFB7tl/b5l8faAGLxY/sOI1XNWlj9niht4F22JFQsYwjgI8CKAYmKRYrGQIo2XyO9IAe yGEyyYsXWZMweZM4WQYvaQY9uZPgtY1ASQY/SZRD/umTE3iUW1CUY8CUwtCSX+CUYSCVSOZ5UuiR emaOJJmMhkgEVBmVVMAi59YBToMq6uEkUUIaOoKWaZkZfMRFkpg0/yg3AomOSfCVXoB/BDeWG9A3 tZEpiYIkJfI3SDdzgWiENwd5dokEeNkFemluBJIdUccmdtIqqNM+Z1kjxUKNeXeYWtlRismVUNCY XMB7ewKZolJsk3mWlXk6E4IYQsIXt0JzclhpyPhcMpiN7ZeUQsCXqZmaeqglLzdBgemagvIgmKKZ xMmZj9RBoLVnJmdWTkCaS9kEDMdy1ymcB1I6bamcaikZd1JFejeOuPlbqEiP08mbvTmckUluvhmY /q3incIimIoiQRQyl2vHdVMocec5BNSpBcJXdWKZeVJHI3tUnJGxR2pZH2w5QSZCgmk2ahqlVd3F X13pleppLlCZlxlaLhvqmB2qlFXwn1lAogtooleAogGooiM6fy76ojAaoygmojRaozZ6oziaozq6 ozzaoz76o0AapEI6pERapEZ6pEiapEq6pEzapE76pFAapdxgSR9qnlKKgZ1Fm6VHl4upkn3EpUx3 jkLaHDOYpX8ohKqzUi3zpbYYpkm3owfCgatThHe1lVlJg4KYVZG2dRKZp1tanq2zbV80N/O0pYFq PYS6NXRqVtBDp8n4p1W6f14yiUdVnvw5kHOa/lGZaos5BJq5yVN6Oop1KqqeKnGUVqpoWql106iV iqr9SaOnaZtbeZgUao351EX/xkKh56eWuqqb6qqXOmm7qj7KFaqo6kRpKpcKJKY6+p7slqmnGKwZ uKnSqqtY2Kqf+qt4V620tUXFiq25iqy5Sq2kOqbDdnO92nejiqmqqq3kOK7gSlvVqqauioZ6+q2A aqtZF6/laK6++Kh3So5YNaEDW4scdLB3JaftWooPyYH2qlAI621k9lxIWHOOKpdsRKT/CgORGlbG NlRSmgYdmzoURLIhe7Iom7Iqu7Is27Iu+7IwG7MyO7M0W7M2e7M4m7M6u7M827M++7NAG7RD/mAA RFu0RNsAR4u0BgABSfsATesAT8u0Rru0Smu0Siu1VCu0dRC1Txu1B+C1Xwu2YZu1VSsBRcsATXu2 C6C2Y+u0Yqu1buC1XUu2YLu0dRu2Tou3EcC1WSu3feu3bwu3bOC3V6u3SKsAcou4ZIu4iru3i1u4 UEu1dru4kyu4dEC4aCu5j/u3h9u4aLu2jwu6Zhu6elu5ohu4lpsGfOu2iSu6a5u5n+u6bju6Usu4 hqu5qSsHU8u2VUu5kEu5fQu5kUu7s/u1npu0qJu7ZpC2pIu8dLu7Zwu90Su9oRu4You8pyu7ytsG c1u81ku6hju8teu44/u3zLu9b7C6sKu9/sLbvuvrufALv5hrvNqbvOgrBvM7v+7Lvu8bvrzLvM8b vPULvvdLBnWLu/sbvgnsv5s7tZFrtbE7vgU8wT1LvRZ8wRicwRq8wRzMuxT8wSAcwiI8wiRcwiZ8 wkTaqVwwsigMkReqRfPIrDKMbR67BfbIwjUZrVbnpm+KwzekBfxlUCFboaBTqAB7sFllNWrakclq Z5YmnYt6UYJKNyFJraNGxeuqr74Kqhn0ORFKekVTZkOJr/MKcErnq5CWplq8xv92rG36q8ZKhu/a XPoTiKwqx5SFxeEar+iaql26gGTsrtdqajjUlaUKmsq4sMzmxujpx7tGq4VohXKMx1njzJlzXHKY LJo46Mg+fH1cPK173MiLTHH89skq3Ktgysg9FKq4Ka5i6pmwbKleDFzeJYes3Mnp0kCmOKcTe2ZJ TKsyCKpWGcoq1bD6VcizjKd3CjzJPMmyTKyH5XCJ+smi+LPN+aa91cJXUabMo83e/M3gHM7iPM7k XM7mfM7onM7qvM7s3M7u/M7wHM/yPM/0XM/2fM/4nM/6vM/83M/+/M8AHdACPdAEXdAGfdAIndAK vdAM3dAO/dAQHdESPdEUXdEWfdEYndEavbMJAAA7 ------=_NextPart_000_0007_01C70B0F.1C8483D0-- From ospf-bounces@ietf.org Sat Nov 18 14:41:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlW1M-0005BR-J4; Sat, 18 Nov 2006 14:38:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlW1K-0005BJ-JS for ospf@ietf.org; Sat, 18 Nov 2006 14:38:34 -0500 Received: from wx-out-0506.google.com ([66.249.82.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlW1J-000370-Ar for ospf@ietf.org; Sat, 18 Nov 2006 14:38:34 -0500 Received: by wx-out-0506.google.com with SMTP id h29so1340232wxd for ; Sat, 18 Nov 2006 11:38:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=adrLgbue+sA6wRugwAxW5jJc3oOBz6dPiwqT+K/vLv+LRcnht9j7XkbTTUOlh7FDlT7yosfmw70xUjTELszWXzuT9bzUfVApc9SiO3qQfWfz/j0Q+6ifq+ie5LTvbdAG4EFJNS0zJge0tKsLI8gtIO8Z6PL7nzn8xVTiMmTGcrw= Received: by 10.90.101.19 with SMTP id y19mr77547agb.1163878712703; Sat, 18 Nov 2006 11:38:32 -0800 (PST) Received: by 10.90.31.9 with HTTP; Sat, 18 Nov 2006 11:38:32 -0800 (PST) Message-ID: Date: Sun, 19 Nov 2006 01:08:32 +0530 From: "sujay gupta" To: Erblichs Subject: Re: [OSPF] Comments / questions on RFC3623 and Update GR part 1 : BMA env In-Reply-To: <455CFFAA.E39D6B25@earthlink.net> MIME-Version: 1.0 References: <45590834.B988E949@earthlink.net> <455CFFAA.E39D6B25@earthlink.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: a50b6fe619b8c4df89c7095cedd22e37 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1176066160==" Errors-To: ospf-bounces@ietf.org --===============1176066160== Content-Type: multipart/alternative; boundary="----=_Part_35341_7506338.1163878712657" ------=_Part_35341_7506338.1163878712657 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mitchell, You have some valid questions. First; In your scenario where the restarting router X is a DR and the env is a must NBMA, no BDR present. A DR-other when sense that there is Topology change has no means of communicating this with the other DR-others. The point here is do we need to communicate this with the other DR-other's? Is it required, if the topology change is communicated with X , should it be not sufficient, because as X will exit GR prematurely, it should flush its previous send grace lsa's , thus communicating with the other DR-other's that there is something wrong, cannot say though particularly a toplogy change has occured. Before we discuss any further, another interesting point you should note, the only way the DR-other (i.e the one which has detected topo-change) communicates is by sending a LSA(network/router) which when examined will tell to X that the DR-other has stopped its support prematurely, in essence it done by doing a 2-way check on the lsa contents. This check works well if the NSM between X and the DR-other is below adjacency full. What if the DR-other finds post adjacency full event that it has to exit GR , there is no way it can communicate this to the restarting router, if you read the update draft however, this catch has been taken care of as the DR-other should send some form of notification to X, using 1-way hello , lls block etc. that it does not support GR now.In brief explicit signalling. Second; your scenario in which X is the DR and an extremely important router and is the only path to a set of routes and end systems within the area. and suppose a topology change causes a route element to be removed , so now the question is if we want a liberal approach in GR, (because we want X to be up and running as it is a critical router) , the topology change detection should not cause any action on the helpers, result will be ofcourse there will be routes black-holed in the system. X will still be forwarding packets to the removed lsa routes. On the other hand if you wish to take action, make sure that the helper exits gr prematurely if it has ANY info about topo-change. In the update this is made more tight , in the sense of using spf to validate if X has any dependency on the router lsa which has changed, out of which you may get broadly two results, the routes are gone or the routes have changed to something better.If the routes are gone you must think of exiting gr, if the routes have changed to better you must still think of exiting gr (as remember the routes on the fwd plane of X is unchanged ) IMO this *may* causing routing loops. True there is additional processing for all the spf checks and dependencies. Third, in your scenario where the ls refresh timer has exceeded 30 mins to say 45 mins the env is NBMA and X our GR router is the DR, there is no way things can work correctly.If we keep things as it is at the LSA max-age the system will exit GR.You could solve this two ways; 1. Do nothing for max-aged lsa's as long as you are in the helping mode, dont treat it as a bad news. 2. As per your suggestion, start with a fresh copy of the lsa everytime when entering gr helper mode.-- but note that grace lsa's are link local so at best you will get new copies from immediate routers but not a step ahead of them, so there lsa's could still Max age out before gr expiry period --- did i miss something here? About the idea of extending the grace period to 1hr+ and then sending DN lsa's for them, Isn't this a too long period for GR? just a thought.. you could however extend your grace period by sending subsequent grace lsa's, if X feels it will be unable to complete gr in the given time period.. Eitherways this issue definitely needs some thinking. And about the minor item, the helper on removing the GR router should run spf and update the routes of its forwarding table (this is specified in 3623) Needless to say the base GR needs a relook, as probably you too must have surmised by now. While at my presentation at Montreal on the same, I saw no clear objections, with what I gather from this minutes of the 67th meeting , there was only one objection.With vendors relying on features like NSF perhaps the awareness for a workable-GR takes a back seat. Best Regards, Sujay On 11/17/06, Erblichs wrote: > > Sujay Gupta, > > Let me give you some insight on part of this thinking. > IMO, GR has added a few holes in our converged routing > assumptions and that your update might be able to close > a couple.. > > There is alot here!!!! > > Summary says to think multiple > times before you exit prematurely based on a topology > change (LSDB) and assume that you need router "X" no matter > what. > > So... > > Why don't you tell me how a LSDB change is > going to be communicated iff the env is > BMA and GR router "X" is the DR and no > BDR exists? > > I consider this a huge hole.. > I don't really see a DR-other communicating > LSAs to other DR-others to allow them to > understand about a topology change. > > > Second, lets assume that router X's is an extremely > important router within our area with the > connection to the internet, etc.. If it weren't we > would / COULD just take it down. > > thus, we have router "X" is a DR, and is the ONLY path > to a set of routes and end-systems within this area.. > > Then lets conservatively look that a topology change is > a removal of a single router LSA that has no effect > after a SPF calculation. > > If router "X" has sucessfully entered its grace > period / GR interval, aren't we ... > > .... black holing the routers, routes, end-systems > that reside on the other end of router "X"? > > .... since router "X" CAN not probe to verify that > a topology change has occured. It is in non-stop > forwarding mode.. It will still forward pkts to > the removed LSA routes until... > > so what... > The pkts that are forwarded by router "X" to > say non-reach Z will cause minimal harm.. They will be > dropped and most likely a ICMP message will > be sent on the reverse path... The ICMP > message might be interpreted by X, but if it > is just forwarded, > > So,,, what we have here is the unability is to allow > router "X" to state that its routes are of a level > of imporantance that most topology changes should > be balanced against a delay in making the change. > > New LSAs or changed LSAs that don't show up as > primary LSAs after the SPF calculation COULD > in theory IMO, also be ignored. The originator > could in theory check out whether the LSA is > needed to be communicated. > > (This says just because a minor toplogy change > has occured do we need to go thru all the > work and possibly isolate router's "X"'s > dependencies). > > > If we feel that the new / changed / or removed LSA > should be communicated ... > router X still isn't going to be in convergence > until it resync it's LSDB > > If the change of LSA results in a better route, is > it worth isolating router's X's entities???... > > > > Third, most large OSPF router vendors support the ability > to set the LSA refresh time on non-DNA LSAs. If we are in > a normal environment that the admin does this to decrease > the number of LSA refreshes versus the drastic steps to > using DNA LSAs. Then assuming having a 45 min LSA refresh > would not be unreasonable. > > Going with this logic we have a few simple steps to > take. > One is that all HELPERS that originate LSAs, > re-originate their LSAs upon first seeing a grace > LSA in addition to router "X" doing the same. > > This allows us to take almost the full hour of the > grace-time. > > If we could communicate a wished grace-time in > excess of 1 hour, we could in theory send out > DNA LSAs which would allow a static environment > to support grace times in excess of 1 hour. > :: Part of this logic follows the damand circuit > support. > > > Part of this is can, should we figure out a way to stop > router "X" in his grace-period/interval from forwarding pkts > based on obsolete OSPF control information.????? > > The other part says, why don't we just run in a degraded mode > if we -realize that router "X" is so important that we would > just isolate ourselves or so many routes/routers that we > REALLY need to keep router "X" alive as long as feasibly > possible. > > Third minor item is I didn't see any suggestion of removing > entitites from HELPERS forwarding table based on removing the > GR router because of a LSDB change. > > Mitchell Erblich > ------------------ > > > Hi Mitchell, > I have some comments inline; > > On 11/14/06, Erblichs < erblichs@earthlink.net> wrote: > > Group, > > First, I have a few questions to the base and the update. > These comments / questions pertain ONLY to BMA envs > but are also relevelent to other envs. > > FYI) IMO, helpers are defined by two major requirements > a) the ability to recieve a grace-LSA before a hello > "new hello" and not restart the adj > b) the ability of a helper "Y" to (re)send a router-LSA, > etc upon > router "X" exiting graceful restart that are in its > retransmit-list. > > > If this "helper" split functionality is supported, then > only > a limited number of routers within a area need to be in > Full-helper mode. > > Within BMA envs a DR-other above helper "b" functionality > is not really necessary for retransmit. We use the DR/BDR > for retransmit support. > > > IFFFFFFF, a GR router is the DR, who is in it grace-period, > and a DR-other stops sending hellos, if their are no > alternate paths thru another router for any forwarding > data. Then what benefit is it to prematurely end helper > mode? Basicly, most algs can determine ahead of time > whether > the exiting router has contributed a primary link/path. If > it isn't then it has no consequence. Yes, data pkts that > have > a intermediate dest will be forwarded 1 or two extra hops, > before they are dropped. > > (Update: 2.0 Action on route calculation) > If a topology change occurs and the GR restarting router > is identified as the next hop. By definition it is in > non-stop > forwarding mode and should be able to forward packets. If > this > is identified as a topology change and the ONLY route is > thru > this GR router, shouldn't packets be forwarded thru it > anyway? > Not doing so blackholes those routes, IMO. > > > > Suj>> Here topology change also includes routes which are no more valid, > if the lsa seeks a route to be removed and that route involves the GR > router > the helper exits, thus black-holing and circumventing the GR router as > router > under plain restart.Note here that previously(rfc3623) the helper was > exiting > for all reasons, which has been curbed now so as you have pointed out if > the > lsa effects the route which is ONLY through the restarting router will > the system > exit, which makes sense. > > Yes, and no.. Router X, once he has entered GR, is not in the mode > to accept topology changes.. He will forwarded no-matter what > based > on his old information. Thus, any routing inconsistencies done by > him until his GR time period ends CAN result in him routing pkts > improperly. This is basic IP forwarding. > > The originator of the change will be the one who can make the > correct IP forwarding decisions with reciving or forwarding > IP pkts based on the LSA change. However, because router X is no > longer in sync, should he inform others not to send or allow > reciept > of data pkts from router X? > > At the end of the grace-period or when router X re-enables > his OSPF control code, he can be resync'ed. Until then, yes > we SHOULD have some level of AI that determines the benefit > of keeping router X in GR. > > > Second, most environments have most of the > LSA changes not result in any primary path alterations.. > > Thus, > 1) Helpers should be able to be able to support a, without > b > If this is the case, router "X", if it is a DR should > allow > all the DR-others to support a, while only the BDR need > be > a "Full-Helper". > > > > Suj>> I like your analysis in breaking up the helper job into partial > and full. > IMO "Helper" is a behaviour of a router w.r.t to the GR operation, > where as > the idea whether the helper is "Full-helper" else a "Partial" depends > upon the result > of election. In brief a "Helper" is always expected to perform > "Full-helper" features as per your describe , if it does less; guess it > is > plain lucky ! ,( also note Helper support maybe a feature switched on / > off by admin, not a partial/full helper). > > > > 2) If router "X" is a DR-other only one of a "DR or BDR" > need to be a Full-helper. All LSAs can be placed on the > retransmit list of the for router "X" by the DR or BDR. > > 3) Topology change. A LSA aging out of the LSDB, will not > necessarily remove a element in the forwarding table? > If this can be detected, should it still force the exit > of a helper wrt graceful restart? > > > Suj>> as per the base ospf operation a max aged lsa on the lsa, should > trigger > it to flood the lsa (-->" which in turn should instigate the originator > of the lsa to resend a fresh copy, if fails ends in removal of the > corresponding route everywhere! "), > thus if the case happens as you have described a GR with "strict lsa > checking > enabled" i.e catch all topology changes should force the helper to exit > as it has to > flood this lsa to the GR router, here the update draft would tell you > prohibit your > exit only if the lsa somehows affects a route through the GR router, > else let peace > prevail, no need to exit. > > > 4) If router "X" is a DR and has entered graceful restart > with no BDR present, should the DR-other routers allow > the > LSAs to become not refreshed and aged out because the > grace period has not expired. > How can "one" or more "HELPERS" force a new DR election? > > > Suj>> IMO the DR-other allows normal aging to continue, if the lsa age's > out > before grace period expiry, the helpers would exit GR(see above) , again > applying the same logic. > > A new election would disturb all previous adjacencies, do we need it? > > > > 5) Even with a 30 min max for the grace period, some > routers > may only retransmit once every 45 mins or so. How can we > guarantee that those retransmited-LSAs are not aged-out > if > router "X" is the DR and is down for a longer time? > > Shouldn't recieving the first grace-LSAs from a > restarting > router initiate a re-send of the LSAs? > > > Suj>> With the LSRefreshtime is 30 min , the MaxAge double(60min), the > max grace period is same as LSRefreshtime 30 min, I > dont see how we reach a stage where > the problem will come, you might want to consider some border cases i > guess there the previous arguments(see above) hold good. > > > > Mitchell Erblich > > > > Best Regards, > Sujay > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > ------=_Part_35341_7506338.1163878712657 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mitchell,
You have some valid questions.
First;
In your scenario where the restarting router X is a DR
and the env is a must NBMA, no BDR present.
A DR-other when sense that there is Topology change has no means of communicating this with the other DR-others.
The point here is do we need to communicate this with the other DR-other's? Is it required, if the topology change is communicated with X , should it be not sufficient, because
as X will exit GR prematurely, it should flush its previous send grace lsa's , thus communicating with the other DR-other's that there is something wrong, cannot say though
particularly a toplogy change has occured.
Before we discuss any further, another interesting point you should note, the only way the DR-other (i.e the one which has detected topo-change) communicates is by sending a LSA(network/router) which when examined will tell to X that
 the DR-other has stopped its support prematurely, in essence it done by doing a 2-way check on the lsa contents. This check works well if the NSM between X and the DR-other is below adjacency full. What if the DR-other finds post adjacency full event that it has to exit GR , there is no way it can communicate this to the restarting router, if you read the update draft however, this catch has been taken care of as the DR-other should send some form of notification to X, using 1-way hello , lls block etc. that it does not support GR now.In brief explicit signalling.

Second; your scenario in which X is the DR and an extremely important router and is the only path to a set
of routes and end systems within the area.
and suppose a topology change causes a route element to be removed , so now the question is if we want a liberal approach in GR, (because we want X to be up and running as it is a critical router) , the topology change detection should not cause any action on the helpers, result will be ofcourse there will be routes black-holed in the system.
X will still be forwarding packets to the removed lsa routes.
On the other hand if you wish to take action, make sure that the helper exits gr prematurely if it has ANY info about topo-change. In the update this is made more tight , in the sense of using spf to validate if X has any dependency on the router lsa which has changed, out of which you may get broadly two results, the routes are gone or the routes have changed to something better.If the routes are gone you must think of exiting gr, if the routes have changed to better you must still think of exiting gr (as remember the routes on the fwd plane of X is unchanged ) IMO this *may* causing routing loops. True there is additional processing for all the spf checks and dependencies.

Third, in your scenario where the ls refresh timer has exceeded 30 mins to say 45 mins the env is NBMA and X our GR router is the DR, there is no way things can work correctly.If we keep things as it is at the LSA max-age the system will exit GR.You could solve this two ways;
1. Do nothing for max-aged lsa's as long as you are in the helping mode, dont treat it as a bad news.
2. As per your suggestion, start with a fresh copy of the lsa everytime when entering gr helper mode.-- but note that grace lsa's are link local so at best you will get new copies from immediate routers but not a step ahead of them, so there lsa's could still Max age out before gr expiry period
--- did i miss something here?

About the idea of extending the grace period to 1hr+ and then sending DN lsa's for them, Isn't this a too long period for GR? just a thought..
you could however extend your grace period by sending subsequent grace lsa's, if X feels it will be unable to complete gr in the given time period..

Eitherways this issue definitely needs some thinking.

And about the minor item, the helper on removing the GR router should run spf and update the routes of its forwarding table (this is specified in 3623)

Needless to say the base GR needs a relook, as probably you too must have surmised by now.

While at my presentation at Montreal on the same, I saw no clear objections, with what I gather from this minutes of the 67th meeting , there was only one objection.With vendors relying on features like NSF perhaps the awareness for a workable-GR takes a back seat.

Best Regards,
Sujay


On 11/17/06, Erblichs <erblichs@earthlink.net> wrote:
Sujay Gupta,

        Let me give you some insight on part of this thinking.
        IMO, GR has added a few holes in our converged routing
        assumptions and that your update might be able to close
        a couple..

        There is alot here!!!!

        Summary says to think multiple
        times before you exit prematurely based on a topology
        change (LSDB) and assume that you need router "X" no matter
        what.

        So...

                Why don't you tell me how a LSDB change is
                going to be communicated iff the env is
                BMA and GR router "X" is the DR and no
                BDR exists?

                I consider this a huge hole..
                I don't really see a DR-other communicating
                  LSAs to other DR-others to allow them to
                  understand about a topology change.


        Second, lets assume that router X's is an extremely
        important router within our area with the
        connection to the internet, etc..  If it weren't we
        would / COULD just take it down.

        thus, we have router "X" is a DR, and is the ONLY path
        to a set of routes and end-systems within this area..

        Then lets conservatively look that a topology change is
        a removal of a single router LSA that has no effect
        after a SPF calculation.

        If router "X" has sucessfully entered its grace
        period / GR interval, aren't we ...

           .... black holing the routers, routes, end-systems
           that reside on the other end of router "X"?

           .... since router "X" CAN not probe to verify that
          a topology change has occured. It is in non-stop
          forwarding mode.. It will still forward pkts to
          the removed LSA routes until...

        so what...
          The pkts that are forwarded by router "X" to
          say non-reach Z will cause minimal harm.. They will be
          dropped and most likely a ICMP message will
          be sent on the reverse path... The ICMP
          message might be interpreted by X, but if it
          is just forwarded,

          So,,, what we have here is the unability is to allow
          router "X" to state that its routes are of a level
          of imporantance that most topology changes should
          be balanced against a delay in making the change.

                New LSAs or changed LSAs that don't show up as
                primary LSAs after the SPF calculation COULD
                in theory IMO, also be ignored. The originator
                could in theory check out whether the LSA is
                needed to be communicated.

               (This says just because a minor toplogy change
                has occured do we need to go thru all the
                work and possibly isolate router's "X"'s
                dependencies).


          If we feel that the new / changed / or removed LSA
         should be communicated ...
           router X still isn't going to be in convergence
           until it resync it's LSDB

           If the change of LSA results in a better route, is
           it worth isolating router's X's entities???...



      Third, most large OSPF router vendors support the ability
      to set the LSA refresh time on non-DNA LSAs. If we are in
      a normal environment that the admin does this to decrease
      the number of LSA refreshes versus the drastic steps to
      using DNA LSAs. Then assuming having a 45 min LSA refresh
      would not be unreasonable.

        Going with this logic we have a few simple steps to
        take.
                One is that all HELPERS that originate LSAs,
                re-originate their LSAs upon first seeing a grace
                LSA in addition to router "X" doing the same.

                This allows us to take almost the full hour of the
                grace-time.

                If we could communicate a wished grace-time in
                excess of 1 hour, we could in theory send out
                DNA LSAs which would allow a static environment
                to support grace times in excess of 1 hour.
                :: Part of this logic follows the damand circuit
                   support.


        Part of this is can, should we figure out a way to stop
        router "X" in his grace-period/interval from forwarding pkts
        based on obsolete OSPF control information.?????

        The other part says, why don't we just run in a degraded mode
        if we -realize that router "X" is so important that we would
        just isolate ourselves or so many routes/routers that we
        REALLY need to keep router "X" alive as long as feasibly
        possible.

        Third minor item is I didn't see any suggestion of removing
        entitites from HELPERS forwarding table based on removing the
        GR router because of a LSDB change.

        Mitchell Erblich
        ------------------


Hi Mitchell,
I have some comments inline;

On 11/14/06, Erblichs < erblichs@earthlink.net> wrote:

     Group,

             First, I have a few questions to the base and the update.
             These comments / questions pertain ONLY to BMA envs
             but are also relevelent to other envs.

             FYI) IMO, helpers are defined by two major requirements
                a) the ability to recieve a grace-LSA before a hello
                   "new hello" and not restart the adj
                b) the ability of a helper "Y" to (re)send a router-LSA,
etc upon
                   router "X" exiting graceful restart that are in its
                   retransmit-list.


             If this "helper" split functionality is supported, then
only
             a limited number of routers within a area need to be in
             Full-helper mode.

             Within BMA envs a DR-other above helper "b" functionality
             is not really necessary for retransmit. We use the DR/BDR
             for retransmit support.


             IFFFFFFF, a GR router is the DR, who is in it grace-period,
             and a DR-other stops sending hellos, if their are no
             alternate paths thru another router for any forwarding
             data. Then what benefit is it to prematurely end helper
             mode? Basicly, most algs can determine ahead of time
whether
             the exiting router has contributed a primary link/path. If
             it isn't then it has no consequence. Yes, data pkts that
have
             a intermediate dest will be forwarded 1 or two extra hops,
             before they are dropped.

             (Update: 2.0 Action on route calculation)
             If a topology change occurs and the GR restarting router
             is identified as the next hop. By definition it is in
non-stop
             forwarding mode and should be able to forward packets. If
this
             is identified as a topology change and the ONLY route is
thru
             this GR router, shouldn't packets be forwarded thru it
anyway?
             Not doing so blackholes those routes, IMO.



Suj>> Here topology change also includes routes which are no more valid,
if the lsa seeks a route to be removed and that route involves the GR
router
the helper exits, thus black-holing and circumventing the GR router as
router
under plain restart.Note here that previously(rfc3623) the helper was
exiting
for all reasons, which has been curbed now so as you have pointed out if
the
lsa effects the route which is ONLY through the restarting router will
the system
exit, which makes sense.

        Yes, and no.. Router X, once he has entered GR, is not in the mode
        to accept topology changes.. He will forwarded no-matter what based
        on his old information. Thus, any routing inconsistencies done by
        him until his GR time period ends CAN result in him routing pkts
        improperly. This is basic IP forwarding.

        The originator of the change will be the one who can make the
        correct IP forwarding decisions with reciving or forwarding
        IP pkts based on the LSA change. However, because router X is no
        longer in sync, should he inform others not to send or allow reciept
        of data pkts from router X?

        At the end of the grace-period or when router X re-enables
        his OSPF control code, he can be resync'ed. Until then, yes
        we SHOULD have some level of AI that determines the benefit
        of keeping router X in GR.


        Second, most environments have most of the
        LSA changes not result in any primary path alterations..

             Thus,
             1) Helpers should be able to be able to support a, without
b
                If this is the case, router "X", if it is a DR should
allow
                all the DR-others to support a, while only the BDR need
be
                a "Full-Helper".



Suj>> I like your analysis in breaking up the helper job into partial
and full.
IMO  "Helper" is a behaviour of a router w.r.t to the GR operation,
where as
the idea whether the helper is "Full-helper" else a "Partial" depends
upon the result
of election. In brief a "Helper" is  always expected to perform
"Full-helper" features as per your describe , if it does less; guess it
is
plain lucky ! ,( also note Helper support maybe a feature switched on /
off by admin, not a partial/full helper).



             2) If router "X" is a DR-other only one of a "DR or BDR"
                need to be a Full-helper. All LSAs can be placed on the
                retransmit list of the for router "X" by the DR or BDR.

             3) Topology change. A LSA aging out of the LSDB, will not
                necessarily remove a element in the forwarding table?
                If this can be detected, should it still force the exit
                of a helper wrt graceful restart?


Suj>> as per the base ospf operation a max aged lsa on the lsa, should
trigger
it to flood the lsa (-->" which in turn should instigate the originator
of the lsa to resend a fresh copy, if fails ends in removal of the
corresponding route everywhere! "),
thus if the case happens as you have described a GR with "strict lsa
checking
enabled" i.e catch all topology changes should force the helper to exit
as it has to
flood this lsa to the GR router, here the update draft would tell you
prohibit your
exit only if the lsa somehows affects a route through the GR router,
else let peace
prevail, no need to exit.


             4) If router "X" is a DR and has entered graceful restart
                with no BDR present, should the DR-other routers allow
the
                LSAs to become not refreshed and aged out because the
                grace period has not expired.
                How can "one" or more "HELPERS" force a new DR election?


Suj>> IMO the DR-other allows normal aging to continue, if the lsa age's
out
before grace period expiry, the helpers would exit GR(see above) , again
applying the same logic.

A new election would disturb all previous adjacencies, do we need it?



             5) Even with a 30 min max for the grace period, some
routers
                may only retransmit once every 45 mins or so. How can we
                guarantee that those retransmited-LSAs are not aged-out
if
                router "X" is the DR and is down for a longer time?

                 Shouldn't recieving the first grace-LSAs from a
restarting
                 router initiate a re-send of the LSAs?


Suj>>  With the LSRefreshtime is 30 min , the MaxAge double(60min), the
max grace period is same as LSRefreshtime 30 min, I
dont see how we reach a stage where
the problem will come, you might want to consider some border cases i
guess there the previous arguments(see above) hold good.



             Mitchell Erblich



Best Regards,
Sujay

     _______________________________________________
     OSPF mailing list
     OSPF@ietf.org
     https://www1.ietf.org/mailman/listinfo/ospf

------=_Part_35341_7506338.1163878712657-- --===============1176066160== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1176066160==-- From bilateyng@greenlivingoasis.com Mon Nov 20 02:56:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm40W-0007sM-Jh for ospf-archive@lists.ietf.org; Mon, 20 Nov 2006 02:56:00 -0500 Received: from [121.12.4.47] (helo=pc2) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm40K-0005zM-LZ for ospf-archive@lists.ietf.org; Mon, 20 Nov 2006 02:56:00 -0500 Message-ID: <000b01c70c79$46cc2ab0$3801a8c0@pc2> Reply-To: "jody" From: "jody" To: "ayman" Subject: morning Date: Mon, 20 Nov 2006 15:55:42 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C70C79.46CC2AB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Score: 0.7 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C70C79.46CC2AB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C70C79.46CC2AB0" ------=_NextPart_001_0008_01C70C79.46CC2AB0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable precious souls within her.past, since they so happily have ended. And = then Prospero embracedand when he saw her so dishonoured, and found she = was taken from him governor introduced them to his daughter and his niece as their oldwords = he uttered, said meekly, Is my lord well, that he does speaka more = valuable present. letter. Julia, angry that her maid should thus take the liberty of Protheus.you to come, let not my letter. O my dear love, said = Portia,though he was forbidden upon pain of death to return to = Britain,bluebell, like thy clear veins and the leaf of eglantine, which is her with, and that her eyes were not fierce like Gonerill's, but mildnear = Dover, in a pitiable condition, stark mad and singing aloudwhich was = forming against him under Malcolm, the eldest son of the be her husband, and to love her for ever which she hoped would be be her husband, and to love her for ever which she hoped would bea meek = and manageable wife. And truly none was so fit to set aboutmaking after = his youngest son, that son and his eldest son also werelaw through the = lenity of the duke being utterly disregarded, the holy disguised duke come in the wish deserves a welcome. My businessa long = discourse to her of my dear faith. It will well become you togood fortune = that he had met with. In the mean time Orsino came to the presenters and the givers of course were rewarded with some rich had for not many days after, a poor soldier, passing by theAnd there, in = the presence of the old lords Mountague and Capulet, hewhen jangled out = of tune, or rudely handled, produce only a harsh andking to know, = Polonius, the old counsellor of state, was ordered to have wronged her lord with doing so naughty a thing, as giving histhought = dead, remained at Ephesus. Her little babe Marina, whom thishurrying me = from my friends. How now, Marina, said the dissembling to Ithaca but as they doubled the Cape of Malea, suddenly a north where Pyriphlegethon and Cocytus and Acheron mingle their waves.sweet = singing. Whosoever shall but hear the call of any Siren, he willthe = wonder of whirlpools. Which when Scylla saw, from out her blackyour young = neck in the yoke of marriage. I never saw that man that was had departed, he did not at first know his country again, either = thatShame on their unworthiness, there is no day in which two or = threeboard, scarce should he get salt from your hands, if he brought his guestrites. And he described the very garments which Ulysses had on, attentions to my instructions, have rendered a life of labourvery = cross. He untied his parcel, and said, Betsy, I have brought your mother and I must consult together on the subject. The resultthe = deceit unable to invent any new incident, I left the conclusionMy father = was astonished and he said, Is this the sullen Elinor lady let me stand as long as I pleased at the booths, and gave me telling me what every thing was. She made me observe how the = commonscarcely possible to explain to any one who has not lived in the = fens,up to the highest pitch of delight at having visibly presented to me ------=_NextPart_001_0008_01C70C79.46CC2AB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

3D""


precious souls within her.past, = since they so happily have ended. And then Prospero embracedand when he = saw her so dishonoured, and found she was taken from him
governor introduced them to his daughter and his niece as their = old  words he uttered, said meekly, Is my lord well, that he = does speak  a more valuable present.
letter. Julia, angry that her maid should thus take the liberty = of         

Protheus.you to come, let not my letter. O my dear love, said = Portia,though he was forbidden upon pain of death to return to = Britain,bluebell, like thy clear veins and the leaf of eglantine, which = is
her with, and that her eyes were not fierce like Gonerill's, but = mild  near Dover, in a pitiable condition, stark mad and = singing aloud  which was forming against him under Malcolm, the = eldest son of the
be her husband, and to love her for ever which she hoped would = be         

be her husband, and to love her for ever which she hoped would bea = meek and manageable wife. And truly none was so fit to set aboutmaking = after his youngest son, that son and his eldest son also werelaw through = the lenity of the duke being utterly disregarded, the holy
disguised duke come in the wish deserves a welcome. My = business  a long discourse to her of my dear faith. It will = well become you to  good fortune that he had met with. In the = mean time Orsino came to
the presenters and the givers of course were rewarded with some = rich         

had for not many days after, a poor soldier, passing by theAnd there, = in the presence of the old lords Mountague and Capulet, hewhen jangled = out of tune, or rudely handled, produce only a harsh andking to know, = Polonius, the old counsellor of state, was ordered to
have wronged her lord with doing so naughty a thing, as giving = his  thought dead, remained at Ephesus. Her little babe Marina, = whom this  hurrying me from my friends. How now, Marina, said = the dissembling
to Ithaca but as they doubled the Cape of Malea, suddenly a = north         
where Pyriphlegethon and Cocytus and Acheron mingle their waves.sweet = singing. Whosoever shall but hear the call of any Siren, he willthe = wonder of whirlpools. Which when Scylla saw, from out her blackyour young = neck in the yoke of marriage. I never saw that man that was
had departed, he did not at first know his country again, either = that  Shame on their unworthiness, there is no day in which two = or three  board, scarce should he get salt from your hands, if = he brought his
guestrites. And he described the very garments which Ulysses had = on,          attentions to my instructions, have rendered a life of labourvery = cross. He untied his parcel, and said, Betsy, I have = brought       your mother and I must consult together on the subject. The result
the = deceit unable to invent any new incident, I left the = conclusion     My father was astonished and he = said, Is this the sullen Elinor   lady let me stand as long as I pleased at the booths, and gave = me    
telling me what every thing was. She made me observe how the = commonscarcely possible to explain to any one who has not lived in the = fens,    up to the highest pitch of delight at having = visibly presented to me
------=_NextPart_001_0008_01C70C79.46CC2AB0-- ------=_NextPart_000_0007_01C70C79.46CC2AB0 Content-Type: image/gif; name="XdpfH65kOV.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhFQIcAcIAAAQCBCSOBNQKLGRenCQSlKSKRAQC5Pz+/CwAAAAAFQIcAQAD/ni63P4wykmr vTjrzbv/YCiOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16 v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqM BJ2dC56fCqGioqMEp6gHpKqkD66jDaqnDLCrs7e1uKmtspu/ebi9oLEOprnFq6+1xszKzrTE0sfU u8LJu8DacdfPxdnKvbPjy9LQz9bT5ujs5N7g79vyct31y+Lm4N3nw/nYzqjwfVvnC968g2fqhQIF K2Asd7cWRjy2rhWrZOgkhnuI/rFfOYQg1djyqC8axJLeZGlMl3KYwoHqIhgMSfMLynjNkJ38ePNc Rok7dfIqJWFmzaNaenokiDNlxZy+mGVzGFNqzn1OkWrd0jNcw6ulvvrsStWq2bP5PEXdyrat27dw 48qdS7eu3bt48+rdy7ev37+AAwseTLgwkwAKEJ9QbDiMABWPHTA+oDiAZQaXG1jOTHmz5MkSNjP2 vIAzZc2cRU8ALboy5sSXW8cmjRk0atuaP6gGgbuxksgogL8uTbx27uKjUVeYnNx48eGnnz9gLRk6 9eese0ffPl23dA7aff+geEC4AgHoF0Rerz59+8fo3Utvnri+/er3o4fnftw+/n3sF1wH3XYCEjgc btftph9sptFmXX2xlZZag+IZodF5DQDHXnkYctiheeYhN6Br+T0oYmgRMHefbcztV2JrJ75oon/d HXgiiQuWaGBnMSJGn4sV5nChh+oVySF8HsbnnnxEHqdijxJW5mCOKVYJZX8SroZljPy1aBqVA1JJ Io5STtlZajbWRhuQQeJAHohGIolkkwwsCQGOBMLYJY1RmhmmdXqyeCeKf4JZIJ6y4XflmFwqOp+M jraJBJwdEqmhkXGmKOCT3JH5qI6dAtjojitG2tuXh4oK6o83lkrqd6Ea+J+kSyi5HpOXvqdre9N5 mZ+X/yEKK4OjZfYkjGs6/siianrCpuaIaYJ6pomMrviljpwmyymt87CpgrfchnsYDuCKa+656Kar 7rrstuvuu/DGK++89NZr77345qvvvvzGMMC/AAcs8MAEF2zwwQgnrPDCDDfs8MMQRyzxxBRXbDHC kg7QlsZvcRykx1qBzJbIvpFck8lIoVyYyiCxTJPLgsE8j8wI0fyXzdrgLI/OfPFsBgA8+PyzD0Ln pfJUEelijFpDqYQCAFADvUDUUltQdQNXH0D1A1lPHbXXWzOgsoLKbstgnyeErYDaHXS9tgNfg+22 1nHTzfYCReN19FVO89OR0iZcLbXgVqtdt9YMZA0114m/HQHK2So3bLAl/hCO+NQeUF314Zc3jjnW ns8tdsZFQWMPRn7DlMLgnk8A9NyiE+625aIfYLJ2x04+7NOO967B6xBYDvrnrV9euwJ538XyPqdn 9bfqvHcufQTAMx7857OHfrftNXYvZvflZu778RJUD3fihhc//trbI0+6TKY/9U5YTLeU9uLrV4D/ +Vjvv7n1viOe+yI1IzDNx08hqJvwNrC/4eVvgflz4Oja5DKSyI8lFmQKCVgnQNc1MIDa0xzc2pe1 21kpVgga1OoiyAHOSU94IhyhC6c3wI9NIIMTIQpA0jKkyrHQdQGMHf/KB8AaFspau0mh9wL3w98F sXjZI+IQJ2jDG2KQ/m9V2chaEhg69UlRcVCcYtf+10HIUas6SozVCGjnxQxwUIAQfOEQ48g9ClKg GmXhIUSi4RMQsK19XPuj4WYIww9ub2za4s9pEqWt8OnvcIAsHCQH2UDObc6QM6xjFe1APhgkTwyd 9Nf7OBm0PITSk6MMGVw+WRdWUsKVloClXGQZCVpOwpYd29gqU5myXdpxZL7cpCpzScGLGfOYyEym MpfJzGY6M5m8PAouaxnNkwWzQtNsRDYfsc2tdFMR32REOKWpS2IKs5fmxGY53TJOa97hlC1opxTg 6QJ5hgRlSONjVpiGQWEYhYEACCj6BHqBMQb0kgetHUIPWgF81o8X/oDTJ3mexlC5+bF/CWVfRmW4 UII2tJr7ZEgfm/INf/oQe20MZEXZ+MgOfhQqJB2HSUXKApaCEAMJjeLxbJoBe7YMfv4gaVDVIZDo 0fF8YEQpBcxHT02ONJ9UKctSatrEgtKQeDvt4gZ8WjOg/kOoXyUqR1Yox6VOj3Yb5V9HLWCyrrRj rOyAwRuvajW6di6nRRxcWl96ztQ1L347LOoGPXrUEXL0eg6EHV9VYgqovtV+NSVsSguH2CJW9ZRc PcjywhrXtVxRKGQtrAzhaFm77fWmDoDZVF3ikpGGdrKSnKIE5RbFxYpns/MDCk+iYhHUnVS0w5tr bUuL2gao1res/i1pD1Ug3A80l3pAlK0EMjszKzIlj/ID6z/dqNXiqvWBrRsjaSnQVsByFq4aXGN3 7VrXso6XhmT0rnFBStOQXuSh+IWpCPZ6Wurxt6IajaPgADwBh1LkQkjL5+oI3F+c8lelhVQcgclL 3zc0VQXUZcKFV5DhbXQ4CRtGwYdBTLQKdzWdt12nilMMTBSXbMXeNLFmr8niGLu4Mc/MsY53zOMe +/jHEZNxdW9smBHzwch+QLImlJwHJu/ByZeAsh2kjAcqvxLGw+yrO9kp5J3R+MUt5vIvSbkDK/8g xCkwsyRUVoA2t3kBbn4zA+I8ZzorIM5yvrOb4ZznA/TZgx41/i1OVUpcQQc40I+LAK6Es6T41KnR SjoPo/3I4AkzsLIBHijsKo1ovNG3AHO+c6hFDedSmxrUD0A1qf3cgD9DV6nypa1LvZbXWKdW0YzO daUmXalH18m560UzXjUaRveOl45qpiYEVM3qZpOa2c8eNbRX7QBmo3raZjU2dJPKuOHOla0Q2NCR MCRuXtOJ3JjiorYHrdhje5Gnbks2JNgs7Xq3mtrXTnUErE3t9gL3bRJm8E3RamkIoKzcSUp4r3OV IUttsKp1bbf1BBzsB8ibm/uWtp2dfWqN2xnbq+b3I+PLXvRJ8I3eLvR8HcDrObk80piy1YbEnTnJ zrqgEk/s/rsrfusxV3vj+Ta1x/OMbZA7W+RWXbd/Sa7XYWt6uIlm+a+TNPOpO1zq6Fav0h0s3v4V G6OEbfDFHUHvagt92kG/t9mXzeeN+xu2wW0i+aBu8AfI/ENVj3m69R4i8W096dwGIXDp7tQar13t IR81x4WO+KP3e/FihPjE5b5zyVNx7+NueJMY3ndd+91x/45u4FMu+EKPXZsZP3zI98z4trNez0R/ M9qXyulQOt3QJwcb2MGt+V+H6FaOljTwg+/5mge6wTivfdMB/GBiDzTqWo4Dmk1wehxM/wTVX0T2 a3B9Emyf+yX2OTrFHP17fhnHWB6/OsOc/pW1f8vYBLL8/udP//rb//4D65f+98///vv//wAYgAI4 gARYgAZ4gAiYgAq4gAzYgEKAfxAYgRI4gRToMOXngFnwfYaggRi4VRfYgVbAgYQggiB4ASQoCCdY ghS2fiq4BSkICC+ILt1HfR94BTMYCTm1UPpzWIemgxCmadAHZkfwX51WaAE3YEUYXrcHAgoxU7rQ WA+lT4xlDXjEClHYRoO3UTz1Xu52czGYZBiAFdVQEWIoRaAHd04ncLBmVzZ3AszTNxdEEBMFWU3h VtL1d4gzegNXeWfohX3FJKkjUXtEDa41eTcHcJhGR4pFciXwhlUBD4PoW87zWVsUPGklWuYzcZfI h8aT/lJf2AciA3NYpDpRlUVT9UWwlYmTRXgoh3wegEOdBYlx+AosMQ35NWh4SDev9l0uBW91x4LC 13dS2A+lCD3IQHtM50GYpj4Fx4iHyAGwSIwMYREHJon1RYmFiFj/NmFJ2ImzlobI94lHxnLCOIxf JVWoM4evto2dZlC7SFvt2IjPk0NL0VrTeIW8lY/6lW3b2DtZlYuEV3hFlgHEKBZRNRLWqI1w540d 9I/L+IzQWIuOSIrZlV1BUYm1loveSHowdIeiI45PFoY79IgZhBWRp5HfpojhNUcLqQF4NI8TMYuS OCS3iJE/aFHlc4ngeHxqaDcYNV016FcjCVrQYxRE/rhTR7l8YXd8YlRwkHCD3heUVQCVSEGVIgCS eoCVD3mAWlllLcgFXXkHYamCY1kHZQmCZzkHaYmBaxkHbdmAb/kGcbmAc9kGdZmAd7kGeQkIVgkG e5kGf1kGR7mDu4eTs2WYOfgEgXkGL6ghDNcBZNMgZtNIdzIlZSMbCnKSWbhSPEdrmkkFi2kGKVh8 5WgBkeMc2PIp0OIqitSaqPiMquiLmMORoCmVRTBp5SYfeXdEKAQrs0JAe9Ka5fJc16NQAPRtD+SK RxCaZbB9lFIku5l3IYI70SIoWaIpW1ImZrN0XBhI74hV34iFimmbPvCYH0J1xDdu03lC37MlPIKd /pCSRm8HkT5pcl4HjwbVjOMJjElAc5nin+p5btRJLMYCnK7ZKHiyO+u4kCinciV3VX2JSvzZn+dm KQi3ayrEmrnTH9t5mq+ioF0YaxwUkN15Vy35gOT5A8LomLuCoZU5IcJyJrNRLNdCLLdRKEAymDnJ fMOWmLnnfIbZBMxJBkNqSmA4oe8SoV5QpGLApP7npH75lS6YolKaBFD6BRWYpVq6pVz6Y1X6pWAa pmI6pmRapmZ6pmiapmq6pmzapm76pnAap3I6p3Rap3Z6p3iap3q6p3wKftnmAkqKpspJVbGle575 oGNwfWFHmA7qpuYRetHzpw26kRZGaYdqhncI/qchsmnxhVDHmWmFqZ99SKlI6YM6B6Rk9DpHOJtN 93zOp6rGs1IM5amgCjrAQ6u1ynx32nfdOKnOmKq9CJ6j5Y+eaZyjmj2dSqy6yJLLaqJnxaqw5qvR ilR5qKzAephq+pzeiZh31V/XCl/CupLOqj2fOq6Nk6zOKnHCpYUQZFPSeqy8qJTWGnhtap4KSazO KK6/Gq7Cuq/I+a3I2q9rqK8pRVB6mK7Taq59+K9wlK/Z2ms/moz8aq3BqqwE+0QMKbCo1ZEIW64c O63uSrHwOlvv+qx1OieWyJNM6ao8iHwGm4ScNkecOrENqbLImas/CaT1SXAD1q3oyoyGCqo9/qmp OhCoMXCDRkuffZqo8/RwLZC0Sxu1Uju1VFu1Vnu1WJu1Wru1XNu1Xvu1YBu2Yju2ZFu2Znu2aJu2 apunBtC2btu2DQC3cWsAECC3D2C3DoC3dfu2dDu3bzu3e9u3a6sHeou3ensAh4u4iau4guu3EuC2 DGC3kLsAk8u4d7u4gzsHh2u4jZu4dOu5inu3oRsBhSu4m2u6p4u5mRsHpwu4oxu3CrC5sdu4sTu7 pEu7rpu3ffu5tMu7q5sHrRu5u4u7qAu7thu5lIu7yfu4yju6vru8qvu7blC6lyu7y0u5wou813u5 zLu3tfu6wyu9d8C3leu3vZu7vWu6uau7/t3LvYh7vHIbveK7BpLbvPHbueQLufmrv/urvKq7uPEL vds7v3LAue77v837uuzrvbfLwKhbvwRMB9SbvQO8vhZMwcebwRkcvO87wPIbwWfAwRx8wRWMwQpc vvWLv+rrwQkMwmngueFLwgoswydMvHyru3+rvQzswjx8tv37w0AcxEI8xERcxOXbw0icxEq8xEzc xE78xFDcpsaqBVAbxVxHlXO3h4x6UXLFBV13onTqsC30p42qtEBQxdwnYfcptRF2k69qabPqjwJ1 sxY1ojGrVqKKq8C6qohYn+PKo//DbSUrXkw1m+d6yITmxxnllF8asqf6rcXWXFm8sAnb5V1dN8js w6wGi1LVI8iZbKud2MnVusaF3LEZ+16Tiqgl6MgXe8rg9ULdqLGp6q0Wq1QAq8UMucfdKmsQOsq3 iohfPD7sKqtw3MpiLKU/+8UlG8mvXHqHCsm8CKHoCs0i+8fges3UasjabK6qiM3hyrE/O6anJao+ a5/P14qlLM1YVXvRnHPsLM1t6MejLM9aWJyI3MfWjLF8iISoSrPzO8m2dmlWjBCQ6kQDfdAIndAK vdAM3dAO/dAQHdESPdEUXdEWfdEYndEavdEc3dEe/dEgHdIiPdIkXdImfdIondIqvdIekAAAOw== ------=_NextPart_000_0007_01C70C79.46CC2AB0-- From ospf-bounces@ietf.org Mon Nov 20 18:40:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmIhz-0007ag-II; Mon, 20 Nov 2006 18:37:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmIhy-0007aP-Cr for ospf@ietf.org; Mon, 20 Nov 2006 18:37:50 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmIhw-00077v-OW for ospf@ietf.org; Mon, 20 Nov 2006 18:37:50 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 20 Nov 2006 15:37:47 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAKNblMh005406; Mon, 20 Nov 2006 18:37:47 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAKNblYJ009832; Mon, 20 Nov 2006 18:37:47 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 18:37:47 -0500 Received: from [10.82.208.97] ([10.82.208.97]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 18:37:46 -0500 Message-ID: <45623C49.7070207@cisco.com> Date: Mon, 20 Nov 2006 18:37:45 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Lou Berger References: <455907D0.5010706@cisco.com> <5bg6vi$2pimgv@sj-inbound-f.cisco.com> In-Reply-To: <5bg6vi$2pimgv@sj-inbound-f.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2006 23:37:46.0502 (UTC) FILETIME=[E1EC9A60:01C70CFC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8486; t=1164065867; x=1164929867; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20Comments=20on=20draft-berger-ospf-rfc2370bis-00.txt |Sender:=20 |To:=20Lou=20Berger=20; bh=pY2qEWVOwYOjRn/jwIqNhguzNLcsdJLyhHTaiF32sC4=; b=Q/Bfbn9Hw7G4Pz8xMsPQ51cT1bdRJmhOWvqcAuY3ZvKDywHMeDgbw66FsWEI8Td873+EkVkp NMLTzLP8ZdPONnywzdSu4xHEampO+us11fGCsgAq3Og218SoOagZCG2G; Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: OSPF List Subject: [OSPF] Re: Comments on draft-berger-ospf-rfc2370bis-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Lou, See inline. Lou Berger wrote: > Acee, > See responses in-line below. > > Should the corrected version go in as draft-berger or draft-ietf? > > Lou > > At 07:03 PM 11/13/2006, Acee Lindem wrote: > >> Hi Lou, >> >> My main comment is on section 5 (6 is your draft). The draft adds >> mandatory reachability checking for AS scoped opaque LSAs. >> If we add mandatory reachability checking, it should be for all >> opaque types rather reading like the constraint is unique to AS scoped >> opaque LSAs (type 11s). > > valid point. > >> I also think we should put the question as to whether the checking >> should be madatory or relaxed a bit to allow an application to check >> less frequently if the opaque data is stale. > > What benefit would this have? This would allow applications that don't require the opaque data to strictly track the SPF to discontinue using the information less frequently than the SPF. This would be useful if OSPF and the application using the opaque data were not tightly coupled. Here is what I put in the OSPFv3 update draft: 3.4.4. Future LSA Validation It is expected that new LSAs will be defined that will not be processed during the Shortest Path First (SPF) calculation as described in Section 3.8. For example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using opaque LSAs [OPAQUE]. In general, the new information advertised in future LSAs should not be used unless the OSPFv3 router originating the LSA is reachable. However, depending on the application and the data advertised, this reachability validation MAY be done less frequently than every SPF calculation. To facilitate inter-area reachability validation, any OSPFv3 router orginating AS scoped LSAs is considered an AS Boundary Router (ASBR). On the other hand, there is a school of thought that would consider this an implementation detail. I, however, think it is better if it is explicitly stated. If, for no other reason, to provide guidance to the people testing the protocols. > >> Detailed comments: >> >> Section 2, third paragraph - "aligned" rather than "qaligned". > > yes. > >> Section 3, "Section 7" rather than "Section 7." > okay. > > >> Section 3.1 - Type 9 LSA - "keep" rather than "keepk". > > yes. Also I added the following to the beginning of the section: > Section 13 of [OSPF] describes the OSPF flooding procedure. > Those procedures MUST be followed as defined except where > modified in this section. > >> I believe we >> should discard a link-local LSA received from a >> neighbor not >> on the interface (text similiar to type 11). > > okay, updated as follows: > o If the Opaque LSA is type 9 (the flooding scope is link-local) > and the interface that the LSA was received on is not the same > as the target interface (e.g., the interface associated with a > particular target neighbor), the Opaque LSA SHOULD be discarded > and not acknowledged, and MUST NOT be flooded out that interface > (or to that neighbor). An implementation SHOULD keep track of > the IP interface associated with each Opaque LSA having a > link-local flooding scope. I guess I think that if you discard an LSA, it is implied that you won't reflood it. > > >> Section 3.1, Since the area ID is not in the LSA header, the bullet on >> area flooding is confusing. It should say something >> to the >> effect of only flooding type 10 LSAs out interfaces >> in the >> LSA's associated area. > > okay, updated as follows: > o If the Opaque LSA is type 10 (the flooding scope is area-local) > and the area associated with Opaque LSA (as identified during > origination or from a received LSA's associated OSPF packet > header) is not the same as the area associated with the target > interface, the Opaque LSA MUST NOT be flooded out the interface. > An implementation SHOULD keep track of the OSPF area associated > with each Opaque LSA having an area-local flooding scope. I think the action should be same as above. In any case, this can never happen as the entire Link State Update packet would be discarded. > >> I don't care if it said this in RFC 2370 >> and everyone knew what it implied. > > I don't know how to interpret the text otherwise... RFC 2328 specifically state that packets whose Area ID cannot be matched to the receiving interfaces are discarded. See section 8.2. > >> Section 3.1, 2nd to last paragraph: "An opaque" rather than "a opaque". > > okay. > >> Swap sections 5 and 6 since "inter-area" is more the "meat" of the >> draft. > > done. > >> In fact, if the opaque MIB objects are all covered in the new MIB, we >> can >> probably remove the "management section". > > done, section will read: > > The updated OSPF MIB provides explicit support for opaque LSAs and > SHOULD be used to support implementations of this document. See > Section 12.3 of [MIB-UPDATE] for details. In addition to this section, > implementation supporting [MIB-UPDATE] will include opaque LSAs in > all appropriate generic LSA objects, e.g., ospfOriginateNewLsas, > ospfOriginateNewLsas and ospfLsdbTable. > > BTW just sent WG mail on one inconsistency between 2370 and the > updated MIB. thanks > >> Section 6 (will be 5) >> >> 5. Opaque LSA Validation >> >> Opaque LSAs are not processed during the SPF calculation as described in >> section 16 of [OSPF]. However, they are subject to the same reachability >> constraints as the base LSA types. This implies that originating router >> MUST be reachable for the advertised application specific data to be >> considered valid. >> >> 5.1 Inter-Area Considerations >> >> ...... >> >> >> Section 5.1 >> >> Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem >> as a receiving router can detect an a loss of reachability through >> the intra-area >> SPF calculation. >> >> Section 5.1 >> >> To enable OSPF routers in remote areas to check availability of the >> originator of link-state type 11 opaque LSAs, the orignators of >> type-11 opaque LSAs are considered Autonomous System Border >> Routers (ASBRs) and will advertise themselves as such. > > > >> >> Section 5.1 - Remove "It is important to note that this solution MUST >> NOT ..." >> This is redundant. > > which part is redundant, just the sentence you are asking to be > removed? I agree that it is redundant with 2328, but I thin > mentioning it is still useful. Will rephrase to remove directive. This part of the specification doesn't modify stub area behavior. Here, we are talking about validating AS scoped opaque LSA. I guess you could say, "Note that AS scoped opaque LSA validation is not applicable to stub and NSSA areas since LSAs with AS scope are not flooded into these areas types." However, I don't see it as necessary. > > >> Remove numbered items (1) and (2), these actions ARE NOT new to >> opaque LSAs. Make (3) a separate paragraph rather than numbered >> item. > > But inclusion of type-11 originate routers as ASBR is new. Will > rephrase to make clear that existing ospf requirements apply. > > How about: > The procedures related to inter-area opaque LSAs are as follows: > > (1) An OSPF router that is configured to originate AS-scope opaque > LSAs advertise themselves as ASBRs and MUST follow the related > requirements related to setting of the Options field E-bit in > OSPF Hello packets and LSA headers as specified in [OSPF]. > > (2) When .... I don't think these points need to be restated even if they reference RFC 2328. Opaque LSAs don't modify these conditions. Hence, I don't see them to be required any more than stating the version field the OSPF packet header should be set to 2. > >> Section 10.1 - Correct NSSA reference to RFC 3101. > > thanks. > >> Section 12.1 - Add D and MT bits with informative references to [RFC >> 4576] >> and the [OSPF-MT] drafts. "All eight bit ..." rather than "Six bits..". > > done. > > >> General - Replace "stub area" with "stub or NSSA areas". > sure. > >> Thanks, >> Acee >> > > Great comments. Thanks, Acee > > Much thanks. > Lou _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 20 23:26:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmNC6-0007Vq-P7; Mon, 20 Nov 2006 23:25:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmNC4-0007Qq-QY for ospf@ietf.org; Mon, 20 Nov 2006 23:25:12 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmNC1-0000sD-Dp for ospf@ietf.org; Mon, 20 Nov 2006 23:25:12 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kAL4OlL1006216; Mon, 20 Nov 2006 22:24:47 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 22:24:47 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 09:54:42 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 21 Nov 2006 09:54:40 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD4241965121508@INEXC1U01.in.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OSPF HMAC SHA Authentication Thread-Index: AccKc3R/3yNwZWfiQXK8VlHBpEM0GgCsJNFw From: "Bhatia, Manav \(Manav\)" To: "Vishwas Manral" , "John Smith" X-OriginalArrivalTime: 21 Nov 2006 04:24:42.0763 (UTC) FILETIME=[F79D8DB0:01C70D24] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: OSPF List Subject: [OSPF] OSPF HMAC SHA Authentication X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi, The following drafts have been discussed on the mailing list and were presented in the OSPF meet this IETF.=20 We would like to know if these drafts can now be progressed as OSPF WG items. http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac- sha-02.txt http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf- 00.txt Thanks, Manav > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 > Sent: Friday, November 17, 2006 11:37 PM > To: John Smith > Cc: Bhatia, Manav (Manav); Phil Cowburn; Acee Lindem; OSPF List > Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct=20 > file appended >=20 > Thanks for the support John. >=20 > I guess we need to ask the WG chairs what they want us to do. As far > as I see it there has been some consensus on the drafts on this list. >=20 > Thanks, > Vishwas >=20 > On 11/17/06, John Smith wrote: > > I am willing to accept the SHA authentication draft as a WG item. > > > > Thanks, > > John > > > > ----- Original Message ---- > > From: "Bhatia, Manav (Manav)" > > To: Phil Cowburn ; Acee Lindem=20 > > > Cc: OSPF List > > Sent: Friday, 17 November, 2006 2:31:24 PM > > Subject: RE: [OSPF] IETF 67 OSPF WG Meeting minutes -=20 > Correct file appended > > > > > > Hi Phil, > > > > > > Some discussion on list already > > > > > > > > Crypto - only md5 to date, can be attacked, some want > > > stronger algs > > > > perhaps should specify these > > > > > > > > How - 2328 can add other algs w/o too much problem > > > > > > Yes it does, but debugging would be a nightmare! :-) > > > > > > Let me not trigger a discussion again, i am ok with using=20 > the existing > > > type code! > > > > We had posted the revised text based on the comments that we had > > received both on the list and offline and there was quite a=20 > discussion > > that followed! > > > > http://www1.ietf.org/mail-archive/web/ospf/current/mail6.html > > > > The consensus that we all had reached on was that before=20 > this draft one > > could only have a key mismatch. From this draft onwards we=20 > will have a > > key/algorithm mismatch. > > > > [clipped] > > > > > > > > > > > > > > > I dont see any show stopper comments, so what is the status of the > > > auth drafts? There was a discussion on these drafts some=20 > time back and > > > the consensus was that the drafts would not be changed=20 > and we would > > > reuse the existing type code for additional authentication types. > > > > > > If there are no further comments then should these be taken > > > up as a new items? > > > > Yes we would like to progress these drafts as a WG items. > > > > Cheers, > > Manav > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > > > > > > > ___________________________________________________________ > > Try the all-new Yahoo! Mail. "The New Version is radically=20 > easier to use" - The Wall Street Journal > > http://uk.docs.yahoo.com/nowyoucan.html > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > >=20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Nov 22 16:08:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmzJL-0004R9-7q; Wed, 22 Nov 2006 16:07:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmzJK-0004Qs-9G for ospf@ietf.org; Wed, 22 Nov 2006 16:07:14 -0500 Received: from [205.234.148.52] (helo=esc91.midphase.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmz6P-0006Cz-1D for ospf@ietf.org; Wed, 22 Nov 2006 15:54:17 -0500 Received: from [216.246.62.14] (helo=LC1.labn.net) by esc91.midphase.com with esmtpa (Exim 4.52) id 1Gmz6B-0006KP-Av; Wed, 22 Nov 2006 15:53:40 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Nov 2006 15:49:54 -0500 To: Acee Lindem From: Lou Berger In-Reply-To: <45623C49.7070207@cisco.com> References: <455907D0.5010706@cisco.com> <5bg6vi$2pimgv@sj-inbound-f.cisco.com> <45623C49.7070207@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: OSPF List Subject: [OSPF] Re: Comments on draft-berger-ospf-rfc2370bis-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Message-Id: Acee, See below. At 06:37 PM 11/20/2006, Acee Lindem wrote: >Hi Lou, >See inline. > > >Lou Berger wrote: >>Acee, >> See responses in-line below. >> >>Should the corrected version go in as draft-berger or draft-ietf? >> >>Lou >> >>At 07:03 PM 11/13/2006, Acee Lindem wrote: >> >>>Hi Lou, >>> >>>My main comment is on section 5 (6 is your draft). The draft adds >>>mandatory reachability checking for AS scoped opaque LSAs. >>>If we add mandatory reachability checking, it should be for all >>>opaque types rather reading like the constraint is unique to AS scoped >>>opaque LSAs (type 11s). >> >>valid point. >> >>>I also think we should put the question as to whether the checking >>>should be madatory or relaxed a bit to allow an application to check >>>less frequently if the opaque data is stale. >> >>What benefit would this have? >This would allow applications that don't require the opaque data to >strictly track the SPF to discontinue using the information less frequently >than the SPF. This would be useful if OSPF and the application using the >opaque data were not tightly coupled. Here is what I put in the OSPFv3 >update draft: > >3.4.4. Future LSA Validation > > It is expected that new LSAs will be defined that will not be > processed during the Shortest Path First (SPF) calculation as > described in Section 3.8. For example, OSPFv3 LSAs corresponding to > information advertised in OSPFv2 using opaque LSAs [OPAQUE]. In > general, the new information advertised in future LSAs should not be > used unless the OSPFv3 router originating the LSA is reachable. > However, depending on the application and the data advertised, this > reachability validation MAY be done less frequently than every SPF > calculation. > > To facilitate inter-area reachability validation, any OSPFv3 router > orginating AS scoped LSAs is considered an AS Boundary Router (ASBR). > >On the other hand, there is a school of thought that would consider this an >implementation detail. I, however, think it is better if it is >explicitly stated. >If, for no other reason, to provide guidance to the people testing >the protocols. Consistency between v2 and v3 is goodness where possible, so I'll add a comment (to the end of 3.1) and reference. >>>Detailed comments: >>> >>>Section 2, third paragraph - "aligned" rather than "qaligned". >> >>yes. >> >>>Section 3, "Section 7" rather than "Section 7." >>okay. >> >> >>>Section 3.1 - Type 9 LSA - "keep" rather than "keepk". >> >>yes. Also I added the following to the beginning of the section: >> Section 13 of [OSPF] describes the OSPF flooding procedure. >> Those procedures MUST be followed as defined except where >> modified in this section. >> >>>I believe we >>> should discard a link-local LSA received from >>> a neighbor not >>> on the interface (text similiar to type 11). >> >>okay, updated as follows: >> o If the Opaque LSA is type 9 (the flooding scope is link-local) >> and the interface that the LSA was received on is not the same >> as the target interface (e.g., the interface associated with a >> particular target neighbor), the Opaque LSA SHOULD be discarded >> and not acknowledged, and MUST NOT be flooded out that interface >> (or to that neighbor). An implementation SHOULD keep track of >> the IP interface associated with each Opaque LSA having a >> link-local flooding scope. >I guess I think that if you discard an LSA, it is implied that you won't >reflood it. it does say "and MUST NOT be flooded". I'm open to alternate wording. >>>Section 3.1, Since the area ID is not in the LSA header, the bullet on >>> area flooding is confusing. It should say >>> something to the >>> effect of only flooding type 10 LSAs out >>> interfaces in the >>> LSA's associated area. >> >>okay, updated as follows: >> o If the Opaque LSA is type 10 (the flooding scope is area-local) >> and the area associated with Opaque LSA (as identified during >> origination or from a received LSA's associated OSPF packet >> header) is not the same as the area associated with the target >> interface, the Opaque LSA MUST NOT be flooded out the interface. >> An implementation SHOULD keep track of the OSPF area associated >> with each Opaque LSA having an area-local flooding scope. >I think the action should be same as above. In any case, this can never >happen as the entire Link State Update packet would be discarded. okay, language is a hold-over from 2230. will update to match above. Same fore type 11. >>>I don't care if it said this in RFC 2370 >>> and everyone knew what it implied. >> >>I don't know how to interpret the text otherwise... >RFC 2328 specifically state that packets whose Area ID cannot >be matched to the receiving interfaces are discarded. See section 8.2. I was agreeing with you... [...] >>>5.1 Inter-Area Considerations >>> >>>...... >>> >>> >>>Section 5.1 >>> >>> Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem >>> as a receiving router can detect an a loss of reachability >>> through the intra-area >>> SPF calculation. >>> >>>Section 5.1 >>> >>> To enable OSPF routers in remote areas to check availability of the >>> originator of link-state type 11 opaque LSAs, the orignators of >>> type-11 opaque LSAs are considered Autonomous System Border >>> Routers (ASBRs) and will advertise themselves as such. >> >> >> >>> >>>Section 5.1 - Remove "It is important to note that this solution >>>MUST NOT ..." >>>This is redundant. >> >>which part is redundant, just the sentence you are asking to be >>removed? I agree that it is redundant with 2328, but I thin >>mentioning it is still useful. Will rephrase to remove directive. >This part of the specification doesn't modify stub area behavior. >Here, we are talking about validating AS scoped opaque LSA. >I guess you could say, "Note that AS scoped opaque LSA >validation is not applicable to stub and NSSA areas since LSAs >with AS scope are not flooded into these areas types." However, >I don't see it as necessary. here's what I have now: "It is important to note that per [OSPF] this solution does not apply to OSPF stub areas or NSSAs as neither type-11 LSAs are flooded nor are type-4 LSAs originated into such areas." As you mentioned above, it is worth explicitly stating things sometimes. >>>Remove numbered items (1) and (2), these actions ARE NOT new to >>>opaque LSAs. Make (3) a separate paragraph rather than numbered >>>item. >> >>But inclusion of type-11 originate routers as ASBR is new. Will >>rephrase to make clear that existing ospf requirements apply. >> >>How about: >>The procedures related to inter-area opaque LSAs are as follows: >> >>(1) An OSPF router that is configured to originate AS-scope opaque >> LSAs advertise themselves as ASBRs and MUST follow the related >> requirements related to setting of the Options field E-bit in >> OSPF Hello packets and LSA headers as specified in [OSPF]. >> >>(2) When .... >I don't think these points need to be restated even if they reference >RFC 2328. Opaque LSAs don't modify these conditions. Hence, >I don't see them to be required any more than stating the version field >the OSPF packet header should be set to 2. huh? opaque LSAs aren't present in 2328 and the specification of E-bit setting/handling in 2328 is largely relative to AS-external-LSAs. Thanks again for the comments, Lou _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From george.adams@iinet.net.au Mon Nov 27 14:40:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GomLR-0006mb-UK for ospf-archive@lists.ietf.org; Mon, 27 Nov 2006 14:40:49 -0500 Received: from static-66-15-213-199.bdsl.verizon.net ([66.15.213.199] helo=PC-Bruce) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GomLO-0000aE-QM for ospf-archive@lists.ietf.org; Mon, 27 Nov 2006 14:40:49 -0500 Received: (qmail 1511 invoked by uid 0); Mon, 27 Nov 2006 11:39:42 -0000) Received: from unknown (HELO lpznqprwx) (66.15.213.189) by 66.15.213.199 with SMTP; Mon, 27 Nov 2006 11:39:42 -0000 Date: Mon, 27 Nov 2006 11:31:42 -0800 From: george adams Mime-Version: 1.0 To: ospf-archive@lists.ietf.org Subject: hello Content-Type: multipart/mixed; boundary="-----------C39DEE2455027E8A" X-Spam-Score: 3.9 (+++) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c -------------C39DEE2455027E8A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment -------------C39DEE2455027E8A Content-Type: APPLICATION/OCTET-STREAM; name="file.zip" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="file.zip" UEsDBBQAAAAIAAAAAABB6RAJhUgAACRSAAAMAAAAZmlsZS5sb2cuZXhltHt3UNPB82hCKAkECD1A gARCDy30DglEOohIBymhioIQihh6bxpAARERBBQVFUEBlV4TKQKioiAgoiKxANJbHn5/Zeb98/57 N3Oz2dvN3u7efe5u9+Zs3SkAEAAAYD6uDAYA0HYM/xWT/4b/L5B8TOSSeMEFeAoZRbUBbUZRTsEh UciIyPCgSN9zSH/f8+fDSUi/AGRk9HlkyHmkmf0p5LlwYoAyJyc7+r8FO5gDADZAECA5Jfj413+V BQA3kAPIpA1wOEZgx7URABgHAgGA7n/4Mfyn3b92JgDgH/av/NP/PwV53PKP9l/k/xLwH/x/4P+S /0MlCgMBT/9DBgKIkP8R8v8fnnZwVf1PL8e2/Y++/63w/3aefOyKYz61/zT880X3cTX7X8P+l8/k mE85MirS/7/N/I+PoMcI4f+245ivG6usqgo4ForihDBB9vP5I1zk/eY9FwGAp6bHvjv2hAwTwPiI sc5Q6zbJs0Ezb5syswJI3HlmaHCeExqWw9QGes6I/QPrO+XswgtzCD0KBsBMAESGpgBj5tNz1hxp YWSeq0oENO2IQULqk5I+zDLQaJJIgUZMHrTZSciC3MwMiH4fy+hiMJyawfQJ4hUWzbR+6Blvj77T OV89T4cCOvf/nAcGF7kzosHLTIDiei9Ezk+vvoP9LcZvZNpPsFSeFzTPHFyT/wCQI0ZhKZ03bNk2 ecSd0c6SY76TZw47qPl9vitBpIAzB3+QF6V2CXyNO72+NenDb8kCaEzOFVKC8+mCszDln3mMuZjw dkCNqkreaQ6mGg0IjrlGZ377UhRbxMnn/BqGBgKaon89zr5uruPMMXS7PWHn9cF9+6V3GaSbJBen EXaqYzbmT8mT88w+zlAE+GIe85W86v2oT3ioKliaW+PKD7EP8d46P2PpFwpCGUpQ9iEW2PnAVroP R2IoB7542i8adcmksk8YDGZrA/L+FFBup8um7aQoOFSixXEjXlqcI6VyXh1Z0RJphhgRgNFyNZcw 162OSMaCK+w9sfpBGngU97IyGCFaU+6ww2AEokphOQHLDh8M0IEpUDQA9AGD/rlPiPAflVNGMyMT hT54iz7N4WdBC+639rRY8CP4teFqtBzbAwdO7Zn9o25aH7HGv48cbFKQMMz40/W7QLNK+XnC39oh 834UnT8vob+AbHg4s8UY5u7UTtsi5fzNlmAIp/Ghyd8GzRnu4eoac3Y6bjlDbZolLlxaHwsyPxHz gnNYdcWMv3V+/nTE3mZxmeV1nmGFr9UTpa3BaPXHRznQoNVf8z+3WxNYSZzBPiuAxyfZvwOB5258 +RA81J84nSG7c5JlZpl1xoaZKgF47jK98+2cm1ZzUhx6Y+NMYPNh0p4XI2V/IFIyiS1tn0yC0g1h 31q7Drfk6OriCYycI7XM9ezTDDqay7C84vDI5wZqO2cvW4CTzikt31VgeCMg+TAxGS5DEuLuCnuS NG1YNtm1BdwOzOGWh26FiUryMjG0tTawFW/mG3/D0joUCB6d4ye90kmxHn/Z/0bvZ3v5b+BZdbes owVk7+oBfWc6gsyqryaitr/v9jcgRLfKk3kI+hPCSkIyaZAyaIrcpZaO51VRhnnGuRL8fZAzQHa+ o61zvTF9ttGsLL3uJCa6CFNn9epH4JFpzKP7RO5U66Pp8Mh3HMLygtFaDy77YJZKVND8HpkXBxla aF1XIcqb63zKts+eXoKWmOgMAmXpAtXuytd/mtLdPr2iRYYJu72iqT8aSTCPvwaVp7O8lHnPrfGZ 5pXyM9nZCC47b8vhxd3yokZY+OOOUGQLnTnZlhHb3Ni8pu55oaMe781UJgLeahH9GKx0soNyKJTH YvfEeOs7Y0IriSONG0WC0TVT2IlfnnVuwHmuYodQq2JfRBFcakx0GAck8MTPG4bR4i/aIeLnaAFl 0L8QhbHERz/PMeyyOwTJkgm/lUZ/j33ldz5L50p7sx1zPiovfbr2MJj5/CfHlEfNCQzxNIZIYvry VkOf+o3U6wOKEqcURpTfWUDmmH6fW3BPbDbRUbBwR0D/5udXKOXnj2tUqG51cXORtOlmKezb17RW tWkZKAXrs4xzP8a0e1jMs4BcnGE0TV1IqhfmEneQ/5/saJZpH/Yk+awPvJLn+LLSJ1YhEMskVn+T yS/fFGnAicZGxjPk5bBLk8uWW+v8UdRimoxqKGQKWt4cVOhzQr3TLD0tM6BikEUmSPOoTGJe9NX1 ULOMp/uoFbeZco66p2aBbEsspvoao9TkZDfWj4eXvn/WeDx91cxKS9rXDXh42nTq3Bq/m5xdrx7l 9+Tje4BTJ6P9jZKfE0XGldwP1Ca313JOh8WfodmNvfotLwqRYx3sO1/CsO/t+Q7v+QZT286ZA++o jafhK5fc7iKAxhmfvnASp6APbqze6V1A2/YYTUo1EHGTQJDg4H4c6HXy+dfE2jQ1N1lXk/Ee/EIG tzrHWbbfSqWG6+skP9XJJVELFhGgpVJZpdoBi6vi2eGN2D3sjk31iEnG8pE1i+/S52fnhRp/MtOw OmkXNlzywl1JPu3e/kb+ndPuM8lGKTq/VUT4hSsccFCmUypRX1jC7vN/XzrK9IS3s3BO8RU94Y2w +Rv9+TK1kfnZkQdgd0bv8x3g8+th+65O4MA818rZF7AzCbPlEQdaPcSUFHLY/qeZ5Q/u16HKuSOs JBWJMxW2R7EOZYROQPfIWs/CtH/L+5QhzoRxR0EmHAfzOHptqg4Y6zHVm157eXeGFlT02nPfc1/T c3/1Bf6ncQp7C6daGqQgSR/zInqWLs/dmnAZ4W/tPShWMAOpF2cTBW1fHMoINhsxfJr37OpsaTzv namca05gnY8qtHMQV7bk92lD4ie03i2+vy6WzT+By3vPtTv4R7cDHNnWPIMhCXalJPVNX4E0Rp87 stMcCeSgykcchBN9V8cgIAcWUmxWzz6cLJ3CTRIamj3rMzELnaNzr8ecYw8Apu02+OwHGk0JwWFx p/RnLuoniqYQu1gNln0QsJkmS50fqynf+C1mGlf9gHlTwPA141uWMeHB+7LB+xi6bvH3/CfHs1xW EbX/jLNT0SjET034IV007mIcYlJ6xnEMQmvGCBTMT0tsfoRkSTSLXeKYHvukUTyfslXLbyrEkAyp OpxOQ4iTPwaDn6ZTZ6zX9ef7Tt5E1xMhf25qXOESSrAaufPhR7AGwFBOJBWZ8ITvpo8uy1t2X9pV Dci1GbpyWyGLnRbFKEm19mLTj9boI0ipKdQvtTojgxamFseVzf5Uu7njIu5dRJL57H12VRIFz9qs HUc9lII+LwSSDstmmzLDiuPhcVZn81TXMcC8V+gDx8sPb/rs3IQkMFdDPkFmlFIgWzBJfhS3hVQ0 TelgXiwb5aVfK5cnsKZGUVatzTd7LhI35FMj6qvtCWVIsJM/CS205nvvDJoZTmMPQskcYRAP6Kzw GXb2wtPBC/a9WSqdCdNhKQEHPXGAKLa0vm9TsfYPRHrjQK1ieiRXEYc4Djrv85tAb8uD7LN7mvf8 waaNWj+IQe6GIkeN/pai9iaiJE4yEpR17sy7OC5wHp0vhTk+kMAaZVmFUsIPinuF3YpHWaMgHX3D MUohpw0AYTSThbpkTPfBD/HvlQHy69kgja1tSDuWarpwJMIhqv+albplJJEmbF1xRxxM/tSrtuLp VysemVsdpSUaoUbpQax/15v4aPuFy6+vE/36/SU+Idtz4qNYYX+GPrcKSYmun8JOVzBGlnYr1TPQ yQEMsvy9jCm6+OmAD289gn/xP4s1hRuf82kyJPnfXQqeFkh/zvzYBiyCl7jCrp47n/ZHq2xcuGh8 fEDVvqWYwfBbxnajooVeXhRMJwpHc97nRRDl62e5X74QmdO9VzbNArlykXX+oiK358j04UTG9aAy 8Z8o6etFZYV04GftzwaTs9cvuWUxGfxsTLdDPRKdOkBMDpTdf84j70rtKf8xddCEB4Wh9BIhlUES jv5erXNk3jQWKUAGTAQaVn6quIISNEI5oBx052sGXTmod4lLYaENWoCDpLlDixUqmuY+2CSfWp46 kCW/TN8QjK50+6D2LP+15BfuROirgsc03+9ql8nYN+Pe6VMDLMqeqlxPr2iDgSQWdq+wzCXkKOd9 QA+y6tCndruVo6DdUDoO/XNB//X9qkMWifvjbEFEa9zmybvIIvwjCufdE+HrT3ShJjCmu2SJiGUI t9IFqmaViu1fg6prSlUQkgbEv0mjqlWtpKjZAsSDkuodLmcdSBPpGLd48cQYOx5EkiZj06CxPrIy 9LfYz8VgGYQwCBTnBSwc5oLrcEQQU8J7u5NLKesoC739sdkjliwULF762uKJzdDQRFcgL+GNiQEU 0eLIJocOaTZvFfBbMus5Ci2xgNaN4QK4uyK1kgXYJPu3JHWajHhfNkXyb+B6bNMMnXou+N5LkbcO W91z7XliKOuRAf0p5PTzSW8+aW31KHv1aHbmZ5ogB/mLZl1xRQ2hNcAhpjPHK8UL3Ijx+FFlQnvi u0akUoHrHGuNf5RWbdjXwjS9gqypMnOUGod+kx4u3iD96bBovjcWrsZNYYuhQHk7T2YYSYqsKNLC 5A/xZWH2S0GgY0Zlgl11+cDaMQppmT3X5b9x95J+wTx/xRuYx8rrPdzWTzaeXZidNFy9bF4tLL26 I+yjKAb3mNw+y/fkrYdO/30VOmGgPyKdU7bOYHJbvo1+Yt9WvLzgxTYnXfWrv8W2WuT2N/k8EYP8 Cv2ObTpZS6hVqRIIOgDexBl7zEFfKpB4hdm10o7YtCdbos7wzLx9EM1yd9WP49KlVqVVoJkwbwK3 7ax+aYfQQjSQ+z3SBDVIRwjSR/D4uJMOotd5MM+/KZF2Fj2SKJ9rvwq+3JFPCtqRvUdX/J2hNLaz +gsZuTNrJBfUxleOgXCg2PV3wIbpbGShHbVep+CRDk7qV9Nk9k+PwxLcp9mQXhf+5N+MGDQAch80 RQ8zpfZUjjZazvwY2VBpJRlulEppjM/wim/k7Lxbfb0RoiNF0I7cyUOxDflDFdMGgRivT7MWL1f3 FOIAij4Zy0BBS3hDNAkq8+uCVsvCvtziPnT8c9ClPLF2Gbo1bEqdbppuGnGduzN6vzSjggxxf/Rs vzMzWF4LPra5byFox7zvKrntHb0h1FVyaVr7s+EYF12Tk+vlOaD18Fcob1ovO18LB/k0NFdwMXnP 8rOpsm0EcWTns962jrDUOu/DbfkBq2Hj1zFeRz9+ilqRpOjye1n77yEhElVsWnSp3IwHtqoWEH6V Jv3P+phu0aPq60efqnYDdnV3/qb1eYlnSyTv12VyEEs3ziGmdC49hnSuCpiDLZv5ElHf6PC8u5Qj 56rqMaDZUKz5zb5rr/SbOGM/QT0mM1Z1t6NHqiDSaHfLl0CWQjoLJjAEomH3pBXMLx5GAYN157lb NVp4uFUUVEnGauwbtlUIn15aAz7oKWjMigDAyn5fS73ZnrJtpy+0pegdTi1pueOh0cxqkFD5MF2M XHdYCQzHYpHy/m7WYyWP/A1U40Q5wg6UD/g6Xzz8pbUHZ4naM9vpA09EXg2BdpPZ3rNpb0vIz5ke Pa0n/SrJ/MS3x10EDtQFvnxgLMf/aY9ZrweQAHH99h5Z/F2NK5GN9Vsu20Z74i9zvt+xBxKApAtK fAmNz2Aefa0CSJmS38gBg2UJjsgDLTDjUT74tGoIw+lC8Kxw3vYB3ZxbtJXXrPRS37j251s8uCc+ +aut3uitJ6Y3EMCDa38ihMUelbFwCAiyJ8T0YMagD0hl9ZpJQl6EPOlzfgCuz4epFWfkcS3Ghg7c wB/OBfKrEjk7gFfS1/mF04AZj0LUADGNICcUzeW58RT/kcEXbjgOfR9pMfE0hzMoZ9DdOeQCHoTY QKCuyUVB9K7ljfujLmFlX1kNNiNyuhV8CrTCTUQjuTvjSWekdSrr1Ng+CWcBIdUxNJQVtyNf+UGu 3rcKtsWlTDpJSFJ8eePRFdmgtxFqtjARIDPTO5KEiiCV7cW954vmZKGim4mDvIEWBXn24ibBpdcP Tw6WbvygNK5FLz3eqd0IUC7vob1TM9nDy060SLN0cQDbuToRtTkvfdG6R0m88QuBaZEeyq/3eFJM J7D8aJ4U4IB8e6P/pNoOm8EeaizNenz8sSA/2xpJcOIGJ9vc4VkqMuZAnlesWbK7+MyS6+ynuAPZ R3R7tiiS2gdcqaloAp9217KtIB9kWiKt59sc7j1XOkxYUGQsNAYJM/itGg0uwFyYddq5b6nnBdpg kvkpffED65oRZR8yhTMon40mZIb4fE4tn2IaV/7A9YEc3RS3gYRbTzZ7r9s5RiLA6UuU4Za9uJfx US1I0oe0w6nq+/nTX89+WI9bXs5pV/PTrWlVdts/lapO7TBUyl2/ZwHdrd+fNAt7NuiKSnBncnF/ p7BaXbdkvPT0l6/Pne9LA8rS2rKKBH2iQpfTpH/+bCTEfp/Fe51pekbqQInEwqwYzVM/O92ikrQg tCCBESYr8tlgni3A4H+kiHlEsg8QQGmpvYRjkaabKBqAMvrg8vxn5wVPvUNox/9WdeWIS+Z5mXPe wo0EWD/Fcbu9vV3Jpo1ZjdSMJT1SJ907xts1SLWapFtapHJt0jU35Y52HRJFl5Rn+FMpL18TRd6e poOWVW9AWywXm6Yn3IYnH0/lPIQrlk2hZ2EL5E/lvJZ2ZJcJ3qQJmQcTjItI8ofB7mVmz0ngZ+7z jD/TfUc9R6ACkuYsh/iLV6xRM4yc3bTPbDnv33yHyIpL/Zk2MWqonGxS7IyeSHu72D15Ggvx4i08 fx/Q+Llpso+VkKVkoJfocqvhLFvSS/KbL6i5U4PMc0MsB1PvRgI92D0kf+nqtswnT7yXu60PC2Rt wD06/FzWxRySIhM+ubCY4ipG0DHR3vbiuhQOQUys2r1Lh4uxftXtAnFqaDrbwhN1oxlNPfZNb2xJ evSTJ7+WUOyjT7znDBLMhjpyboXLz+AqmSs7oxlwAz50jjQmhPcgJJWD9rNAs+GcbY8ME4dMw9/l mTE85ucZ0nFuJE065RIH+Rs2tPMduUdbRDO00yzQNUzL4roFL1m2l0teDNgHb7/GHP7uKkzvQyH5 5QmBRFUDgyy3y3sKPnwS3ZaSkDY+3d897EXMfTYpLC1NchWpC4XMbKp3xwQJLQEtqxX2p36ptC25 tXHKnTGAXixZ/nVTH5qzjRc688tZ+qiGENzpDKs1sGgRKMKWrgla8XcOU2m9b6py1wdoUekw0/Vp 2c1U2/Ukqx3pyakWnhp91vO/NXo4YYQB0QH2Dl/Ii5MeZT8bKWzUjnrrSjWCrk3BBM+gtCdVXg+u BStoQ1dat+D9DyNNrAjq9bJUrRualiNyCRHnpcn9XkKL2gnaMEL5zzWCRoIJn4rFGp7zEKx4z1vF jp1iAQmXBdeVBBA/MyDJJ37/pqJULsIUzH6rUGNpcdx5v/HfGx89y7Wxj4bFJSOwKIl2qEF+qYGU 1HFShEvBRPk5peMUZ/LNwqX8Nv6kryCb6fwdROoOqKQwHJyXHme3Itab7AntXcpZokZiJ9NX5JaW qm1VqCv4d8ZJj1JaG9ftwrPEC8eVauSjpjMomSkF+WmeIhlpWLQnVZHKxv4b5P6eA//ENhKBXqTE H1hpvoOYpRZuzuVK2Tssx/wY0j/UMjw0/C4Ip8G/AqcOCYPKIaj0p9ZykcdGcGMSgqY7Ujy58HcO gSAqyqzvefrBq1Hr69bTB7jEA3bFIDeCYHtZxA/tQb3rFD6hH4l7qQallktLvD/0QBEbBIaHkLOS MOWF2g8AHec6VxZqF6xsunQEOZrPXnIr4VE4/ceKU1oqq12p/k9YKpTpNfQPOvuVYD87F5QVp5z/ 8L7wRjbwXhQRecBe/noQJRpB/rblIjAZTUUuLBx9M407z7ZAWeD/psWa0FhMnixINt/nwnNReJho ZEkpjqDRy+CdQZIvG7UZsxwGW55UR0mNcS9nZgEqoCTEGyD6uoxOvFpJkydERfmZfxoxJWPDIZqL VaaW4yKKjdyrcvbGYgbFFr9FNg6xoPmm10rYEtOYM9NbrlJRbnq/ovJV1pB4bOQvtl99JczteM/c bjnNhquiOvqE+8pROw6PA1/6j3/OqDsMsYOrAZ4HqUmX2rTYiLWmawypEmf7uIQDfWlC7x8G8YmX kznJXzZs3ntHouc1Es4bGERrqDWGyrf3dkXe8HGWtdiZecU7zgLzcxe7FByIjo+jW6BMoktKMuNF ZSKvgDvMMcuIuwt0KXq6H3JjO2BnuTGSBlbattl4bmFH3dhBbfjcRivpPMgnr/54rpHf12a1Qsis lfbUWNndVsfhPFdUdWsIkdSV2+kJb/P78k4JCvFru/b1IVClX83/7vT9VZmm5Af+TcCjQS0CcVxx rmIxaA3087adL7pEk/MvmPtnZwu/Emu/nJ2dNeAKavyy2dYyyCV1EazX1vdQd72bFjvdh3UU7v9T pFgLNxGKXcj3pnzDLzNTOeim3UcZSiXTfdbDuaA90ENPk82Em4V91yFqlzmxbZRSiPo+0tF4kUX0 1+UTvYKkEJ+8SgHu24Q3H3mKWW6y6yftwYJIxVelsWp/RUTXmYuV9oZRI0WgB0I+Xfyvt6ZEzahs 6/1G7NJSbHD8OvtsB3Ie0r+Of2ERK4i4x+xoVmLW130/r3AVPtZw2WAT1lcUZtH/qq2oUGptce3+ xUrTz7Audx5mLh+3qoRtUL46+K3+4Tv56A0LGSIMwdzHHnKZfMvWqZ9/rkjlB+gLH/kbXrXFdCwW gmCCx1iy2bxgjjkLlzpjIJrb2Nd/Ipjjohs5l7tf65x3Iyot4NKfXPydBqLcDVhKYwnCzQYjoSMr enfxgEiJzNDoUovt512iXEbz8TCIieUSSy6yJGG63hshukrm2H1l5j1PqTAiBfilHAP42wrhWAp4 KkDsw4dN5TOJfYRl3faoTwCR5OlarEy8YV1BQVPKPELqvYrc8ijeIApe9Glf42fEoKVaxVSfrJuR F8Q1p59Hhx2MU0O1dywq0aGTX3gI+WrEpqqj+1Mm9XlX4Zy0vCXqX3CfS3m/hlg6ZesqOE3nCXPv 6kA5v4nWNXD/6yaDITtMn9XqfQ5YPgK5qkA2NSo5W72Kz4WC70iOyo1jpKQGKDA38y+PVP0Eo72q QG4lT1Z8Np+lF35rXL2xuom9SXniObG5stkiJuWNj1lNYVqOKsqAhio/yRm5uqFkp74QwezCuavT 1ptsMLzeGkDv4jTgw0bSa6D0MvLXVALPoY/Sc9gVYCwEJHOxrRdW/N3ZJNvTI6GiV1aqstB7hGtF j+6HfI38cy9gtWjzTzLh6Z0w7ORRt/yNij8COBt9St9VqnVlocdHmH6yKDXdc5WbgE/NmJgJdLY4 xSRDYQoioseK4045r1Csj4NrayjqVr02fmBX3nmdV3Iuru/uLozPbc6iz56KykrfbjSo+LmZ6knb +Ekgmvi4MftZqCLtH6LZRiYR6kGKFVksA1CZJZy3ITqdg/33nImVcwpj0X6oKeQd6sAFv7ovU3LB soeu04s5aIBag2US9ZNZ8kUOvk5dwLnSRk5n963jdCAknoHThuvUa/mI31u/Ie0wFQJhLRDw0TXC ipadqln4+BG8pU/mdDII0ylB5s2nB9w0606I+iaFWyW044PRJC5vkzZV3q8RrHdC3dT049IFXufe 1lcbeJp+DfPdaPfnhGtTVftyryyZmtLDAQ9A9FLBXhVFfqYsUBqVf0V0pYG6lorXIcK+s/LHcOnV 5j/6aVpU0cVVYx3Pv9Ets5Z/vGZsnBpYA4JVqJQ1/B8wzYLzqKfbr2m5oVNC+QD075SJ/JPgk6dM BLGaZDVk9gvXyv9ZQcItrj3fPghmVODirNkky6p6dYvsXbiczw3w03L5pE9zQNZSr31Lw19S/ACP RAlWFV7hcx7p7hWyFsJlFiVz48OPtb6yKaDkSwOng5Mtpc5wH/YKnCriwrY1cuHAAj+yHNcynwkQ TAibKXqxCbhgZHR3qFsLkxwaqd0vX6ON/XqAoKxwRGKtIeV4LJYgGXMbN8f+nHJ/k9DynemOSeb+ bXa22g9Mg1VlCM4DVxSH3kGLq4hFOdTJCiHAB1c1e+ybkoLwFejzRaywCK8SeFOoQKbziAuAsVR5 YXEPc3I24c7pjv16ADp/D09X20TG8BTHqWhMavEqUXqq5V/iSuy8a3vpCh2WxWrl9AKYAt8cB5aO j1gUR7f7fhDwftqLWxG+6DrOXTN3fFDg5sJDHkAU4+XrK5VU4yT001T7VC4SKpXPz/OYayP5IlGN MHCHQzjhglCikOIDS6WljsDrHb5eSCUT1YmQKiEsvL7vt8PxRr2+OmC+EOXRc0mxDv+GSEsZMD53 IBQACK8fwXNUDxEiKjBPoblWtU2RFoO9ZAYhnOCJEnpfG1OpgbNXIXs5PR9ltIPBB7ntdItUTySM xcwYCGOLTIGwcRApVWrXavlZQvMtqGmFlw2EdorTNR3hfWc5B1FC67gTHmtFKx88CB5qSe5CkUyw RjW4Y901ngdvvowW3uVL7zMLEhvkivTxQiVVfUvr/OiBR4bJHxUBpXYCGFdDjtI9sQS5dObAiEhq mNpG3rEZNXTFQYurk0DF6wIWG07nudWftQQMeRSaqqSbYu5bGHGr8vPa6QxyzDFdd8YXOGLBkEf8 Lu219w4Ndnq/msgU2duaD4ZAml+24k8eBIJOs0QQe6yRNxHrs4Lw08XJfeEAQYPhDXuOy98jsb0b vIKrq+wkUyJlI/noBss5KQAWAfk9YXmh7ISCLrtKgJjKZ2E6s8/SM5xIUZDzT7TO8gfCWFTKYr27 yElhXcpvnkVhzDaaLkz+oXJO58c0mOuSh+7pG9eJvXrK1vKCiHcUCAqn8z1ZNd1o1aBvIQPxIOom adC6dPFVuWrkQ/2f8omFPT8NXviQf2N0ipblow+6FXWdC1wM+nZgCffPv9pXsjR1L/zVLQnaf+Yp C6wstE7nPmVjiyGqorBhTSDhGm18l9qmlTvVs696oRcXrLU+7lZ8iaRNgVyv4yJYUGVTva/rvrqG qOVb6OXyiqbIoAgYHVlqE6rMnLvo9qDi8Zyx9RBYHaXxxVNt+drELAHSAucstwWCDUZ0c6t5aql9 JwSTC5MdzRLBXigAy+pbYdw81a6xmf/tUu9tRQkMnWT6eg4fSkzgdzDDeePWV3sJ4nHES8yNwYn9 +dBeq8H1/A7k63ToOoH27gpw14KEIKucTmbxhI9LLwoQ8RaJsDESnrlRrq0a6PpQI1qAmJN+oPIj 0SkYFjypajjBzLJkcrmAj7dQbZnAX+gUoIIGMRTr7mFZVUEX9feLonGATbVH30GsWK5GSoClLWr4 66DA6aVi6PoFfq6VRtdo1T/15FFGynZZsDcu1PHjkYrMEpVpnA2iSxi1Hu91ctwbzPCkcjj00pnl LcMJdj4/5KSt+canWXY1JlAjvWV+4CHlHHkiWwCE9RuRovJ4c2RXPNIVcFIeC+5Nz4+QGEGuBbLI XrAxT0u2hj6HrQC5SZUB6rKFj5a4RQnwbkDm0hScPAG0yRQZXlKvQqWRbnl8HqrXPlpQJ2nSg9i+ KKYPCEdhDEc8sawmCHlHQE0yv1s3i2zqb6PvETZFr/kqeK4GRSoMYctxMs+uDl4OpftBUqRYkbMl gKzo4KOqo2wwzXf18bWr8jtEVU5vPJkTLY/SU+of3wxpcngH8NcZumqAd81ZWbz/Urs2kEBiTRD0 AktTPmsCNPqBTA+dhY8Sr4HKzY1/CbCLu0Wr9vdmbJKsq9qt+JHHoUGkGN+JJCNUrluQGkkRQOKk W/5mKrFcs0LTjfR2/YqODN6qqYZasebMdfEnG0w1FYuYMAtZqvZv9UcWff1r6+k9xHtamYOK5jvJ gzcym+0x108UsHxySQrobZGlQCNj4e5OgiQOthIL136X7gOeyDT8cmrEEKsXjbpcuPwBABQ8zkdl g/Ln0FTVZeKX16nRJDmysu0qOtsyk7lATZBSnK3/xkOdro7aKDBY9embDU0fg6krL0njnW/JnJkW peLx3HgXZOPZp0K2vC63JCkv0kPjTWpZiWBhnygNO+p3lMe5q0MuBvEcRBwanzMcx6wqmyD0+SAj hQLDrKFUxeR1NcTOPpX+kl4PkbgLZXczsv/oUDPE0Z5sECTJjn+GCoT95h3XiZBuh2wJSbv2PtJx fUIGu76U+0AWyXVB93EmPBqykllKd70I7cnS6BdBG5ERvIJYiNPRTytlmI48H/qvuZDjwU+En+Ud ytfOIUFvnRwhigD+/hZ3DigvQA3cHSBsIt7LYP3ys9dLFWuRNoMadyJK7vJITA1tL9AgwLlxeFQp AJP36974BjoU9XgPMwxm44VMI0O+wpyfmPAP8XLEoF5/1f2ajYfkcL5N4Is2wINBTJ17ndNSewWU 3hvU3rMm5bZKlRtDPOxzJpdhVneqjS/+PctOEqRrtLenLWtFs8tL9Ao5IL+h4Rbog7P1Vz1bOqgw sTshLOoXXhyowR+BV4QpDcpFUv66Z1moPW33W3GEfUxKt9ON0+mA1ZObXKQFG9Z83obheg7Mx1lH iC5qQogq5ekh+KeOsk64lu0I35wrRnvYyJ1g3cC0S8wGX1T4DVO8efCamRVXgbx7AVBu39iXdS7M eS1h5PGkXJ9QcizyNeDrkGBf8YIK9SuhTd2509Y36xTWZiBMC8XGOyFHLkozGMb6zRuLTaOlRlHT 878RDZXD09OI+Qhy39BYSn4R5FDXr6zoiVwOmX+3CpXnY2N1QYhqtu5JBdvAirJMl2QTBpHpsJwk G4LBTRMbgKHmfh47POFCAr++09IbfpWl3oDAUCo/FiXrfViMkxRfWurlSOL25/BnCmcXelCPqy4t Wmqdc6usynRv72XKt0ENm8ZTBTuOo5QUgZpvVljBbsi1WPa8YMuW+zayd3uzdTC8YjU3WRcG0hAQ XlVUVl89+r2BCRsW7hAaXyRP3KVQhV3xAFYi3OFJKv53VQpalCwr1tMtkx/CWycNenfiOCPrEIDJ DW9Ef/LHywmGQZUKdTMQwvee/nG7R7WUTl/0FeezjbO2C13/QihgfpHeqxYmk6r4Bckp6gVpy4tI piklgu2WMswaI43tINuVhUEuDxp6iS/5looU0Yn8vOxGPzjxWUoJUCYcbji/U+hZkXVnw6Ps77y5 U+0Bx+MpYTJG9Qsor71DWWtX9OC691fKTJkdiXLGEiKi2oXTQIqB7TdOelJRwh/9tpvQoZEZ7VJ9 r+pb4q15cJGu/dYarehbQRyvykh0KkQlwyaf0Fnkh1qVSBDW+vPBFWymlVAmgk2FwETkUjC3spbt d6mQZ8xImlCzkwqNmw4mfyFka/v70I0Fb6p9po4pKho6ZNXnC4CX9ASO94E4GhfIAEtLZvnmoB0j 5Li0xBc3IqXmeiv5u4BDj9ztM64NtXKoi6/ryTxQmvhOfHyzgKaCy7YIXSKFFffWa2pR46mgl1PK Xq4PU5uiFdXXYIdT63Q60SHagZQ7xwtWtEwtufoKygXZ1ThRGkzzyKQZJttQA1kEiWE1VwfYv+A/ LzKfwHUoEwKDidbgR2UR1kg+mmzdNVqzCLjS4wbhL2rNGZdFOi8+vMIvKEei6aJUloTk7tKCZFae wyKfZlk9Xyoc0jUkafOT4Ew+42izKfFf0ssgOJXtNbxb1GfQq29XD8VqRfNzeA3DibXS3FYf9nBo Sa/2EayM3koLHfL70Pjzj5bQ0XxtCZi9ClU/VpVmJ1pNIPe4RWn/dRIrdBmsqfNNuZvDuQQf+yOm Zq4bfEPgvGkNCJX/KW86NQWbTzuQ5qPd9Zmg6bDKh4an4FtZLbLPOGxrOrerSLMRYtDlhXXpE9IA 0wrVDERRofVcyO3kbRz1FN7Z6ZUMM1o1WXR3Mf09lHZg9yuOLxK7yDMXKgoTWroYGAf7hTdiuXGf Syta0NQNKc2Wowel4e1fBO9orGnZRFOaOPOGKhUyi5EZGAm/tCMatynBAouH/rj3jS8e/5dEZn5R IoejApE0iwKSaV0aPLYQ94jyjfMV75Sw8NJZHug3+A4zl5aPwjV5iQxxhYQH7LvfvQWwH8BpguAG eAv3FLOqOMms3ibnOL9F/C4hpIH1WQJ8V3xug6UOvf1uc6HwCaYb/+FOg3fTNTWBMLdBLvQ4c6nz 5xMXuIhas2d3QlHWs5+FBJ9+Yblo8pkgy5oYKlghoBokmnr1IbS8KIgY1nsPQTlpSzzWSfypmCpw kZMAdlvjdVyAu62jAkFhSdSzr2KRp6gC6fxJZcd9roShTGqJVuAwjL9QU6IMrMBzAYrsbk5GNC+k km3WY0S1FuRoHmt4e0Q0lJbcjS2+DQP6qLIDPRKyygwwkmbZKcdLTMUrkQFfFWqfsORXgltGY65S mmrVKSvCtCzURcssOCUS161kc3ONFb2ixZfJ9umo6QmFnRGCOQ68sWGLLQhfKl/0IvGrd7a6hfbg IsZW+e1FZe26Kn9QiC/zmXIipYyCgUGZKn9RMi0qt2omwUvC3YCxLabvwg3X2baqLLpeZUPfIZLk IEUWYG5fCwY/wKvQniejnVJr1UyiMsW6fqn7iJJio4p+mchWn1YX+VLuWh3kexHiINe1z3uBGY5N PdEqk33VIIPqShByruW3M1FD30JG5bzafBXRec3G655JFH4TTwsl6dJPkSBoYLyiA4KuUgY3F3Ju F2CBtV23iK0eUxTMhkC5TIxZT+TDVDMjz5MxlJwltuFH+Am0mJmBy06KOBp872D7O9RpL1D15P2j qKI+SUrRcwNBjvFrWC2onMbJKyc1KCJp24h0crlsgAPtpNhwq4nMUuQ3+lAVL68B4bccG5Vm7UBT 4V759uDWuinZGlgGeHpzm23nnuMtk2y6ZpuTjnYyGoCXvFpcThl+fEC0j8QlwuKUhqOmLoZK852z J4I/pB/YHujEE5csCWNIMT6DSYRwnka8u/4wP1skTcCeT6P69gVWPJanWj0YhAF8J1a09QLiULue 6U63uA197IcbwZ5U9WX4ckgEsx3WUy7hs69gZsNVJ5lJz2IFb4uy+fx8L1c5uSq/gGNp6zAcN0jV 7fi6HrJ1VWCVpXnH1RFgbWQi8yBa7uAkgJ3eU7lnuYJOFPEmPrA/+TZKX1zHsiqc6Bjdzi1KTbGh xujd44pfrPX10TlQlrdDfson3tGxBTQdnCv/HkWIzjqI4wUDT2Cx5um9285YVIZAOv5RY0tq6ocL YMKzJdgbpIKPWwRNgl+OZtb0AFo8bH+RouwqzZ9EQt6Gux0RSSp07S8YOPLMJsQZle/QjUzb4p88 T0uHe8aSHJliph76lrL/qh9WuVjWKPD0HUccD/o4AB5hJ6y55IZZtWF4G8HjPby+0fI6popSvG3V P8sxvQ0FG/KbS/j0e9JDAvXD6JrfylLjdpHsI0a8SDPYvq6VqxjmsWvitH9TvbTzcHnXmcGMHtRF Sf0b3/PjjV3+xI7XEDJWHjK3QV5LLrqBMOVKjcPYworaG2PDEFTatnMGvkde1AJomnJrAcktEoJK 7N92J7JgzIeHnVqLcpYWh0l5vsPIsdqTud1MjpG1oYnpuv4793q1ECPiitct2O8gfWfXTqiLRQsX SfNLo2KOLHBrjTHRxvWbgoP39Glc2t06/itqUxGvXZnDNGJdeB8Yj7vEwHYO9P23MGkDSXi6Rlsx mHVjQ50CXEP5QqggIlpiBxRbVJxqxvYv2I0Cj1yUHzE/uSFuEp9egxcj9Kc94yVLpAhcl3nr2Gz5 LkVVxIcf15+eWtgOHqEfyA1yARoSfxqPBHTzN4noaoAqTDsblgArDyRYByqPYCR+ur5CuMjt0WaR gKM0BcMa2hN8HXziPfsJpo6MJ3YYwwuUK1IRMboQ2EjO0huWmyfdRkCvlSgzXYQfHIpvLZRkLl2x z0qPE288DNgJxsA4HZ+RD9TCzW5iah7IHh52nh2SM6LwH9JllLy8u0nCsoI1h/Yl9lFFIP6Rs2Ej op2g67h9kbeLLQPxpgQjoRQmVl2tfOMbCcZqvBuZtj+wmMVk/hMWMwfH40N+ccYvayRiDWXsfIzr kJgs5BwtBm1kS08Sh7WQBots8ar5YAsXEgevIJSjINSjkKIAvjNyfIbWcCgZKa3RF+MwgF+IGp4D VNfZyiGkmpYt5DB5l45HeJN5BF9cPxKkK4u2Tg79WWlaXjT/M5+5q+5HVXzKkjZ/FQ+gRQ/2g6oK 4mVr2KFLkuSlmW+jECDL9owRnwxoE0ov6FWy4IsRHOm+mYog7+3vuKETdxb00oJlx4X3Ze65Csqh +PBc9y5XKr6V93IbiHp0Qk6vuTDULcxqvJUScOpmjt3sCFRtyeTOIkdcwHt1DStLEVuXZNt+IKI5 IJopDf9CZm9vf9PFaIM5evjaeQ09Enw3m5lXmbqHlpCU2YONj1CRoZJyGUkmpyDdIH5iygt4jisU FHpqAqo8pTWtcrw2Lo/Upjx63m/RUUN45TZJltEXqa5/0Sk6YCsVkcUTbYGI/OkYMGDB3pEPB6pQ W091F5LLT0yPnN0YyTz+3o2e4u8gfE0zk052Q3jaC3l6NcvUuIjL0NGkSipkl4eNOJp+rtI/xaYl yYoVEYb6uugUrQnDyPtuWJK43ys0HCd6+DbJFyxQV0VLRgfS853qBPjDggMm6q6VXICOBrv1UMTs 3lYUWp0tBoPrVNllYoN2ARpN+whX3YjRPxxEybfpGjWEUBpawPMI6fE0hwR26RiVwbhrQWv6wflB boNX3HbIbPHCIVzCGxs7Bo1sKxo9LDv5lEw+b3ySbTRnzxZHSYFkzhB0CCVgY+kX+2c9P19VB+mX xkGlLQm0A9gtJBYROoIhCUzrkBLoob/OqGC3lAu/exI8Jlu0nmUWcAlAfrEAJY/STl4e/RfhZeUr mcRszj3En2FLdMSymiWMvjGTrZU3GN2y/7c43BxNSshOd2jHd6g4rhclGYxOn8eNF3I5kwBGbCFw mJs2erTo6xvmVI+6UUjkcaYvu24AHN9fK3oTvbBZVID+dEc6Ve4E7zra1ukE/k3v6Joz8TgWfTTK qlr/hvM6SwH/0qlCNqOPN68mPjFZKJBxWUf5rGNtFJ6O/svs5HR59SbLSmBtTpCMmOCufwTglaow 9jFeI3eqOrYJamHXw46gSruYQyxucGKyS4/gJaYukz+Czxtx8t9acRqNPzU8Ost03eJtxvG1xCrh wmGjfE3doi7diSKkUi0TpgEf1accXyQ4vh+9mSLJmV4Gh9tBrhG7+uCjb2FwE2PIngzHzhuzUdYv V3hwBK5G8Pd9YBAlHHblu9nlh+IbXLDg1w1hRClfIOsjsxq71borAsbd3ZiPbfJkk9WqrQkoGCIv k+aOtG+WlZLIhSiGD2+MllGKMbD8vjQcUw/UPsiEYvnipY+aZg2uScMnRFDwlkOocKKw2dpJTvmp 8Q8o49CmUmQs8xiGAtEt8F5mTUXbCiKD5YVVS5idC5HDcD7nRrnLLn+FdXHK/GN/mzK9KYp/CUGm kYI9xIRitWCaa4fSNQQUJwsCGSQ1oJTEwWUdczjiLkuxwx/kmOCSPkW+VuD+DyVYlRDhPKXbwvHR XQxAv0pkaVa6b1R26Y1J9GmtsSvwrOMN0tvd1fEZxSRX4IyVXqBJsim2yEC2U9fA3c3HdyohSVXg +CjgZj4G2WKNpImD8RfB8hxxDokmixFYNJ8qTEH3YtPJ14p/2IGyZ65DgPwaD+80PlGNtevcYg2x IERtITWeXdq/2GlKQjLjSFgI2cyuPrYp5JVerDo+BmWcW3wuGiPIbMOqKxuhBlAUQcUnlMu5rGuM MnlzS8nOmOy6pi8d3/BgXOBlS9Sh9PxvQr+XktdNVaxwmx8DiB+CxPZ405jZ0/XmFUjRBzXG8Vc1 A0CvXJ1OdXPc+wUbvftv+3EPH/tK8TdofUlQmLJulIQ7zd1syr32NuF5iN3giifp1Bgrob8IIqT9 fOkxUywL+Ysn7DJ54ovEVzkuCAv0uSe9k9GqVxyXmWwsGS0VKpmzY+LAs8SpXHb7ylpG97dfW63h oifowBMSSNIeHXEiiQ3CD+ocOWRJ20FG/xXkIv0NVdn69fgwPRToAjHjcT0TwJCmjkcIU349O9vP MTIOFKYAp6Ypx2Bp+WdAMVB4dQOQ3MhvDsodzcpuNDl+dpS8e569+8w5SU2AHcCdwWDUIZjtPDxA IBDOnRXKy+suwgPwEEKwetjgHrUffjX1EOGB8pAAiXJ6KioqB4yu/VMAW0AEW8rfXysLv7ZSdrY/ vR/voZWW7LwaPhbWNTXQndsz21ML4APZWDuA+IwAF5xMzB1MmV1OnjjB6DpkmLq44E5aWHgx21q5 OJiDTU2On5pxyaPkNBVk1Jth+wxlOfkTAE+AckBcAAB5XsicYZxMVj9+XXUqr+BG/ujIeHlR0RFg iJFXxOjr7v0w1/9urRHIxsN6guAOO+5/Bg5fn/67vPpq4+/u+srvm4BbHQ0VT7sKGzqeTQNajxlO nrW/EEOODbe7cPZCPCkBDhBQllfjUZGTZCEAuiI+M4zFoCo8ggghbozYpm5cmJahtrgWo+uAgURi NbR4TwHiTnh4Btha2tuGyAFM/KLwZ33MGDMMRlT0WTs8G0BSgotPlQsCAsP42YMA925dflh8tZLj uNtrBTlN164VdqW+3AOgIBISnBwQZRC/Ulh6DKPl0lZEbGxUzlkHdi+fnILHt28nP2j5s8VgvMis rq7LaxkDiCsby8lJCUtyodCsurYX7jPRGQ7nQ/yDI077EaPY5I7FMwap833UnspbabSenoeAF3kV ZQUV7VcqSgvadgHygv84QGApGAjMKxsIMGBnklBiFtZhYoGycaEhQC6wxFmAUNIug4GS12BVwXJq YjTkVTHS3JIK0lIa6v429qfMgxmMM3umdmY25mxu4Yn25HBiIjugMaswq+Tu1az8EkYvI2Nx6EKg X2ygeWh4oN1EVOg5Ig4EOP4TQ45ZQB0K4FUASUEhANyDqym5twuyU+5lXL36T62C3LS6JcCPyYlP IytvPwz//bj3dvxDO+BJceqd9OvXijOsj3kyOotLM7cAfvbW7mcJBHNLBUC8yykcyeQR9p8EAH2w 983a4OLr1yPdNQBG98ynWerA8sDA4Kt7gDvXU9P/8WQUVjypqLhV/Cx7FSAmqWtspCDLqausbA1o zSy8llz4/HhmtKaA8p9tAIY3Pq/Q1lY/HwykA2qLy89nFLesJe2/TEstvkwyi/YLjPJz8gsNHArm uFPKmCSAtcFigopiAsJC7GK41ocMhmVibGJ8cKJFYkz82ShSSKKoIHEtmvij9WjmRDCLCRDwue8j bSWa9mPqV0M3qXo1SQrLoq6hISWHFXSy09R8yOjqKPQITfD1PX8p9EyCT1gomcwNuK9z0LXKyL6Z //xGZm5+eXn9j9YMyo26rPISSmbm5vzcIUfdkzu3W++UPmC92wdwCTwdfJG4Fc5gnEoiRZvF+UVf IMEAFqGX3BzJgT6+VrF2NnF0xsxG/OyHNxP9b3cm5qZm3yZriogxGEKuHwSdWYEwQWwU4EZbS3NG U23b7bqnrUcqh03vAbfL8t6U1lxNrUxPK7q6NgtDHPvVekQECmPnRIgkAZyDIki+EafIFyOcBAA8 6pLdrXJHMGM9dRZjzKo+FMzZeiOxhtswBGBKTOpPio/yw0cWHOsY4EsKcAoPPz4PhUWoY0+dN4gK DieVHRWcOTqc7x2jzs3R++fnPlz3M/E66WJqesToFcKQXawIb9ZG33f395SUfhl5/26iTqika8Yx IfaCjKxHxDlf1wDHCAbjF4dSVLxbDOhkYmS8twSAtvF1Z/boy58f2kf/JkQ+4NXy7vDS5+WR3V3G 0p+d3eWjkYIYVdTaMY0VI4NS1eExkFXVQunJYvhPAxou37qbW3br0fXr/mlyjQF08BWBUoZHhvMd +2avmPMXQmNjohMaN50/x4RZX+1POuvWsc7gYIQbfR6fHvg61fNp4xmgsKQl60pRbd7lrKOkmZ2G tCtZNZtWH0PibMMjE+POn3eIi4hkCLFfFfT/Jo0w0kQbagirGn/6ymjVZIGdBEx+2Vj9utG3cXA0 sAvd5O/sOCwE+Nhb4EBOpx2ZrfBBMtw+aVuiySahpp4ObGkB83ML86lEaxuCr51ttSTgjK9VgE/I UdfUjqd/gF9cqL2wvoKYIgajr6ogom19wJhnMVRQw8hKeAOelmVdflJ5o6hlW9jz2A9MOfae1qdd LS09vc56WtmcttUFzO4sMzZo4QxOxuIRbXl/6feyREbt3frHtRmPmsCt9be7jv1Xm9wDaClNv1FY +vLmk5sVmck3K9fjbjcX1j/45/im+7cv36uuf3b/TvOj+nuZQ4COvPKXyZlXknNT83IflBQItXRu 5FWWZ52qz0otD/v9/JLV8QqQEWISFHbOlRwPBgzsff7+bZ3RF/CdwSg92lr9XgzYm4ZPvfkw+Wps d+r19Bxt8nX/QQdgK6OrR8KwXEtZTUFbS0ULw6U72UqAHenqaRgKu+oMsa5/DT3I4KAvj2uduuBz gnzpxyBj60yND9k9+uKF0/y7OWUZddfTrlKutTPqGIzN94Nrn+bn38y+O5qZff+36euPnemvf76/ /nKSibG1u7iTP975vOhx09P3N35wPOXyC7IVUVVTCkJaz8efBQVGXXALivOKCpd2Od4orPU+v5ta HHzX8+rr5Dzr1vB6M+DbxJvvG0l0xkT34tvpnom1kc2nK9RXv3t656jfqFNCe0qdxkEOjvH9HokO NiStUK/wjn4PS2fb0xGmF3UitDSEWhP5GFrGWrJacC2FBVx0rFM0WSOacBQ+u3eBHBB9UolHxltN RlJbBiyjx4Rv/cVo5ax98iL9zsvWJ3fvJr/s4phyNzNjMJLoJt4ejjgv3Ak7G7sEqxPedqGKgPqC tIrymx0eD7s2M1Pzs+qTbyVn5F9uuH94uLW19fFT96eaT2MTDe97BqGjqxND78nVSo1s/WWDzbur 4/Q/Hd0MjpDRlUX61o+vq7/oK+el+ZgYSftdTAIgZgkmbiwfiwAbK5Mwsy4QzsccA0i/d+94LooE F1WlP6jOf9DwpKH2XkNXVUlD9QBLp0BwZStTJqU0f14wMW+rOrkkky0tt/R2ae721/k9RmtsYCDe N4gJUHY7q7Gj7VnqdG1NW51Kh/l+/bWnt5vY4jprJrTklNS09xgMDSMDeR0IVktHHS7tBfg1O/z6 4/CRyOjwVlcP49OnP5/2Pw3P/nnEceNyRlv9ndyM3Pl+6UT69ftoSTEwyAghysxghD9FYWqhUkgD BYSCoa4MRoFNGaUopWAf/eCQlfNcQqivNcj4UsJe0pMnehf3zu4AlTBaqkrKPElprfNkDUWULO7c yMDIz72RmfnuVwtJZ9NG7p3AOFzyifOOCHM4B0+qCXcHK+iDFKL1ZREyivb68zsMtvauh+11i/VV VSOAuc3fEj82do5WVQ5nlpeZbgBsgshEN97QsPh4s8Bzq44eD7+wvVNX1RWFLbCKdpzk0RIw1mvj 0bxtAAxMBSb4E7e6lDw/o8+fZP+lqIbUVkSq8auyeq/E5Klqqv1VZAZEuNgeMFpbvFyI8a4uzi4O 7q6nHfCeYdan45Y9GF1Fzx533nvW+bjs3ou2Ro3W8hlA669f8wpXKnOuVV5pZ2q7eg1cxnWrPsMj bOZKOct+tbgEk/jRPZNLKcbp4moR74S/fmF0nZz5Mv19fbf36/67UkDJkwcvHha6L7AmPSh40fny evOLeY44Noa1pwkxruJ0/MWAKO/YuEhS+HhZIyBTfDBvJHOqt6v78uWbC6/eb070vPvwdWOLtesg 3sE2zCPSxj2ywyrOZsAcdW7ViN7DKDjqcv6RkV42+fFjCyA18+rR07vVVXVvAU5HSkcMi1OO9gaA t5MfqF8+TU+P/bWycDPHebtpndzh5MDbmFgoRSWJcDC0j6Qv3rn/4EHVnSfb+NPeTqoAIzWs8vyL J2s6ylijl/LPtZTMUApYRZXxo1Zz6cbqOy9aOl/UVbs7zY6tc2S27h1t7fyYFWuof3EhOZvBUDm4 0pmTczUnbGq8t3vt2+L2/2nn2oOaOrP4CQ8Di7wWimXxwc44Lbu6tAVX25F1QchGW6SMUmV2OkIq UYGEOEkuCAjEuUAhIYoPQEGBMvwhDjDarkUb1NBWBWQV6gubVIQCG96PAOGZu+cmgDzif92Z7kzP zMl3v/P7zvnO+e5N7v0yc3+dd0c7+3Qk3FaUWerNqIpCefoFhTy15oIGOlq1H6g9jxxXezfd3aTV 2dY32VTpbcpqGh/df/qw9Yezjc/8rN3WVI/arlvjpdjq5pGwf3SXS9Xk3bDAgcNrYf1Od5dwZVqs bN/Va22JZdlpuZ5XpVKPXDKVrJ1J+7BPerpTf70/95QsNUPi/Oc3PMq0ImeGhGcWCLId+59nNZFX mkIf/VU13ShyWG/+/o6Uzbue2YbYRJjzxJKmgOMV9VvM1ZKK9kZfcLb3fTOg1nz9JaVLgAN1v1Ma WqtksLlifwGfzymfYutjIgIjY7h+uwQRBI+7w4nnOPBCvy5YKDjgFxEh5IpE9oECzsbPhBzhJtWY In7NbjHvk5i4rREh3Pax/r6psDAWx9lPeOhd7tFIsWWSLq/qnUgRVxR5KIbDY4qFBw4L/agOV04w K5BhaaCoiG2nwu3m+SnOghlzS+I3na6/d/jjFV+bVblrNocyvC18BlfWrYjtXLvJgblCrfE+ZNYY 8HL0U2uedl+2p5h7VDxyJvv2p83NTIuP3MM9PxOJVJbDPiuvSGyVm8/dmPCM4Ig5GXbAPPf2+YK/ rfKN9NBOuWxbFXvp7XChqBT2brZ2cnK7/DFA3JgbnLA2clyAL1J3GCT81htKX5Df6vmYovaR/6Z6 HLINIl3xjwwmm6EimLK1ZP+0o0rYd53mzlhgcVQyVKIBwnp2gKj9vTpSYy60rXlphd7kICUWZ95Z OL5uUYdw91sCLgpG1pgdnwEtRZFNDLnzO+TMdKy91Gw7JrWT0HUdwFt3tsyM/NYik0nesyC7LOKG GA+7AtG8P1N3g4epSpnsjRofRpxO8nczYljGlIZZHKzRWNUoHdK//9O4pEfDGKR9LTOa257LbyGJ CMiYSNbgIwuzkKe+G2HNAIY2mLxnReUW43EOhrNSitWZE/t2DFd+QuWWohGHMzPNye8selqp3HI0 yCov4SdGG6QoBU3TERwSZbFnH/VE/nkRpiRxT5GEe6SEBocE08ZQjjxgvSQKPviemCR7JV037GhG lV+/NPdmGDlGkICE5oJxx8rs6GsJW9r6Csc1xP77JuyuSMBCU5SUIvfIJavFNS/05yJ09DX+2YgF Ix+L8wL3YjyPHsacDJw0DJgNPk/4YjDOE8HQGzZp2hlDBE2HBr4u+wqO8xIhN0kKJ/kJoCj4AiqS SKjOy4fn92rhZnom3BYIoEYshm/j4qA2KwvqTp6ExpwcqMvOhsa8PPihoACaULubmmBArYahlhYY 1WhgUquFKZ0OOhvqQfOgAQY7f4bBjlZs22Cg4yX0t7dA388voK9NDb2tP0Jvmwr1R+hpfQ7dLU+g ++Uz1KfQ3doMXS2PUR/B+fNnICGBAKk0DaKjD0FiYhzweJGQn58LSUkJcOxYPCgUVaBSPYObN7+B 6uobwOdHw/T0BExNjUNfXzc0NNTBxYsFIJfLYGZmCrFJHKuAyspySElJhuTkJBAIYpDvRw96/QwM aztgaLgd207QjnRBR6ca2jtU0NhUC6NjvTAy2oP2bnj67AH2+6Dq+hUY0w3gcT/EJ4hgeOQ/aLsK uvEhtA9iX4N2fMUIY9XfvwMTkyMwPqFFfBjxIYiKPog4AYrqKpicGkN8FO7VKSHx2FGYmh5Hmw5U 6mbg8aPgGNaciDVnyaVQjfWWV1yGCxfzYUaPdc1Mwn2slYgVY38akrE2PdY0gzX99OIn2NmggtXK J2B37SHYVdaBfWU9+NQ8BZ/y2/Dh7cewquQmbLxSDweqHwIU1oDr2euwofQOeOd9BSGnSoBdooT9 JV/DnhPF8J60DILPfQmRxf8CXzz+5+nLEJaaB9KSL8HvcDrEkdlwreYBVF7/Dlrw+igqKoKTeB2l pKTAkSNHcL0FeD6jf/0/Br9lmGyQ166D04agoNBQwTZaTI2i8aC9BgnlJtOjFody3BDkFeXlFYV4 ZCSfH8rlLo7i+Jc5970Io7CW4V7ovgXdjfAy3Dj5PLwUf2sWnnN/HT4bfVn8t/aEhS6Ibgr39tpG ENsIfzabhbIkf3p+unI+fzs7njCFG70D2Gw/2t2Ev8GbZLMJIpk0gW9BbyLeOLkJf+PkbJycSPY3 hc9Xbtp/CbwsPz6Pt312apPz83lsf4LAxE3n587fiid1gSxZP3d+AEEQAa8GLMMXeS9bH3ezL1gr i1evfpPFcjOV39rC7HWFpyxdCwtYK/JdC89aLI7vYmt/0s7ugpW9bZ6T02lrl3MXF+M5n2fm5MjS cnLOS4tsspi/yzXejF8J3lkhHTU1HeQnAF8z+6WE/v+HFj2ToqZhHSrQmvI/VEp/cOfctNSOLroS +hnJHR9XGMhJRz8JzTHUGausxuebYtSFUkdz0C2xzeGP0d6GOoxq9gejH75xbWg/Yu0OYgV6e3kG BAaC/+4QbAyHyKgn4OC+iN72xCOtG+6XFuyIAPZGCsUEh4c2MfeAGICFmx96AG6X0JfeCv1SZ+S3 OP8PK4AXq0EMLc2VWIpK8xI24Beon+r/L1BLAQIUABQAAAAIAAAAAABB6RAJhUgAACRSAAAMAAAA AAAAAAAAAAAAAAAAAABmaWxlLmxvZy5leGVQSwUGAAAAAAEAAQA6AAAAr0gAAAAA -------------C39DEE2455027E8A-- From ospf-bounces@ietf.org Mon Nov 27 17:12:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Googo-0003TV-71; Mon, 27 Nov 2006 17:11:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Googm-0003TI-NK for ospf@ietf.org; Mon, 27 Nov 2006 17:11:00 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Googl-00009Z-BL for ospf@ietf.org; Mon, 27 Nov 2006 17:11:00 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 27 Nov 2006 14:10:58 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kARMAwVT007063; Mon, 27 Nov 2006 17:10:58 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kARMAvDM013226; Mon, 27 Nov 2006 17:10:57 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 17:10:57 -0500 Received: from [10.82.224.37] ([10.82.224.37]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 17:10:57 -0500 Message-ID: <456B6270.3080203@cisco.com> Date: Mon, 27 Nov 2006 17:10:56 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: abhayds@acm.org Subject: Re: [OSPF] Extensions to OSPF for Advertising Optional Router Capabilities References: <4552E2C4.8090903@acm.org> In-Reply-To: <4552E2C4.8090903@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2006 22:10:57.0436 (UTC) FILETIME=[E9F875C0:01C71270] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2434; t=1164665458; x=1165529458; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20[OSPF]=20Extensions=20to=20OSPF=20for=20Advertising=2 0Optional=20Router=09Capabilities |Sender:=20 |To:=20abhayds@acm.org; bh=iKNhni2+aa3HnY9n72DiVsZ7q7KGYRvNFUPeNPGkUpM=; b=LzoippOQk5AZB2y0xCqkIutSE6NuCgTO0e8WtCG655zu5TKLkM9IiV6uoij4mLt4h8sUU21J GXiFO/zU/P0h0UfFS6DUFFcTYUpar4pUmVzcb/BpubLOJ8+DRr5sNrHl; Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Abhay, Abhay D.S wrote: > > hi acee, and other neighbors in the AS, > > 5. Flooding Scope of the Router Information LSA > > The flooding scope for a Router Information LSA is determined by the > LSA type. For OSPFv2, type 9 (link-scoped), type 10 (area-scoped), > or a type 11 (AS-scoped) opaque LSA may be flooded. For OSPFv3, the > S1 and S2 bits in the LSA type determine flooding scope. If AS wide > flooding scope is chosen, the originating router should also > advertise area scoped LSA(s) into any attached NSSA area(s). An OSPF > router MAY advertise different capabilities when both NSSA area > scoped LSA(s) and an AS scoped LSA are advertised. This allows > functional capabilities to be limited in scope. For example, a > router may be an area border router but only support traffic > engineering (TE) in a subset of its attached areas. > > *The choice of flooding scope is made by the advertising router and is > a matter of local policy. > *This specification, takes OSPFv2 to new levels of intelligence. > Flooding scope MAY also be policed. Such as only a subset of > capabilities to be > advertised from capability subset in each scope. > > Such as when a router becomes ASBR, ABR or just an Internal Area > Router, GR capable > Overloaded, busy for example (if you receive a busy bit) (add to > capability set ?). Busy and Free > capability might be used by CSPF. ( You might have just edited the > new specification for the TE Addresses > for all OSPF interfaces). You might read the relation. > > You might want to add a section, IMPACT: Where in you might add > the impact > Action: Router shall perform only those actions upon reception of > these capability information Since the draft defines a generic mechanism for advertising router capabilities and the action an OSPF router would take is specific to a capability, I don't think this is necessary. Note that all the bits in the OSPF Router Informational Capabilities TLV are informational and no explicit action is necessary. Thanks, Acee > > Any comments , > - Abhay > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 27 20:55:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosAp-00051d-3o; Mon, 27 Nov 2006 20:54:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosAn-00051Q-Rk for ospf@ietf.org; Mon, 27 Nov 2006 20:54:13 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GosAl-0008P8-3H for ospf@ietf.org; Mon, 27 Nov 2006 20:54:13 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9F00LEO3WRWW@szxga03-in.huawei.com> for ospf@ietf.org; Tue, 28 Nov 2006 09:53:15 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9F0001N3WQUB@szxga03-in.huawei.com> for ospf@ietf.org; Tue, 28 Nov 2006 09:53:15 +0800 (CST) Received: from [127.0.0.1] ([10.111.34.76]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9F00BKD3WBKK@szxml03-in.huawei.com> for ospf@ietf.org; Tue, 28 Nov 2006 09:53:13 +0800 (CST) Date: Tue, 28 Nov 2006 09:52:59 +0800 From: "Abhay D.S" Subject: Re: [OSPF] Extensions to OSPF for Advertising Optional Router Capabilities In-reply-to: <456B6270.3080203@cisco.com> To: Acee Lindem Message-id: <456B967B.5040107@acm.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_qXQ76EAuhUKYQJ3rvJwh0A)" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) References: <4552E2C4.8090903@acm.org> <456B6270.3080203@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: abhayds@acm.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_qXQ76EAuhUKYQJ3rvJwh0A) Content-type: multipart/alternative; boundary="Boundary_(ID_GDOoAGPDKBeHPDXqb3pWEA)" --Boundary_(ID_GDOoAGPDKBeHPDXqb3pWEA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT hi acee, Thanks . Im curious about the ACTIONS one might take upon receiving these BITS. This draft's useful since its specification lies at the intersection of all OSPFv2 protocol enhancements and possible problem solvers (which may arise due to _known_ software and hardware limitations ). As it is informational there is also some C++ here. --Abhay Acee Lindem wrote: > Hi Abhay, > > Abhay D.S wrote: >> >> hi acee, and other neighbors in the AS, >> >> 5. Flooding Scope of the Router Information LSA >> >> The flooding scope for a Router Information LSA is determined by the >> LSA type. For OSPFv2, type 9 (link-scoped), type 10 (area-scoped), >> or a type 11 (AS-scoped) opaque LSA may be flooded. For OSPFv3, the >> S1 and S2 bits in the LSA type determine flooding scope. If AS wide >> flooding scope is chosen, the originating router should also >> advertise area scoped LSA(s) into any attached NSSA area(s). An OSPF >> router MAY advertise different capabilities when both NSSA area >> scoped LSA(s) and an AS scoped LSA are advertised. This allows >> functional capabilities to be limited in scope. For example, a >> router may be an area border router but only support traffic >> engineering (TE) in a subset of its attached areas. >> >> *The choice of flooding scope is made by the advertising router and is >> a matter of local policy. >> *This specification, takes OSPFv2 to new levels of intelligence. >> Flooding scope MAY also be policed. Such as only a subset of >> capabilities to be >> advertised from capability subset in each scope. >> >> Such as when a router becomes ASBR, ABR or just an Internal Area >> Router, GR capable >> Overloaded, busy for example (if you receive a busy bit) (add to >> capability set ?). Busy and Free >> capability might be used by CSPF. ( You might have just edited the >> new specification for the TE Addresses >> for all OSPF interfaces). You might read the relation. >> >> You might want to add a section, IMPACT: Where in you might add >> the impact >> Action: Router shall perform only those actions upon reception of >> these capability information > Since the draft defines a generic mechanism for advertising router > capabilities and > the action an OSPF router would take is specific to a capability, I > don't think this is > necessary. Note that all the bits in the OSPF Router Informational > Capabilities TLV > are informational and no explicit action is necessary. > > Thanks, > Acee >> >> Any comments , >> - Abhay >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf >> > > --Boundary_(ID_GDOoAGPDKBeHPDXqb3pWEA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT hi acee,
Thanks .  Im curious about the ACTIONS one might take upon
receiving these BITS.

This draft's useful  since its specification lies at  the intersection of all OSPFv2 protocol
enhancements and possible problem solvers (which  may arise due to
known software and hardware limitations ).

As it is informational there is also  some C++ here.

--Abhay



Acee Lindem wrote:
Hi Abhay,

Abhay D.S wrote:

hi acee, and other neighbors in the AS,

  5.  Flooding Scope of the Router Information LSA

  The flooding scope for a Router Information LSA is determined by the
  LSA type.  For OSPFv2, type 9 (link-scoped), type 10 (area-scoped),
  or a type 11 (AS-scoped) opaque LSA may be flooded.  For OSPFv3, the
  S1 and S2 bits in the LSA type determine flooding scope.  If AS wide
  flooding scope is chosen, the originating router should also
  advertise area scoped LSA(s) into any attached NSSA area(s).  An OSPF
  router MAY advertise different capabilities when both NSSA area
  scoped LSA(s) and an AS scoped LSA are advertised.  This allows
  functional capabilities to be limited in scope.  For example, a
  router may be an area border router but only support traffic
  engineering (TE) in a subset of its attached areas.

  *The choice of flooding scope is made by the advertising router and is
  a matter of local policy.
  *This specification, takes OSPFv2 to new levels of  intelligence.
  Flooding scope MAY  also be policed. Such as only a subset of capabilities to be
  advertised  from capability subset in each scope.

  Such as when a router becomes ASBR, ABR or just an Internal Area Router, GR capable
  Overloaded, busy for example (if you receive a busy bit) (add to capability set ?). Busy and Free
  capability  might be used by CSPF. ( You might have just edited the new specification for the TE Addresses
  for all OSPF interfaces). You might read the relation.

  You might want to add a section, IMPACT:   Where in you might add the impact
   Action: Router shall perform only those actions upon reception of these capability information
Since the draft defines a generic mechanism for advertising router capabilities and
the action an OSPF router would take is specific to a capability, I don't think this is
necessary. Note that all the bits in the OSPF Router Informational Capabilities TLV
are informational and no explicit action is necessary.

Thanks,
Acee

  Any comments ,
  - Abhay
 


 
 
 
   
------------------------------------------------------------------------

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf
 


--Boundary_(ID_GDOoAGPDKBeHPDXqb3pWEA)-- --Boundary_(ID_qXQ76EAuhUKYQJ3rvJwh0A) Content-type: text/x-vcard; charset=utf-8; name=abhayds.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=abhayds.vcf begin:vcard fn:Abhay Rao n:Rao;Abhay email;internet:abhayds@acm.org version:2.1 end:vcard --Boundary_(ID_qXQ76EAuhUKYQJ3rvJwh0A) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --Boundary_(ID_qXQ76EAuhUKYQJ3rvJwh0A)-- From ospf-bounces@ietf.org Tue Nov 28 13:47:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp7xB-0004gx-VX; Tue, 28 Nov 2006 13:45:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp7x5-0004d5-AB for ospf@ietf.org; Tue, 28 Nov 2006 13:45:07 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp7tv-0001OP-Jl for ospf@ietf.org; Tue, 28 Nov 2006 13:41:52 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 28 Nov 2006 10:41:48 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kASIflqn013867; Tue, 28 Nov 2006 13:41:47 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kASIflDM014895; Tue, 28 Nov 2006 13:41:47 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 13:41:47 -0500 Received: from [10.82.224.37] ([10.82.224.37]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 13:41:46 -0500 Message-ID: <456C82EA.5090208@cisco.com> Date: Tue, 28 Nov 2006 13:41:46 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Bill Fenner Subject: Re: [OSPF] AD Review of draft-ietf-ospf-cap References: <200610191232.k9JCWdlG028778@bright.research.att.com> <45380295.3040203@cisco.com> <200610231743.k9NHhpF5020698@bright.research.att.com> In-Reply-To: <200610231743.k9NHhpF5020698@bright.research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2006 18:41:46.0968 (UTC) FILETIME=[DBB8C580:01C7131C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=686; t=1164739307; x=1165603307; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20[OSPF]=20AD=20Review=20of=20draft-ietf-ospf-cap |Sender:=20 |To:=20Bill=20Fenner=20; bh=9ncsI6dxgbKwLb0ZqZVmb/okIccmHVsqYyOeCt0+7IA=; b=MUayKfbBbGbWHkqzwQZrGB/0P84zPED7P84HrRwX/DI6V17gFPrR7wclg4GRKr4ITAor0xPP 1JugTcTy4feJa0qSw7sQYFug99UBv/DCKtX+VKc8IZhScVABnVt9WO3Q; Authentication-Results: rtp-dkim-1; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Bill Fenner wrote: >> Since this TLV is for informational >> purposes I think it would make sense to reclaim bit 0. I'll also claify >> the numbering and contact someone regarding update of one of the existing >> implementations. >> > > After thinking about this a little more, if it makes more sense > to keep some of the bits where they were before due to implementations, > it's reasonable to leave a hole (either at zero, or somewhere else) > and allow that to be assigned by IANA/Expert later. > Hi Bill, Given the many iterations of these bits since the initial draft, I think it is just as well that we change them. Thanks, Acee > Bill > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Nov 28 15:47:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9qT-0004Ot-OG; Tue, 28 Nov 2006 15:46:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9qS-0004On-C5 for ospf@ietf.org; Tue, 28 Nov 2006 15:46:24 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp9qQ-0003I5-VR for ospf@ietf.org; Tue, 28 Nov 2006 15:46:24 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 28 Nov 2006 12:46:21 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kASKkLgZ015967; Tue, 28 Nov 2006 15:46:21 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kASKkLDM014085; Tue, 28 Nov 2006 15:46:21 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 15:46:21 -0500 Received: from [10.82.224.37] ([10.82.224.37]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 15:46:20 -0500 Message-ID: <456CA01C.8090805@cisco.com> Date: Tue, 28 Nov 2006 15:46:20 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: abhayds@acm.org Subject: Re: [OSPF] OSPF Link Local Signalling References: <455A42D0.8090100@cisco.com> <455A79A5.5020208@acm.org> In-Reply-To: <455A79A5.5020208@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2006 20:46:20.0610 (UTC) FILETIME=[425C0A20:01C7132E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2788; t=1164746781; x=1165610781; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20[OSPF]=20OSPF=20Link=20Local=20Signalling |Sender:=20 |To:=20abhayds@acm.org; bh=erWZWoEeNvCVNX8G75agf1Wy9c1P7S/ZDhx7/jOyw2k=; b=P0c0ve4BtdDAL+jaCdFuK9eTRMBfxFzAy9qRigU1aynAqzpbTisSCuni4gPm3hPEbdm7hQ55 kE2DR817WNowl4K/eLDkDNlOdWv9rRtzDAqqrsfcAcZ9r2yG6jmgdd5K; Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Abhay D.S wrote: > This draft seems like good reading. > Why we might want to waste the TLV space now ? To avoid conflicts. Specifically, since OSPF LLS is being used by all the experimental OSPF MANET extensions we need to assure they all use unique code points from day 1. > We also have the OSPFv2 router capabilities draft with local LSA's. I believe this is close to reaching the RFC Editor's queue - although it still has to get through the IESG review. Acee > - Abhay D.S > > Acee Lindem wrote: >> As you all know, we have OSPF Link-local Signaling >> (draft-ietf-ospf-lls-01.txt) >> as WG document. However, I don't believe we can get IANA to manage the >> TLV type number space until the document is published. >> >> In the interim, Abhay Roy has volunteered to manage the >> allocations for LLS TLVs. Please contact him directly if you have a >> draft that >> will require a unique code point. I'm more concerned with collisions >> than having >> holes in the space due to drafts not making it all the way to RFC. >> >> I've excerpted the IANA considerations section from the draft below: >> >> LLS TLV types are maintained by the IANA. Extensions to OSPF which >> require a new LLS TLV type MUST be reviewed by an designated expert >> from the routing area. >> >> Following the policies outlined in [IANA], LLS type values in the >> range of 0-32767 are allocated through an IETF Consensus action and >> LLS type values in the range of 32768-65536 are reserved for private >> and experimental use. >> >> This document assigns the following LLS TLV types in OSPFv2/OSPFv3. >> >> TLV Type Name Reference >> 0 Reserved >> 1 Extended Options [RFCNNNN]* >> 2 Cryptographic Authentication+ [RFCNNNN]* >> 3-32767 Reserved for assignment by the IANA >> 32768-65535 Private Use >> >> *[RFCNNNN] refers to the RFC number-to-be for this document. >> + Cryptographic Authentication TLV is only defined for OSPFv2 >> >> >> This document also assigns the following bits for the Extended >> Options bits field in the EO-TLV outlined in Section 2.5: >> >> Extended Options Bit Name Reference >> 0x00000001 LSDB Resynchronization (LR) [OOB] >> 0x00000002 Restart Signal (RS-bit) [RESTART] >> >> >> Other Extended Options bits will be allocated through an IETF >> consensus action. >> >> >> Thanks, >> Acee >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Nov 28 16:48:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpAo1-0001y8-8O; Tue, 28 Nov 2006 16:47:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpAo0-0001y2-5M for ospf@ietf.org; Tue, 28 Nov 2006 16:47:56 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpAny-0007DG-Em for ospf@ietf.org; Tue, 28 Nov 2006 16:47:56 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 28 Nov 2006 13:47:53 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kASLlrEo029218; Tue, 28 Nov 2006 16:47:53 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kASLlqDM011701; Tue, 28 Nov 2006 16:47:53 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 16:47:52 -0500 Received: from [10.82.224.37] ([10.82.224.37]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 16:47:52 -0500 Message-ID: <456CAE87.1030209@cisco.com> Date: Tue, 28 Nov 2006 16:47:51 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Lou Berger References: <455907D0.5010706@cisco.com> <5bg6vi$2pimgv@sj-inbound-f.cisco.com> <45623C49.7070207@cisco.com> <5c02hq$ajidoq@sj-inbound-d.cisco.com> In-Reply-To: <5c02hq$ajidoq@sj-inbound-d.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2006 21:47:52.0139 (UTC) FILETIME=[DAAEA9B0:01C71336] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8779; t=1164750473; x=1165614473; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20Comments=20on=20draft-berger-ospf-rfc2370bis-00.txt |Sender:=20 |To:=20Lou=20Berger=20; bh=sP875mqMlPM0IYR8+Zq2S4QgwsSwYHp1ymGYPAv1F/0=; b=K+FwGXFsn98N7bECWLz3Hsz0FowfdVA706XC7/vB5gvTdT7q8dVxsMAIbjA7p/2bPnHynf95 ZCgQlV+Hn+0ufHx2Q3DHwijU8mA5JNJAYBnXMJ6arUqY/TMVoABc/6/4; Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: OSPF List Subject: [OSPF] Re: Comments on draft-berger-ospf-rfc2370bis-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Lou, Lou Berger wrote: > Acee, > See below. > > At 06:37 PM 11/20/2006, Acee Lindem wrote: > >> Hi Lou, >> See inline. >> >> >> Lou Berger wrote: >>> Acee, >>> See responses in-line below. >>> >>> Should the corrected version go in as draft-berger or draft-ietf? >>> >>> Lou >>> >>> At 07:03 PM 11/13/2006, Acee Lindem wrote: >>> >>>> Hi Lou, >>>> >>>> My main comment is on section 5 (6 is your draft). The draft adds >>>> mandatory reachability checking for AS scoped opaque LSAs. >>>> If we add mandatory reachability checking, it should be for all >>>> opaque types rather reading like the constraint is unique to AS scoped >>>> opaque LSAs (type 11s). >>> >>> valid point. >>> >>>> I also think we should put the question as to whether the checking >>>> should be madatory or relaxed a bit to allow an application to check >>>> less frequently if the opaque data is stale. >>> >>> What benefit would this have? >> This would allow applications that don't require the opaque data to >> strictly track the SPF to discontinue using the information less >> frequently >> than the SPF. This would be useful if OSPF and the application using the >> opaque data were not tightly coupled. Here is what I put in the OSPFv3 >> update draft: >> >> 3.4.4. Future LSA Validation >> >> It is expected that new LSAs will be defined that will not be >> processed during the Shortest Path First (SPF) calculation as >> described in Section 3.8. For example, OSPFv3 LSAs corresponding to >> information advertised in OSPFv2 using opaque LSAs [OPAQUE]. In >> general, the new information advertised in future LSAs should not be >> used unless the OSPFv3 router originating the LSA is reachable. >> However, depending on the application and the data advertised, this >> reachability validation MAY be done less frequently than every SPF >> calculation. >> >> To facilitate inter-area reachability validation, any OSPFv3 router >> orginating AS scoped LSAs is considered an AS Boundary Router (ASBR). >> >> On the other hand, there is a school of thought that would consider >> this an >> implementation detail. I, however, think it is better if it is >> explicitly stated. >> If, for no other reason, to provide guidance to the people testing >> the protocols. > > Consistency between v2 and v3 is goodness where possible, so I'll add > a comment (to the end of 3.1) and reference. Great. > >>>> Detailed comments: >>>> >>>> Section 2, third paragraph - "aligned" rather than "qaligned". >>> >>> yes. >>> >>>> Section 3, "Section 7" rather than "Section 7." >>> okay. >>> >>> >>>> Section 3.1 - Type 9 LSA - "keep" rather than "keepk". >>> >>> yes. Also I added the following to the beginning of the section: >>> Section 13 of [OSPF] describes the OSPF flooding procedure. >>> Those procedures MUST be followed as defined except where >>> modified in this section. >>> >>>> I believe we >>>> should discard a link-local LSA received from a >>>> neighbor not >>>> on the interface (text similiar to type 11). >>> >>> okay, updated as follows: >>> o If the Opaque LSA is type 9 (the flooding scope is link-local) >>> and the interface that the LSA was received on is not the same >>> as the target interface (e.g., the interface associated with a >>> particular target neighbor), the Opaque LSA SHOULD be discarded >>> and not acknowledged, and MUST NOT be flooded out that interface >>> (or to that neighbor). An implementation SHOULD keep track of >>> the IP interface associated with each Opaque LSA having a >>> link-local flooding scope. >> I guess I think that if you discard an LSA, it is implied that you won't >> reflood it. > > it does say "and MUST NOT be flooded". I'm open to alternate wording. In every other instance where an LSA is discarded in RFC 2328 we don't explicitly state that we don't reflood them. In other words, why would anybody get the misconcept we'd ever reflood anything that was discarded. > > > >>>> Section 3.1, Since the area ID is not in the LSA header, the bullet on >>>> area flooding is confusing. It should say >>>> something to the >>>> effect of only flooding type 10 LSAs out >>>> interfaces in the >>>> LSA's associated area. >>> >>> okay, updated as follows: >>> o If the Opaque LSA is type 10 (the flooding scope is area-local) >>> and the area associated with Opaque LSA (as identified during >>> origination or from a received LSA's associated OSPF packet >>> header) is not the same as the area associated with the target >>> interface, the Opaque LSA MUST NOT be flooded out the interface. >>> An implementation SHOULD keep track of the OSPF area associated >>> with each Opaque LSA having an area-local flooding scope. >> I think the action should be same as above. In any case, this can never >> happen as the entire Link State Update packet would be discarded. > > okay, language is a hold-over from 2230. will update to match above. > Same fore type 11. Great. > > >>>> I don't care if it said this in RFC 2370 >>>> and everyone knew what it implied. >>> >>> I don't know how to interpret the text otherwise... >> RFC 2328 specifically state that packets whose Area ID cannot >> be matched to the receiving interfaces are discarded. See section 8.2. > > I was agreeing with you... Ok. > > [...] >>>> 5.1 Inter-Area Considerations >>>> >>>> ...... >>>> >>>> >>>> Section 5.1 >>>> >>>> Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem >>>> as a receiving router can detect an a loss of reachability >>>> through the intra-area >>>> SPF calculation. >>>> >>>> Section 5.1 >>>> >>>> To enable OSPF routers in remote areas to check availability of the >>>> originator of link-state type 11 opaque LSAs, the orignators of >>>> type-11 opaque LSAs are considered Autonomous System Border >>>> Routers (ASBRs) and will advertise themselves as such. >>> >>> >>> >>>> >>>> Section 5.1 - Remove "It is important to note that this solution >>>> MUST NOT ..." >>>> This is redundant. >>> >>> which part is redundant, just the sentence you are asking to be >>> removed? I agree that it is redundant with 2328, but I thin >>> mentioning it is still useful. Will rephrase to remove directive. >> This part of the specification doesn't modify stub area behavior. >> Here, we are talking about validating AS scoped opaque LSA. >> I guess you could say, "Note that AS scoped opaque LSA >> validation is not applicable to stub and NSSA areas since LSAs >> with AS scope are not flooded into these areas types." However, >> I don't see it as necessary. > > here's what I have now: "It is important to note that per > [OSPF] this solution does not apply to OSPF stub areas or NSSAs as > neither type-11 LSAs are flooded nor are type-4 LSAs originated into > such areas." > > As you mentioned above, it is worth explicitly stating things sometimes. Okay - I'll concede though I don't think it is necessary. Can we call say "AS scoped opaque LSAs" rather than type-11s. Also, do we have to add the detail about the ASBR-summary-LSAs (as they are referred to RFC 2328). > >>>> Remove numbered items (1) and (2), these actions ARE NOT new to >>>> opaque LSAs. Make (3) a separate paragraph rather than numbered >>>> item. >>> >>> But inclusion of type-11 originate routers as ASBR is new. Will >>> rephrase to make clear that existing ospf requirements apply. >>> >>> How about: >>> The procedures related to inter-area opaque LSAs are as follows: >>> >>> (1) An OSPF router that is configured to originate AS-scope opaque >>> LSAs advertise themselves as ASBRs and MUST follow the related >>> requirements related to setting of the Options field E-bit in >>> OSPF Hello packets and LSA headers as specified in [OSPF]. >>> >>> (2) When .... >> I don't think these points need to be restated even if they reference >> RFC 2328. Opaque LSAs don't modify these conditions. Hence, >> I don't see them to be required any more than stating the version field >> the OSPF packet header should be set to 2. > > huh? opaque LSAs aren't present in 2328 and the specification of E-bit > setting/handling in 2328 is largely relative to AS-external-LSAs. The E options bit must be set in hellos for any regular (not stub or NSSA) area independent of any opaque support. Opaque LSAs don't change this at all. Thanks, Acee > > > Thanks again for the comments, > Lou > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Nov 28 16:59:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpAyW-00057E-DY; Tue, 28 Nov 2006 16:58:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpAyV-000576-1K for ospf@ietf.org; Tue, 28 Nov 2006 16:58:47 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpAyT-0000Jl-MP for ospf@ietf.org; Tue, 28 Nov 2006 16:58:47 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 28 Nov 2006 13:58:44 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kASLwi5S004362; Tue, 28 Nov 2006 16:58:44 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kASLwhDM016665; Tue, 28 Nov 2006 16:58:43 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 16:58:43 -0500 Received: from [10.82.224.37] ([10.82.224.37]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 16:58:43 -0500 Message-ID: <456CB112.10803@cisco.com> Date: Tue, 28 Nov 2006 16:58:42 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Igor Bryskin Subject: Re: [OSPF] Re: Comments on draft-berger-ospf-rfc2370bis-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2006 21:58:43.0514 (UTC) FILETIME=[5EEE99A0:01C71338] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2596; t=1164751124; x=1165615124; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20[OSPF]=20Re=3A=20Comments=20on=20draft-berger-ospf-rf c2370bis-00.txt |Sender:=20 |To:=20Igor=20Bryskin=20; bh=Ox5fFqTcmX5p5J4AHxsxpIDHLxyEtuzr/I0qkc/H0+A=; b=RNK79gEaZ6l0FL/N87eU1OBPQNJEkUfYAdF3tG8M/M9hDer0AOAB/pV6/lNdEo7vUeBizf0h 9rCr9xr3MeD4wt2Ac6kX0OOh7kqGjV98Aw/bkAypPpn/bBJXGqFQQmsl; Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Igor, Igor Bryskin wrote: > Acee, > > >>> I also think we should put the question as to whether the checking >>> should be madatory or relaxed a bit to allow an application to check >>> less frequently if the opaque data is stale. >>> >> What benefit would this have? >> > This would allow applications that don't require the opaque data to > strictly track the SPF to discontinue using the information less > frequently > than the SPF. This would be useful if OSPF and the application using the > opaque data were not tightly coupled. Here is what I put in the OSPFv3 > update draft: > > 3.4.4. Future LSA Validation > > It is expected that new LSAs will be defined that will not be > processed during the Shortest Path First (SPF) calculation as > described in Section 3.8. For example, OSPFv3 LSAs corresponding to > information advertised in OSPFv2 using opaque LSAs [OPAQUE]. In > general, the new information advertised in future LSAs should not be > used unless the OSPFv3 router originating the LSA is reachable. > However, depending on the application and the data advertised, this > reachability validation MAY be done less frequently than every SPF > calculation. > > To facilitate inter-area reachability validation, any OSPFv3 router > orginating AS scoped LSAs is considered an AS Boundary Router (ASBR). > > I believe that the usage of opaque LSAa and one of basic LSAs (required > for SPF calculations) and, therefore, their validation are unrelated. > The important thing, as you put it, is to make sure that the stale LSAs > are not used. I mean, there is no need to provide timing recommendations > on when and how frequent the validation of opaque LSAs should be > performed. For example, one way to implement such validation is to make > it event (rather, than time) driven. Specifically, the advertisements > carried in type-11 LSAs could be marked as invalid every time when the > corresponding type-4 LSA is removed from the LSDB. > I think we are agreeing in principle. Note that while the absence of a Router-LSA or ASBR-Summary-LSA indicates the originator is not reachable, the presence doesn't guarantee reachability. The text above articulates the fact that an application using OSPFv3 advertised data MAY NOT be strictly tied to the the SPF calculation and may check LSA "freshness" at less frequent intervals. However, the SPF should remain the definite source for determining whether an LSA's originator is reachable. > Cheers, > Igor > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From mrodlufolgvbbacvw@berrante.com Wed Nov 29 02:03:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpJTo-0000mU-E8 for ospf-archive@lists.ietf.org; Wed, 29 Nov 2006 02:03:40 -0500 Received: from ppp91-76-16-46.pppoe.mtu-net.ru ([91.76.16.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpJTk-00027p-7s for ospf-archive@lists.ietf.org; Wed, 29 Nov 2006 02:03:40 -0500 Message-ID: <000b01c71384$d868dbf0$00000000@ppp91-76-16-46.pppoe.mtu-net.ru> From: "brent" To: "zev" Subject: Re: hi Date: Wed, 29 Nov 2006 10:06:09 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C71384.D868DBF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C71384.D868DBF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C71384.D868DBF0" ------=_NextPart_001_0008_01C71384.D868DBF0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ----- Original Message ----- From: = ospf-archive@lists.ietf.org To: mrodlufolgvbbacvw@berrante.com Sent: Friday, November 17, 2006 3:23 AM Subject: hi provisions, when his wicked brother left him, as he thought, to = perishsnake, which, though a small mantle, was wide enough to wrap a = fairyfor Helena, and return to his old passion for Hermia and then the two nobody marked what he was saying, Benedick, affecting not to haveBenedick = to meditate upon what he had overheard.Rosalind was delighted to hear = that her new favourite was the son My lord, replied Protheus, it is a letter from my friend Valentine, And how stand you affected to his wish asked the father.Bassanio if he = should break this day, what should I gain by themake professions of love = to her, she repulsed him with disdain, andbeing unable to find any place = where she could purchase food, she was king's wrath the more, and like a frantic patient who kills hisand = affection, and in an open way shewed they had fixed their lovesstood = listening to them, tried to say Amen, when the fellow said on the loving errors of her own youth, Helena entered, and she said on the loving errors of her own youth, Helena entered, and she saidFor, = said he, whatever I say or do, you still are crossing it. IWhen = Antipholis of Syracuse had finished his dinner, he was soher husband = mildly and she said to her sister, Why do you hear Angelo had never the purpose to corrupt her what he said, has = onlyreplied, Where is the duke It is he should hear me speak. = Escalusnight your name should sound among the hills, and I would make = Echo, Lucullus was the first applied to. This mean lord had been dreaming Old lord Capulet made a great supper, to which many fair ladies andof = love the night before. That had been a night of unmixed joy andThe story = of the play was of a murder done in Vienna upon a duke. TheOthello, who = by spells and witchcraft he maintained had seduced the by a fellow whom Iago had set on, swords were drawn, and Montano, amade = all that saw her conclude her to be dead and now by the carefaith, and = loyalty, who, when he might have succeeded to a throne, have convenient places for harbours and for shipping. Here Ulysses ships which lay there, all which they utterly overwhelmed and sankNeptune = for the putting out of the eye of the sea's son. Yet therethe oath that = they had sworn, not in any case to attempt the blood ofdriven him upon it = was past but then again the rock drove back that voyagers. Thus much, that you may not fear to trust yourself in one ofand = be welcome such lean beasts as are food for poor herdsmen. Thewe were set = to plough four acres in one day of good glebe land, to So that day's feast was concluded without bloodshed, and the suitors, On your return to school I hope to have a fair copy ready tono way = connected with life. And he told me that the ladies from the and she was such a poor scholar herself, that she could teach herwas = weeping over her, and crying out, O miss Lesley, you have toldmother's = room, which was now made the repository of all my playthings, discontinued talking to me. I scarcely ever heard a word addressed to little happy good child I had been all the way, and that when he = founddwelt in. Then I thought it was like a waggon, or a cart, and that = itand some of them seemed to be grinning and distorting their features ------=_NextPart_001_0008_01C71384.D868DBF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
 

3D""

----- Original Message -----
Sent: Friday, November 17, 2006 = 3:23 AM
Subject: hi


provisions, when his wicked brother = left him, as he thought, to perishsnake, which, though a small mantle, = was wide enough to wrap a fairyfor Helena, and return to his old passion = for Hermia and then the two
nobody marked what he was saying, Benedick, affecting not to haveBenedick = to meditate upon what he had overheard.Rosalind was delighted to hear = that her new favourite was the son
My lord, replied Protheus, it is a letter from my friend Valentine,

And how stand you affected to his wish asked the father.Bassanio if = he should break this day, what should I gain by themake professions of = love to her, she repulsed him with disdain, andbeing unable to find any = place where she could purchase food, she was
king's wrath the more, and like a frantic patient who kills hisand = affection, and in an open way shewed they had fixed their lovesstood = listening to them, tried to say Amen, when the fellow said
on the loving errors of her own youth, Helena entered, and she said

on the loving errors of her own youth, Helena entered, and she = saidFor, said he, whatever I say or do, you still are crossing it. IWhen = Antipholis of Syracuse had finished his dinner, he was soher husband = mildly and she said to her sister, Why do you hear
Angelo had never the purpose to corrupt her what he said, has = onlyreplied, Where is the duke It is he should hear me speak. = Escalusnight your name should sound among the hills, and I would make = Echo,
Lucullus was the first applied to. This mean lord had been dreaming

Old lord Capulet made a great supper, to which many fair ladies andof = love the night before. That had been a night of unmixed joy andThe story = of the play was of a murder done in Vienna upon a duke. TheOthello, who = by spells and witchcraft he maintained had seduced the
by a fellow whom Iago had set on, swords were drawn, and Montano, amade = all that saw her conclude her to be dead and now by the carefaith, and = loyalty, who, when he might have succeeded to a throne,
have convenient places for harbours and for shipping. Here Ulysses
ships which lay there, all which they utterly overwhelmed and sankNeptune = for the putting out of the eye of the sea's son. Yet therethe oath that = they had sworn, not in any case to attempt the blood ofdriven him upon it = was past but then again the rock drove back that
voyagers. Thus much, that you may not fear to trust yourself in one ofand = be welcome such lean beasts as are food for poor herdsmen. Thewe were set = to plough four acres in one day of good glebe land, to
So that day's feast was concluded without bloodshed, and the suitors, On your return to school I hope to have a fair copy ready tono way = connected with life. And he told me that the ladies from the and she was such a poor scholar herself, that she could teach her
was = weeping over her, and crying out, O miss Lesley, you have toldmother's = room, which was now made the repository of all my playthings, discontinued talking to me. I scarcely ever heard a word addressed to
little happy good child I had been all the way, and that when he = founddwelt in. Then I thought it was like a waggon, or a cart, and that = itand some of them seemed to be grinning and distorting their features
------=_NextPart_001_0008_01C71384.D868DBF0-- ------=_NextPart_000_0007_01C71384.D868DBF0 Content-Type: image/gif; name="qyKIJPYI26.gif" Content-Transfer-Encoding: base64 Content-ID: <4lDjN8UAJu4PNL2B1IFZ> R0lGODdh+QHCAaUAAAwGDCyWLLyOVPwGDPzSXBR2FOzm5JxqNHzCfOyKjMTGxAwmbISChARm/ORK TPTOzMTS7OyeNNQiJExKTPz6/LS2vEQ+RGyq3MR+RNTSzAQChFSqTIR+hHzmRAwmdJSOlDx+xNyq dPwqLHRudPz+/OymrOxudNzW1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA+QHCAQAG/kCScEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqL jI2ObQAjaAofRgsAmJkKRiMAVx+XmJJoHwZqoZmRUaVFE6mYm0kfngaqj7e4XLZmC6NEvb+eJ1yX H8MVl6Zls8NpwFWdlgvBsUezyrnZ2lW7Zc+/viQKFpVboNVC3WLXp+FS0a0WRRbuRLMk2Nv6+0rq 4qiV4CErx8ATKFHKOiFE1SqcggUfZrmKJOyhJiETvw3xN+SbLQ6pNimMhCwkCVSqZok6cXBXy3pV NA4BmakczZSZKgQrco5E/klYJKKdiNQznaSXpkYq3OiJn9M/6mrJI+GKEgCRtoiqGjeBREGsOmWe DJdMojh4sB52tTCN6lUi48od+UYvaFMFmOyWGte0IAMSbEvNMnbPwOB/XQ+r1SJWsQUAhrfitDR1 yMNKth5HNqXK1jnHiSXTIpH3qek2GfMVkQlKpxBgOIUBQOYLWQV24KSlmqCzk+uCJEC6FoKsWje8 vl6N3VhvwrSCqo2eBNBscq3aCx7WfqskdZKJmbryvFp0CPBWbS1rBcdOlat0075VIA+ZKemmp/Oj eRw+iTp4GMXXFUVW1fLKVXhh8kEsYolFAm7RfGUPf6nABYBcQzy2nBB1/onzwUhe1UfcCAoN6Asw 0Rj4SgUU5qREi+IdMUGMDYWyCX8kCnHeThZa9EpE9V0Y2Y2lHHgVcMrkVZp+TI7ho4tH/DeaWyFe 0wtsI1BARDMMKGSMPw6CxCVkIKEzHwXNRFnPAgIyFyKJB1EA3WsXjoBMV98AIyZpWRJxnZZDRGcZ SrMhIRZevTDQmhBWuZdeR/gRR50rgJoXJCvrjVWpEPdUBwAFmFAgaJOkYsGXSXO5M4txkiSY5UFF VoYEWyfRKJ0RqwoRIXecXqgEbhlCRpcku+RVGF7GTQBqckcF+Sh8T5x6kZqUWYpOcFcBOMR7RFhn T5B/hZiVrDqKeJI8/rSWqm4XB27arTtDtVUVnZLMBxkFnYxyiVubLCYWR77pKluQnmDSG5gQDaMS YW+xWQmbAn8KD15/1bKAiW7OcrAkJ7w3yyjz+veKux3V00lSsOQ6XYiqOUcNYkKICdxQo7hqSkEg T6PtSZegue7PWTx5bTDKuQUAREN0wuCn5WJiQSwUjmDKBxrmhit3E5tkAHhSHzHShcaJshV/EygN 4EuUdricVMoWdJFhFA5dRIJAIQGArelgciXDCInzGIYLwFiNvQo+eOlGC1RK+Fs7ZwL041lUoADJ kJdBuRWSXw6F5nc4XvnnoIe+yGOiim766ajr4fioqbfu+uuwxy77/uy012777bjnrvvuvPfu++/A By/88MQXb/zxyCev/PLMN+/889BHL/301Fdv/fXYZ6/99tx37/334IcvfvMlOCDC+eiXAEUJ6Bth wvnqW1H++SYsYcIAAyRAxgMD1D/+/2/gnwiGUAL9QYF/A3hAEfCnQCwIcAn4I0EBw6CMEgzAAQDM IBsEWKkBHhB/HhTC/RKYhQcmwYRheN8QGqjBFp7BhP4jwQPeF8MSmCABCQihDBPAwCG8j4RCYJ8I 4veABDjgAUOUoAiOWAQOCqGIBnAABknAw/ypT4j+K6IJbOg/ExjgfQoEoxCMKAIDOgB/CTBFCYhI Q2ysEYkxdKEc/qWAQBwO4IkDUJ8IBmCAKOLPBFN8YgIs6EEv7rGBEeQfBhEIyAeYjwQRJMIDKbDH /u1RBBQYYRrvRwEKJBKENxyhCUbogBHKcIBnLEEmL/iAOsowfyTYowEQKAJNzvGWH0wg/4QQSQvW j4c6FKQnE0jJWJKQfwbEn5Z6KMAqbsqJCHzlAJ04gELm0ZgGhOQdtcnLOz7AFHvUHw8NOE5uSrB/ VERnOXHJziU4MZnbfOA6Jak/QprgAZQk5joPqU0t8fCe32xiNfGISQ4adKDp1B8/u9nNZQ7AnxeE 5TrLGUl5ShSW7czoEZw4hIoOdJ4rhCcmjanAfwphjw4dY/8o/gfNgR50mpEs50LNGckIorScE4Wl Ml+JQZxiVKNAJeim7qdAC6oSpIIMIhAP2cmaPrSf+MCfKeIoTaG+1KFa4iRJO7rNnSozgvf7JToT usqiXtOn2QxqRi34RxZq858UQOA1CfhHLWFyldW84gXPaIozVjOr+AOiUttaSUf+MbD1M8Bh9dpD TbLVjpYEIf5KgEAHVJGEaFypXDer1qBebpab4twR3PXNSrkLtKMdgpYAxVoSPNOtq02tEFiLT1EB CrWu9RM+iRBb0Xb2t8ANrnCHS9ziGve4yE2ucpfL3Dm2spWsW+FzAyrd58pwutg1xSyze8IGRvd7 OURf+tow/sNFjtUI5YtfGiKpBiSqt1QjdGsSFIu/QLL1p5cdbDYrqb+w5mOGWipgWjO4Trx+4btI vGgwByvfMtB3DVVsMJMi7AS/8lGlPcQje5E5BL8asLBCUGwMd+lCkO7xvVlQ4RLWKeGTClYJnmzx FAzgWzDMtFQUbsJ9/XdZFsr1iVTMpodFCEIMM5EEVAUgSAn5xDYegbI5zOb7juxh1Uy5pBhdow/P p8BDFnGQSGDrDXE4yC/jw5Ax/GIZjVDEISSgiGsOKQ6DXFL4CbJ+WpRgDpGIjUO+zxRwdq8SazlG HAr4zQVUIBLjjGRCG8CGOFwwAZd4TykecYaOXOIMl1gC/gMMEpBDJGMaJxioLY5SGVUcpAPUO8MC stqvA+x0YH0cWNcaUL1DPudk0xnYMgoK0/c8sxTLx+MEbBHTzQPpA/mnx6fS9YLO9OQA75eAVYpA vgMdZUJdCUkMapupP2UzA+Pq1S8edqwJtGBaL6nrMkqVCGesnw25qch0DhCYFKji/YhwSb++sn9H 5OQweU1wJL4yqrxM418rqWIksHuEakSyVNl6RV3LGp2qDNRkq2iKKqryxOec9lhbGdgJznqFs7as EXItV/3Jtdeq8aXE1ZdqNJ6xiP0Ld/KU/ddentfFXU4gUV0bQaRaUIGPTqjSeYj0ZjMbgs4+8QwZ +uBw/t4vkFXd6o2jWVCMKnPZLt0pv4nZw3FD0prqU+YwM0lzdHa8f1W0NxMinOqA1pF9F6RA/Opr gEpK0E8b7yGFLznMavtbhvmE9jAFK9d8G5CFLA+sy+8bWKzTV5xS9fhkGchDrC9vydfcKQqBns8E I/KOSL0xWrc6hEq++AjsZetIaXpHBrZSoB5k6o21CUilkxTsXV+w7jH7VBOW8342PCMPuUpCqe8W qUeg7xbPyOhLFhCNgNLk3YsgYBBHmAJ+dWW+G4hlr2b439uMXyBzfd+j0hjvtUb5RRMYYdDe3KTO A6n5CVoEfh6Sqf2UenOlUpinUANoTKYUYtHBXtq0/k20t3Yk40T+93pshWX+I0svJU3uMoEp9W8E SHRfdUFE4Ewg52Y6hwR+9Wi7hmEXN2J1xW5IhkEVWFie1kPUJ31sBoIO4FCMF1haAmgOmGsjdGFG 5Fpx5XeOdHGYx0ffF0SWVUo1JjzzdD/KMHRG1X/EdEgy50liRVVxF1dLN3+uFXSG5UFix1UjOIAR 5En6E287JEkINXwNtlMD108IlG9fh1Bjh0/o5oA7pVXGpEqpNEZAqIIPlUm+twS+1FTOFlUjVYIu NlXoVEcRFn44l0f5VG33E0JERGR7d34/FmLslWuVFD9GxGrX5G9hJXEmgIfEhA/X9lzfNTxDeD46 /pdZrUgEskdLq7SJWkJLbhVYfNRys7Z4TFhfbHVEN4eFY+VJlXJYuUhfeuhapVhF1wZC7nJDdGU+ F9aAlzSEVOV6uVhJIyV9A2hBv+hs41RLPDiMkscEnqR+udh6PDZ7IjRS/KNdh+RHW7RHXpRGxsY+ GUdFSwRmD1A++JSPNdhWMjSErQR/+LBjmXZPgKI+j9ZKgxRgY2VEjqQ/fpQ/6SiMB3g9cXU5vbVa Jclbu1UENFYEraVa+dBbeLRRlfJFRCBVpNWSLqlauRVbRbCDTdRJqrVbMrlRKzlbbHaUSLmUT6SU t8dbWRCFO8mTQimVTeCTPAljULkF2SiSDthc/lPwetzHP5tyhlvwaV5glRoEUM8FlGApBXrnTgcI a2rJBAz4lk3wZp0UV7OIl1xQl375BXHVSoAZmIZ5mIiZmIq5mIzZmI75mJAZmZI5mZRZmZZ5mZiZ mZq5mZzZmZHZAKAZmqI5mqRZmqZ5mqiZmqq5mqzZmq75mrAZm7I5m7RZm7Z5m7iZm7rTAMPFmxnl m7vZmxoFnLlDnL9lnLeEnLajnEHFnC7knLMDnb85nLwjne1knQCEna+jnUMAAd4JAX15PdbZR+Rp CoWZPNzZOtppAN5Znu0pPtB5AhmwRvRZAidwn32kPemZOtjZnuVJnu/5PcxpACdAnyFwoCUQ/gL1 eQLUZT37iTrSCQEV8J0UWqETKqDRZ6ACcKAIyqEKukb4WT0PejrOSQEVcKIomqIqiqLh+TzKeZAJ uqFrpKAeSqMIap9psgQj4BwjMBXyGX0WECPDAaHViQQGcAFImqRKuqRL2qKiEylggJyPdqAyWqM2 SqU12mlLYAEZIDBawhtIMB+cAhOhM6Kmw5xICgIXAAJs2qZqegEN4KZvegGzWAETEKQ6MSMWoBMY MgdLYh/dAqXc8KeeUwR/eh9MIKVYaqUcuqEbGgKPyqFdKguVASpDegRiGjtmKjrKaQBuGqdrGppr CgJxGqdqyqY5KguFwiFdegLk4qeGmg4b/iGrV1AwpEGrt9otuNoUgloEyHkCi+qhjxqpkEqsG6o5 FsAB9mAAFcABrkE1YCoOwsAB5cAiztoIvYoFm1qmSDCqpdoAHlCqbDqabXoBqYoEoBIjeGMHkdKu uYqrVGCr8Oqus0qvSGCcFJABB4oBkSoAGECl/yoAAvuvjSoAFaA5AKCsRXACC6CsO2oXjEILM3IW QbGuYlCoh2oFhXofvXqoGUsC2wo6zKkA49qmDCCnKMumC+IEnaAlLIEPHKCwJ7CjvvABZcMBE3AC HEAJOYsvZXOuWWCvt+quBcOrUKokRvCx77q08gqvRvCrxXoAGDC1/Lqv/OqvVSuw/soA/nKzEQrb CspKrYYTsTEjDxywpwbwtWWAH/KarVFgq7w6q7r6rnHrq0Uapm1qqnKqt236ARUQnhngK12DLfgA ABkwFJWAs0GRMHc6GORAARPrBULbtENrtLuaN1EiqEerq0L7tEbArFpLtY6qtaQrsAfwAYqiANEV pHBRCcnqWjTbFJmquK4qCmfQrp07BU07uZw7t0MQsp8DnZSwmiCQuk5KKzGCFyTQMTT2umXjE00B EiTQpRPQpQ8rub47tL17uUwbJd0bq/WavZ5rBApQuuYbuhhwun5bASfwXcyQNKYwAcq6p9JKtsGB Ln+bqWpAqLJaGh5LuZjrvXLbv+IL/ryVI50nUAEjgJojwADsKwWDIRfK6xNl87o0MwE2URkZsKN3 +gW8S7QDXLdOS6sinL2U67YgG323MbX+irVUm76KIjkZ0KI9uiAjUAl3ghx2KiSdwAGuChHOcaJk OgYnHMD+K7cfm7GbG74DLAQGDDnQ2UcKcBsLDK5WDCcT6qQhhgnYoLwswiEOu7PYoLiFawpkzC7g y7YkHMJIvLlx67YiXMJHMKC3cQB2fMd23MB+CwEnIJRQkAExqwwnMMVoIra3YQBTfLhTTKBp26dm UMJxjMTiS8BNPK/f+7t3awSiQqEZQMUkgsUKoAABCgU9SgQ9rDEccDEKMBILcLjO/qGsiEs1C3Cp QZu0R6vG3Iu5mus4B7Krt5yo6DrFqBsRqEut69u+OqkPuLzG3Ju7uSrHlty5T/w4zPmdouydg3wb KZoBfPydWpwBk4oPifwgHNBHPvwhU5yszKoAk6oAO/sgtMyulbwR5+kEzHmf4BzK+szOfCyf94nM 27DEyzzQAczEADy3uCyo0ww0yikq/4nMJwCe//mfYSC/sBvOhrCx4CsGnUqgGaAADwDOGfAA/0yg DGrSAI0LvYyobDyvB10hK822vzy+wWmkNKZd+JDTOK0M+UlBNIvRstOp7TvUfYSf+MnIRF3Un7PM hlrP95rJo4WVWMmU3dPRE33V/ljd05Cj0ZOcBQv9M9K5lya5lxiqyTut02h91jgdPV+9Ltvqx+CD nE6dW9DT1upi19vT0FDpLnxN19KD16QC2Nkj2C4K1cdJnbuTm4q92Izd2I792JAd2ZI92beZ2MI5 nZYtXITtPJudHw861eHT2cwj2qaRnnA916ON2DUNjyQD2txD2soD205hnXCNrnHNBFftPbLND2Ht 15rsWlpsOiisBdCZoBFw3MgdAQp6n75NPbu9DyUq1mTdkjSGklKpp13BIhP7o13QMRaQrF1xtnc6 3kALqIFqqMP9BBvL1RWSN0qLydEXAsk938lNAPapxQowI72gsI4cMxhMHEyw/qP0IA92GqQG3t9y kN5T8Nz6UKI7jdX4UDpavQSBMwR2ihHxfAULMAwGUOHkQBocELgIXsmRvLTxqr10a8KXPMfxTd/J PbX0raB9eeHTqwqumgSvexLRdcMY4QmKG6QGoDZSgLEK7gTrrcREnrEMvg3Mad0/mJ/IbJ5GSKBO ABKT6rdhgBeAcuG8GsZL8MFdDQW7q+JMPMJEoJwl8OIRAOPIjQFt7ubIHQIy9hrVcLZMYNFNsKqg AhjUS+AWywRqDM26i+JMDcKVvOTaMKATDdHkGeWm8MBNQDO6QhzX+iB4mjRlMwLUqqzPO7PPuyVH wwo6obAJO70Z3sSGTsD+/vvLu2w36H3E83zmnzvfbN7mb17rx62lmBopaZu2X0uzzfC6H1DOuvLf gUrso84h4qG26n3esf62KY7q2+u0iJ4NznnUE40Pjs6sf/sE74EvQsCwDtsV8PC4d3qiWlELh+sr ppwJg5sOzO4fKk60lhvtSay5G/3MXG23TeSvxy1FcL7mbA7nuM6vfXwE0uuSCW/u4mHR86ETFoAm vGI4mBCtGPGqg4rQLP2/Js7SSfvqkMzvq63Jg7zt5OnQBHqi5R2mF4LlGBG2lXAPpDHq4pGwRT0B zRvvLDERlVLqeT7v057QXV3E+b7ESfCrL2xpDjC1AM/0lvbCU3sA3W4E/gk/N01RvRULxumwCQmb AazAWx9iMBny59BOr6vezB2L72Te3rKe2eg6yDNcno5+G6o75EL+uj4LD6BwtpPKK3bao2obERbO Kz4P6EBf5kIf63XbsWSuBFIqAEsP8BGg9ErP9EnvABJgJ5QzHxjdFRPs6R1MFaS+CTTRykMws4FS +KFfq5Yc7c889Cve+vNc7bkwngl8uP+pzQf/Dt1g0fQ7wXuKDtzxxYChtqmMDeZS+F+expLs+gnt xpT88S29BHIdAk2/9JYP9VQrRRJgx86azKvhC6ivvLVgxuKR41fBIvmK59IazsYOGGRv5NLu/LKv 8R2/4r1K+7iwnlMc/son6rdAkKGQiEXjEWkAVIqVxaQCGFUmgA/FAtBaKB+pguStcJ5gIgdg+Sgm nyK6jZQDkNqjnUjPF/V5ep9P608QT4+QT06uQe4EQ8IBMlJSUkLi4IDjo+LBYCgxw2JE4WOEhGIE gOPE6sNiocLJYlTKa2oko0hBa42jlKh1gSNx+K6YpA8Zce8Y8NjZuVl5+RlpkfgaO1t7m7vbm8ga m8LgBFZz0/P71+hEoYLiJJOkwm1kLarCXcHgl8PAQFUTChk4cMBFhEK+CvzUNaQWLU86h8TCGaGg wNGjSQ4qVbr0QVOGfxQkyjHwQR4JA+5wKeAAJmS+lTK7BCxiQCRK/ia58h38RqgQoGTTmFELZAeo IT94jB6pOBFqVKlTnyYaRxIrSXL/phIDAMbAhJJdyV4TNAwi2aoITwi4VMmCxwMj7MHilHVsWb17 60i7k3fiWr6DCasTXGScKaymGKvkClgqmwkjIBe2fLnI4YEKGHzoXBADLAUPTnTKihk12bOJ0gZO /Rp25mEkLSpWTBth5di7eXcTPO6fAdInTogMfrxT497LmVdr/rzrYXW6oVffvRY4cu3bgyu3/t2y dPDjnZM3fz4b9sdD8GIdyc8Tbero6aevfx8cfv3npbNn7L8k/xDaj0BtxCuQuQMRXPCy3/57MD7c /luMwQpls9C6/gY03JDDDj38EMQQRRyRxBJNPBHFFFVckcUWXXwRxhhljBHDDGu8sUEcdYxKwR0L 69HHIA0UkshtgCxSLSSV9ObIJXFs0knXtkEuyh2P7K67KveDUstvelzphBDEDKE0hrpkEEiuEMry TPq4bNNIbEgbc8wKxvQJzi21MVO70vI0780/rxEvTDoNHdMMQe87UE3H+jSTm5S22UnRISuliphC D930nUvRE6/R4IzTbj4jFrAAG2F+8SXI1hwK1FOnhjFgU0QP7TTW8UAlgqtyjMtuJUixqSALPJE4 YYLqVitrWabuWLao8nJ9dZi2LplLTDtLCIGBERgQYMwTskHW/oIJhOFgAgtUZSfdJpZ0FdNZef1H n62Qc0dYYkZYxZd43JmMBGSDqSAeN1ASBqV9RghF3DHiUWOqobr646E5jFCqKRJgnVbjRGgVACRY GBhTgLpgqXM+fouwJ5EoVo3NWT/4ghbaQJ61T15HKxi1z4X2LKUKIpBlxQoDFlYAnna9cANdEtTA ItkTTq0AlXx/upjZpiASyqhmNp5WsDDBXYicCgQomQEFSoNAzLOtliOLld/WhblmMFYNmmns1puo RKTjR1SeuQqunLeR6AXdJc5I1ulzUV2ciFBICGgCcRcmwtw8KI2YtWhjRqqOvftChGsjvs5VsAzA dZuIDEKY/stnWsf8wNhhxCCC1Q8mgIIIugue56Uw/PGX2Hoq59wveK+WuGusSx/mb0ffJtznbKZQ QBfGOXg886bPeNwLo1sfIV3G1c0jUalaC4rvaG/26+LVns+P44YEC+HssztN6IAPxP0Yf69Ln1mS RQ/cJQsVvaMDuQIWjHksISxLQAMHiMUqqMwvLYOQWfwyFrPkOQ9rFCEG4LhDuH8ULhsGxB0A+OG9 822PBMnyHglOZQYADAGGMVSV4pDXufbNj3TwGx0QTxcr7OAvfwcAAzzyMQTV5c8tA9QXAE5AmTMY TA8um5z5dgiGHCpuhhcMYd9s5jlleNB98OMaEKVlEumV/vCE1SMGsSBWRQBAoQqasIAsvOASgblh co9bBUhcAYupeeF4UYGXxO6WsWc0cnTNM1397CcHCiARivBJjgGg6BYlbiMDqWCV0SajB7oFEnM7 ZIL3voJK9Y3RkRVbBhvzJsQ1wlIRI3TMOEqTgeK0gzhxNFwR2hE7hRggH8SRSRjcgEy1IcQnY3jH GjLgjoS445VmkcZQPvdIMqqRjEX0VOoO4Ba3hEYiryvnOm/BjSwAMoZMOOUpXVgKJXjxca0M40Qw 6ENZ0hJjWwOhEGUlr+BgD3v5wN4JyzZMBiXFn8wD3bOYIrqtQUScl0qdJ691ADIRR50d7Z9DjxA+ Pkwh/o92VMUEFuCGKKjrjsQiGh6tkM0zomWbZ9ybUtb3Q2xEL46kCQ4nSIjCaTHvYqXiRkYr9ZuQ ihQDIj1AVA8gx2wkxAgAcekVeuJMcZEgA7ioZjFXgi/sfVWM74to8ihG0UEc4iF2U17HDPoPsmnH MbAgKZxqhkupMFVRv8mAVAl7LXUJgZKyrINSKzkrnLjjrtrJACxOwNjE/vWyTJpVBQor1VBYtX59 JWhZ/tYOhJapTHFcqGUzK6XWWioRJ/hAZw17AAZU9rXL+Rs5JqtQhJ72t7nNkXB/OhvVzbawe5yL APZKXL4cCDilGU4w8ercwQBWUIchhztIUdhMJLO5/tZN0jXg88bjmGIk4t0Ldv8kmK0Qp7cgkS8s NiESP6kXNf3hRqPwG53+VmNGARbwgAlcYAMfGMEJVjCM/jtJSyInKw9oz3FY22DNWvg77M2TZgCH F/i4B8QYvq6IbSRi6LLnNCg+DYnXy2LoaBhOMHYxZmecIBLLuMauzfF1brxj8ODYxyI0cZBLTOTX AFlLUKqwkWHLZIuRtsfZCA4EIMAmJ/OoNwvQRrrQKrTaEeZzc9UGzdAY5lwOeYQGoPKa2VzlK2N5 NiqRM+DmXOfyauN22FDC5uL5mtKJWZttRerdIElXDP+tymtWs5rbHN43nxkJ7oEjHLd8xzFLETYS /hWjpj9IxChHmtFtFjWV97HfcllgDOlal4/dO2lXdzm2pLjhFZFVCnTtxAq7w8UYzECFEfADJSQg H5/TKkkNprEo0UCjJPfgaTQnYdTRJnU3VmE+TLcJ0NSKtHlTm9oS3ncYlAmlGyiABk3cUQGXOwYC tSw1YVAtDFqOwgQUsEe8EcUQ+f7hRSOJb2bT79CJSOgFIOAOCND34BVI+MEh0A00mMM8y56Zs0Rr 5uKCmnBEDSZ132svnAzTAOpCw+O0eL5TKm7PjaPhPQCAi1aesod/zum/g2jLgfYNyVVaCzLNUYEL nAMWCw869ryRBQtWUXLCE7YshLawUpT7u5Ka/hhqKEZoY3Dz4kkgHHGIM13kcJwcsC7pGtLdchKc MnMntyEYMieFgnBgCIqDuU1l7lOCBvTJzcZlzqO0lnL4nL6wuAB9EwpZvXYjlIwLWMuV4NKYsnTx IikaKjSRyHtfpq3/vuVoL3QEYDGUoanlhLeROczHLb4UJRfGyd2wCn6cr6VCE9fLs52NuiuWmzvV uw+xXtCAHyvw9B28z4EefG+AgodhIcn5jgEGlykfC6pChQUvv41jm1nZGYRl5mPZ+SO42tUEC7cU gL0AK0yfjlSTAgXSQDWX1nBpBkRkBqY/dQ7OvGvcX8pb5VdG/zv4946gHC6AAAcPJAjwAAvQ/gBx ZRtKIQsYwtccqPnOLosmQwKVgAv2ovY8x+qQbYNwafO+CQAtgvTAj3oY8Pv0gQgUYrIUIKySiSVw QpqEZpnGAJDqhSWeA6n4YMmELACzih4U8Od+Tr4UECTE7hoCIvHOjntUiQKZMJVWUBeor4esb+YA iuaah5ZGEAjPypfU5gt/CQyByRweIFdESwR1rMHCRr7asA2JcL4Ya/pwwvzsQYKegB7uiP5o4Q6h YAQWwI4Uz/64gZH8bYi+KQS7D+A87+/c0BEdkbIcrcb4zkkOYxTcEA7lq1s+wNEugujKChdQorL8 QaGuKRRVodyqCQyw58uKzQrb55F0r5ae/qz3fDDSoqvjSkMXO+7OHo0L/0s6ZMtbHJEBEAe0dGQD C9Fmsg8pgEJv5ApnriFCVmwx0qEHn83C+sMduoUuunEYj5GSdjAifmQ6fHGpPg3aSK3nzkEB2EwS 8wQNFTFezHHEsDGrqGzKRO04qIwefaMf6/EHs4rCTPAfm6wg/cseB4RXVCIx3vEgf/EhoYISl+Q3 VMwaIcQ2IhJ6NBIhA5Ij9WIimSwkkWQk6bEkg+wkhSQlH20lc6wlrWTBYlImZ5Ima9Imb7ImP1In /WYne9InfxIog1Ioh5Ioi9IojxIpk1Ipl5Ipm9IpnxIqo1Iqp5Iqq9IqrxIrs1Irt5Ir/rvSK78S LMNSLMeSLMvSLM8SLdNSLdeSLdvSLf+E6+JSLueSLuvSLu8SL/NSL/eSL/vSL/8SMANTMAeTMAvT MOuyKQ9TMReTMRvTMR8TMiNTMg0zMaXGAxYAMy8zMzFzATSzMznTM0MTNEdzM0vzM01TNFGTNE+T NVOzNVfTNWMTNmdTNWvzNW1TNnGTNm+TN3OzN3fTN4MTOIdTN4uzMi8TOe2hM5bTMz7gM5HzOaMT OqdTOquTOq/TOrMTO7dTO7uTO7/TO8MTPMdTPMuTPM/TPNMTPdczPCtzNKnwF1iqOH9zPoWzPomT PvPTPvUTP/fTP/sTQO9TQPlzQP8T/jev8SGJYzqtCAncgKXYE0LVU0IjlEIn1EIrFEMvVEMzlEPL E0EPkjhYk1U0pAjSZY8ClEBT1EA/kyRW1EVJQkUDFEYLFEVdtD+xwkZpVEfp80MLUkGfUwM4hK4y gBQs4DKzAjtbdEOfE0anEy/Os0mX1AOetDqVtEOTlAKcFEmXtEWj9DupdDyb1Es11ErHNEwpQEJ7 9B9DNDM1QBM8wAMgoAHYAyd0h0WzlDPzdAGiVE/71E//dEbzdEY9808FFU1jVDWVtDYDNUd7k0/5 oUaHU1F7E1L/c1IbVTMZNVILVE378Uc9wE0pYE41RkPoNAMmADmHoDOpdEtNA087/sEDDGBKt1QD bmNVsaIzNWBPaQg5O6EzfdVV0XRKeTUrMBNY4dRVfxVNZTVVhfVWcXRXcRVUb+MygzVXqXUBXPUy a3UxoHMIqFNbF4BbYRRWszVLj7VLcbVcy1VXiQBcodVaZ5UEZlVZcdRXY3VZz7VaoRVJmzRZ8RVa dXVPhfVfBTZcHVInQ/QyR4AAPkQryEE+dxUzZxRGVXViaWhgPcAI6HVgtQxjK3Ze9TQ3spQILlZj PxZNv1VMSbYIhvVWPdZdOVM+UhZPu5RYD1Vm0bRkO3ZnL3ZidRZje3ZYcVVieRZjO7Nkh/Vk3RVk MzNpLRYzhXZXj5RlX9ZiVfVq/ln2SOd1YzuTal32a1WVXnc2UDNWbPX0WzP2KX90BEIABEoVMRry VFOVWG92ald1QFI2ZMEWRhHDFMBWUHn1TtM2Zm32bg33Mj0PcOmWSe02bR9XPg63apv1Pzx2a50U MYa1cmP2cqc2aS33c2f1bKN2b1+WXiEXbEv2cbm2bi33ThXjbk83ZBGXUUH2bwMXMWCWKdlUDTxA Q6rJdxugE04oYlf3cj83bZ1WcAuXdVlzZz3TYjXTVE4Wbz3WeiU2Zov2M7M3Z6H3Y2loZ1U3ZN31 acEXYztXeZFWcEtTfEPzc4tWVbM3fkP2YrkXcH0We7/Xdb81aUuWbM1XZoMW/oB99n/3l36LNnMD uDQ7dU1P4DIFwAOMtEOGVyVOwEirl2/Nl3G9dW/Fdn4xVzrPNnU1GHRJmH+Xt3QXF4Mx+IM9l1f9 d3abd4NZNIahczNPODqT927JF4WpFzo5l4a1VH0N2Idh+HhfmIRH2HVdNmZ5eIUXN3RFWHeXUmE/ Uws2BEsgtn6BFn9h92TZ43oRWICJlmi3FnYtFoZb1nUbg3RveECuF3pRjIj7F4mL4HrDV1rjI2jT ATTvTHkZI2r5lY+fV2wVI1OP1nvJ2I6LeIDR2FSi1YkPWY3POIbDV4DdWHMReYtZ9zhPkzKyYniJ 90qlNDzTdpRF85RJGU5T/nk7pXgzUxmIWdlCXzk63XMzfy07pEdg8hRTN1U/3xdReVNgg7mXd7SY i/aYRRM3jNmXX3R3HdiTx/CXuG5uVXmWh9ma0bNPZTlCaZmbsxMzh/mbudObNVQ1bVhgk/SZRXR3 2tmdd8cVmHlH/zSZUZSXm9mXOROb63k+71meU9SfiXk3C5U0GdgcPzWbu5NGbVhPO3Qzhxmbw/me v/mhG3o0t9WiyROi8ZmXN1qiARQ8KzqgDdSjxdU0admNqbg4wmqsWNqlX9ql1UamgWmma5qmb9qm cxqngSmsdNqnd1qnYbqnfymmgdqofxqpV3qog1qpxyqpwVCon9qoX1qp/qu6qKX6qnc6q6Xapn2J pa2apaFapw3aF4mjGAvirDmgGBmArdu6rd8Ord8uredarus6ru9are06r9X6rNcar/uar/Oarv/a rd1asNm6rgd7rxdbsRtbrt8asOO6sBHbsSV7silbrwfbrxcbrS/7reG6shEbtAX7sDGbsTMbtQP7 su16s/26MhngLWNbSMw6YCbTtm8bt3Nbt3ebt+3ytWu7t4NbuIebuIs7uH/buJNbuZebuZsbL5Hb uaNbuqebuiUTuqsbu7Nbu7fbt58ZtrkbvMNbvJ37uvWSih7zvMc7vNMbvdVbMcs7LoFiFeZ7MOU7 vuebvfkyvakovw/T/r4Fk78b87/vsuUA/L7nssDduzDhm+v6m74NvC73GzAlvL0X08EN88LpMsPN +8DlcsMVnC8ZnDjyO8BXQQv+sr8JAb9PvC8l/LwFYcRj/MH3MsVZnMJhHL9X/MVZ3MQ/PMJ9acR5 HMcLHMf1O759achDqchBvC9FvMdPPMApXL+HvMFzfMLpu8St/MX9csCt3Mv5e8ulPMuvXMa/3Mu5 XL5d/MF9nMnl0smpyKtzvMvzEs5/qc6jfJpbPJSQ/MnxfMw5PM6V/MRDaRX4PMbVPMhhXAuAHMWB PMFb7tH3nMdbnKghnRAk3dEZvc3z8s09HL81ndI7HM+vPMw9fdSN/lzUD73Ms5zVNZzNEbzKVV3W TZzL7zvBZ/3VNx0JjZK2IzzP8ZzPQZ3Af73K/5zS+fzOi6PA97zWGT3Zg32+kd3Oo53a65zZudyr lx3SM33ZqZ3GqXnblR3TxV3X9bLTbT3RUVzFn7zQaR3FY73IpRzV4zve6X3LZdzG8z3XPb3BhXzR dfzd4d3G2b3czd27gVsuQT3QidovF97hGf4vGf3hH74vhZ3h4zwuFx6+Lp7jMb7hqbnjQz4wJ17c w6rgDV6lv9vV170wk8LC5xy9YX63XT4yk+LC973gnXzjPX4wKT7PR57jJ9PnhVvjIZPkM/7nT/4u dV7pm97pw5vp/p9e6qdeuqOe6q8e64nb6rOe67v+tn/bs8Ne7Mee7Mve7M8e7dNe7dee7dve7d8e 7uNe7tv6t2Xb7nGk171e7/c+t7ee7/8e8AHT7wOfulWe8Id78A+/t9NNAO7S8O1S8AiQYKS78dXb yQ1v8qMb8xcz+IJPFfKy8wPv8/lSTAigHAbAARwf4ely8KpMzQgwukOAACpfvBlcoUyLvpr79hOK sgyT2EwBAjjgAkDfkoJ/+PdS9glA+QkAAzDA4vO+LmGBV/Bx8Jw7BCiA9qH+4OVy8qsp+GiHMG9L Mbsf8+nh+fvy91VC+I8f8j1m/fUy+ZefACLA+e3y8edS4d4I/gLYnzFxfi5lHwgEihOxaDwik8ol s1lUkKLSKbVqvWKz2i236/2Cw1Mig2SsnBQKtOFUeVc+SAad4TyV73e0+u2Gx+kxVVxBfHBwNBFa GSI6hRBESkY8PGAMJeUtXRhAGBhQfBpcIAGYAggmoaYeKUAShGQonZqylp6s2iopbIj5/gIHCw// kpkVVfSdUFD8AR6VRdk1aeoeJa+hhQL6WRMtkpQYkBg8kEBUJA5KIQQEQAR0KqgvSdpTMivIyUIf K3F6AhVl1JFc3ogYvBNiIUMSkTAwXGgk4UGEFaEFoEBsI8eOHj9KMYYMzglQBrgFMqIpT50iLVlW RKlg3Ek4/nIOLnogwoEBByJKGqCnZFE7d+4+QZimxF6kCPiYGdB3gp9Lf0kuQPA0BQKpiVQR1gK7 CtXYWrT0QNIYRZJGCpFCeC0YNlfZsbhwZTgl61QRvnoK9AIpeDDhwmPw+CPJrNmZlC5bHpOG54SU MnasQquj9BrKZdve3MykeZMUEyJOm0Aq9GqUd+eOflqNpMSkp6E+rZmDmTMotSS6TZzbtyAuu8Mt KmQayW0kIcH9Dqd716JwAPykU2ySAbDh7t6/F0M8cmYocuQ+hzYmGU8dEtXoUKZGJ0qSN+Rplq+Z fs783UQukNDWaSJ00olsRwAoBQVGqaaIAgQ4VcJiSGWF/kY/9cSBFVLAGSFLXnnRspde1k1FokV7 3SFLBa+wRYAAsVD14VQzhngXKjLiReKHJtJiXVh3FBBkB+ARWaSRVIj0jR9QFaGiY0laRpl7U1a1 2RLRDJVMgAG21Qxo1NCnxAcD+XSaA1lBMEITYzIjRVadpKlIhRUspg8HClSomxKQCPDGBX9eYOES ZBFH3XHITScIi8yEoMBXiCJql3E2RndocHdskOmQR3LaaWFJOsMGBRmgtN9KVCL2nhlWKuGfktwo EIoz+yXhKhFs6pSaCWdmdaARH4xjVDxoJvXoNcRC9cEII+CJjp5IPPTBEMYOKuOOHvqILVXSUZtE CAYs/sdcLKV4iJC2JZ6bo7Y6slvujdpp6qm883IEajZLemmTqZCxN1+/4k3mzb1LmqFvRRy0BRSc WanJxJgGGOXJOwzLiQ6doSg7QgUWP2vEQ33qcZZYffFlUMmWPsKcAKC4qEop0JlsCorIzVVzdklk kMEGm9Lbs89ggHrCB4DMpF8FrEoZZtKR0XdMBrbeMTQcn/wxNNKscGBSgcTGyUTWEAu7AZoND2Jx KIaMwMHGHAZ9QrQV5KxHuXPPSHeMdTcpyBAuxiJABm4JcES5HeI9eOGH2324E7IokNHPj0OORdtS c2O1oBdhTjkaoB19uTUIi8I1xV5/8g4CGyBA7AgQ/jgx9SeHDB0oJiphFgIGQz+Aue5NhEDCi/y4 QkHguxO/RAaxRp688m1n8IHUQzvPgOfFW+M859FPr8vXSC3MMOtLbC/66EzkHChu9s3e8VRxwD0j 9e836n7O8b9fPxFPK5//421/8wEdHDjPfheJw/8CqDtEIDCBDBjBApuQwAcusIF6gMO0wISEDORO gBrc4Ab158Ge8Y+DIrQf3eQ2I9blrFsVqYbgRujCF3rjgzL0VAhhaMMbOqENONwhD0U4wx8aqYY9 HOL7VHg/9xExiUq0BhCb+B1jaCaKUpwiFatoxStiMYta3CIXu6hFDjAAjGDkohjDaEYvojGNUSwj /hvPqMY3dtGJcvwUYuZoxzviMY96zJ8QRQjHPwIykIIcJCELKUioFW+PivRFHznIAAtAMpKSnCQl K2nJS2Iyk5rcJCc76clPgjKUohwlJeNzBDBQ7Q6LXOUXGrlBBkyAlbKMnCAmYMoikON0mdolLzcg rHHoYZbCvIIrNfjIYSJTXkvDwiNvSQQSICCa0URdL3dpFETiMpnJLKYAYanNbxbJmUqApThJgDpp nk6X1QxAARjjBHAOk5v2OyY86/kpbDYTM+ZE5y4hQIFeuqMAJDBiNu25Snkm5Gas8KZBG+oRcWbC lvo8Zzt2qRZr+rKdwXSoIvn3o7j0haB3oKcY/gAwDJNGAaWCUelJOVoFiM7BAuXMlDp3KQVfGqWd jxLZM12qR49mJ6GYY2hJqaBSlmrhqIRBajCYylGYQkOip6wmL6OwoJxi5mY+/SnAQpqoGoWIUMWh i82gYYFfIFWpXVDrSjni1O88QBw+M2WPfpTPUwaAqjZtTUAHSiNVvHWrQGybcbATnUmJFVIqiaUv aJFSU5DgFJGVbEqloFaUYjayldVsZjVrVMhOFrShHa1oKRtazIrWsqA1KWpTu4VyJCABDnDAAAbg gLn6o0eLLWdeN7CY31KhrxO5xTIF60TCosha2UIXu8JKVmORNAxKZetlLWtdz2a2s6zdbGC3/ltZ lmrXs5y17lun21nN+qYKcU3ArmrrXvfeFoT+AJGOyCBTffY2vVbo67bEIiPj3jFodf0qgaXzMpJF Fa3kva54mVrd7UJ4vBF2sGSnO4Xw9qjBk7WChTcr3ik8YFe0fS+J3SuB2aI4xSpWcQkGABJxmsgl UjUCCXqrVylgdbiVKi6Afyjgui1XXeZqF7r+mi77Kvi7DGbrkpU8YQlD+cILVvJ1s2vUJad1yuJl LBUeMFsJlDjMJ14xmWdrAhMkwAAu/og4DYeH++JVr4GpMVbn1i4S9XiOPz4OWEf0nJGNdQ5clq6W qethQx+6yYnWcIe5S+Xxehi7iWbrCLRg/oASsHfEJTbBF3yz5ofic8a4dAdVcSwsgRZBhyJzbZ5n GLTEwRpvR4w1dM/a2Cqj9rRVZrCGF93rBp+CAo59rHe1W9oKl1a15w3toLMAlQdkGsy21W8XPt0R qKoEzjQmdS/VIqyAjgpxeGv1cbs6C90Wj6gg6S6vkxlYLLSFBHEdhxisXa9Ql7MA3O4nnb+NalWS e7DmVkLidhfdj7A70sI07S+o7QV7bwTbLtH2qI3iS5x+u85IbFXAfTxwGKq743iEODH6dUVRE2FB Qco4y4PEGB0uQeSu/jjB63dwmc+R5MPwpDhLF6SfAz3oBfhbCWuFcw/K0+ZLXDrTdTeA/iFi5hNc +m2bFDShjR6djzR3YdbzqHMiXdBDKRQ7rZvQda0bMu1qXzvb2+72Abg97lo8+/J4TPesf/3uet87 38GQ974DPvCC/7vgC2/4rhP+8IpffJ4Tz/jHQ76hjo885Ss/zMlbPvOa9/rmO+95VmL+86IfPeRC T/rTo55Tpk8961tfmNW7PvayJwbsZ2/723+h9rjfPe+roPveA3/3vw++LCsR2+MjP/nKXz7zm+/8 50M/+tKfPvWrb/3rYz/72t8+95kvV+ITA9oo7j75y2/+86M//epfP/ufvysJSMAE5gC/L0ow2zTT f/QGkK0D5p9/LnhZ//1f6gWg/w2g/hUkgASUwAGyHgXY3wIyIBXIFr1FYOoZgAQkQAVGwQRqYOv1 BAQyoP11YOxdIAj+n5cZ4AgSoAAOoAOYoAqyngj+n/05HAySHgWwIP3loA22npflnw/yoOztIPDF VhDKXhGCH08YYew9gASAHxAuoetJAAX2XglwWhS63hDuHhJiIeuZwAvuHqZ1YetxYe+d2RiyXhny nhqioeixIe69YRsCQ/x5AfwpYGnAH6eVgB3y4QLuIR9eoRQ0YW1hoAfFoe0d4jAwQI9EQ0fMxBZY AAeQAAfY2ku9W2UsABiMSRVs4h09wAA4YbXVVnyRgImRQAKEWQaiYonR2yeCorRl/mD+JOIRxiJI LKJLAECldQQqQGIZlIcV4EIX1OAV3NzNOdEnhiIXEOKaISMonuIA1OIUoGIs4qAzkgBtzZ8r6s8s xh43AkN0KQAA+EY6gMMY/EYiTIEBhFFIAEAnToH/QAEJROJASAE50odK2V2A0BsFJo09RsEE8OIU AGRJpGPTHM3SzIM7RkETXuEextcf3iEJmEAhSqQdDgT8XSQpRoGmXSEymsAoTsGIKWEp2tYAmAMq 0pYTTiMCQuMUgJk5gJkDqEUlXMGISYD/wV+LcdogKiAdfoQ3kmE0esTBAQAhGIApWACr9cgiAGRS FmVoNeJjJWUsWYBl2BpSQlYw/h5ls03BMZEUL44AADilezDcIprCBxwVFIjlKSxCUjolFZJkFEjb RoKibUUBId5lXUbBR5rkM2pkTK7iAroiBsakXNpWSualTpIAmLWYSoJi8m1gS0rBSrYYIZpADQJm bUHge0lIbbWXNXoEUKahUHYEA2TiFFSlPNqasCmkWEYBJJEDAMRjWKbUMsHmQInjPFIiCaClZQ0B AGxlFpjmJFaidURWW2rEI+mXcgrbOFQAZtlab/ZmFIxAJRqmObgXdg4ABdSWvLmXd8bfAHCatI1n XwpiLH5kBmpjXoLnRl4mSXKnE4IiMj5jiUVmNK5kfbpXIE6mXQZId5Ikekrm/kcmY0eIZuodaBgc XGrKphRUp1FJiVeCF2UEpG9SQWoekwXoIjuyGhV4ZXFShluCQzFeZaVZAGM1aG26JSS5Fip+YUn2 n11iI23RlhVCY3zGpzMCqDRKW0vS53Xm5xTUFgUwpm3RJ0pWQpLepzRKpkZ4WXZSwUtKgZQO6XUu JGgaKGnCoZZuBFESgnFGwW5eGP4Mp5jWZmThj2XZpiTu5jyOwVrGIzGelZkGpFk26HB66Gn2ZopW qHVA0gNRQXzSlpqd2AD4oW2BmZo5AJhpBJhNI22hZJQ+JqS2J5BKppBuZ0oa6pHe6Jb0ZzRio7xB oEZQqkua52L25Y5KaaWG/iaXIqKrKqJ1hmNKNeKJQqg0nNVzsqNGVGhKdaItzeMxTUAlBpA4ouUw fqhV8eImUgBskqhl0aavKisJDKuCxOmUulc1VilJTpu0hSJfDsClQakgWmN6UsB6wmeLPaQAdmdl bienammQwid3hqsUlGppXCqA7uhHXiGBgkSCnh7AfsEtEgEHAIAkkqUchOUy1elVylQ4XiXCTIHB okFYNiubWkAzHKzQFGVeRMEC2FpxDedzSktSPo1YHg8AxNItemhAJuWGmkIyuCYuyNRzcuUqymRl kuKILeCIxaKagSIzZGtcAm1c1ZZ6juKThuLRuqJGVCkhnqszoiIf5uEz/vKhZtKleCZglUopvSbA IF7hjtLrZxYoRwjs6J1tF9ipKSCsNJzCtZ6pe9iaATgllzVly5oCFGCorYWjKeQBSrFmZC0TPQGk bPJi36qsRhylOKajKWjEc/pGO5oClyEuV/6noSamFFSmk24rqsZXYcblNe6nMyKjTaoFkbrXZq4Z mO2k1IqZfhKiAWpa0FqpvPVoIO6o7c4nlpotrNIiuaFjV1rnMByrml7BMFaBw/kG8npq8j5AvCkI OTxvl02vswXqL1RC1V1BOQyj9v5oqxJf2iLThrqt5f7CIrpjr3Yd83JBY1aCo/6r73aj/ArWbW6E hlLBAsDl5vUo7/Zu/vjSrxw61Lk+L/v+gvh6HgILMOAp8OY18ALv3QNnngRDMN1RcOVdcAVnXQZH HgdrsMx58OOF8AcH3AgvXgOnpjDcnJte2yX6wlgORjA+TjSYaUfspgxbIjEo5E8G8GgOgwFzwQpH ZcS5cBjgwiPGcBGDHUoZY6w2DTAqsRY08f8GXwMLhHkA0PaGUTkqgB3g6W8wwMValT5IwSEsDTy+ 453ksPNQgf+4IwWQMRWoY9ui5TKYY0jUo9pIARVKCWVcBjvy5hvHcVA0YtIkDQUewrXOcTqq4xXU MXFSAAMopP8YMhjbnT+KaT9Kzz3icRV0sTuOgyRLAUCmKSXjcfD6/oIJKx4KWwZWMtVzriVjNSVS SqXfkmXe9u1U1rIuYiX5mkGPtIUru23eCuRaFuVYRWWK0ubiwnAKyzBSWudYmUIov+0sF6WwaQQu RMNT9rLbOiUhFAf+IglfmCUM57LKElvMVoEwH9MzG/MvpxRXuqXj3vJY2ikJnDOKiuXwgoEqHx4r kyVNqO/BRsGsHiW9ueZ0HiWbHtUiNCcuaEQGxBJEm0Gz4QLCwuaDptTTGGwVHOVsmhQOj/JVjslt Bq6bPrMv/3I0OCtKfTR1staYGOxZHeUvZ3MsHXRBh3SKQnGYAmdsnqxD/7RrqmYbp+UNm9R0RtZv BqdRO+ic/vRR/lIGJfKqUI9DLgqDPxseQH9lcTXDI5nUIj61PMKsJNITzUYSAJTB5MYpW+ewTofE Bwyk3FaBWKupSMP1UfJqnD6oM2NWceHwrNKTXddmb2qoSWm0W5OlJI1FFshwV6M1i661lNQwWXvo WQWjOHMo417oPtsziNJ1ZCflZGd1DyOoaWPBAljGaQouFRQuixInJspj2+pmyB5sAlEGBRQu4+p2 sL0pIMPyifJiZce2mnrsOldAtIJpbKM0ZqUpIHMynn6x4ApbZEn1UwbIblOAwT6Qxjo2StEpQjwQ hVL28LJwmGK2San2OCcl3KomoNIpR6f3A51sPnqBVhceV4P2/oWpBeTq6mtmbLXSKl0HSIVejFCH 8SIcZVRSNFlGFrPy4s39t03jNXUm5SaqtRTYqpv+t/ratNsS+IRTdC6alHBblYKrNeTWIzxLDhOD qLD1I69G6PAKeCC3s0nVeLFSQPEKZMYOBBR0NV3D+Iq3djDgt+Dpt/Hu8caiJXSewEzjZiIkJcZq +DEnpcYmwnOigVq7AXbfo2w+pySiLCzLN4ctQBoAQCZWeGyqFPqewMJSK5ivFmDnbZgTeGRZQMra WlhmrMEyrjZ3+ZfKZt+yuBlYIhTEtzxaOeMGZGUDOlqmQ3r/ciJAugzbbxTkRc2ic3hPIi8uwKLL eGkD8M5Z/qWSV8bbNijdimV1akTfVqdZW+dux6OfE/Qt1zo7wjLCIu5zVhpxk0PdcjKHWaedxmOz iuV0ejguwHI0kJSxo7OySiIudKKdIqyqi2U2H1VxnSWnxzkxF/nNIS6sszji/q2yKmTl4qrxCttP y3rcAsORBx68R2/yhgEQgwH0boSX49EfJ5O9f4G89x3Ag1MFJKUiqfTZCXwEo/bZEfz+anDC6x3E k7BBSbwFL/zE8x2aEZ8YYrzlfSHxQWHHR54W4l5PiHzljWTwpfzJL17IE+HFs/zRVfzduXzMFx7J 8x7O2/ze1TzwyeDOC57O5zwYAv3dWeEBomDR813SHyAN/io9zQt9FUf90/eYAXyhv+Oe/Tk81edZ E8L87e0h0XO9cclWCmpgiE392NeTl8mfEQbg16o9R0HbiVXvEoqfmbVf3uv93vN93/s937+fA8A9 Giruev394SN+4iv+4u/9A2x93EN+5Ev+5FN+5Vv+5WN+5mv+5nN+53v+54N+6Iv+6JN+6Zv+6aN+ 6qv+6rN+67v+68N+7Mv+7NN+7dv+7eN+7uv+7vN+7/v+7wN/8Av/8BN/8Rv/8SN/8iv/8jN/8zv/ 80N/9Ev/9FN/9Vv/9WN/9mv/9nN/93v/94N/+Iv/+JN/+Zv/+aN/+qv/+rN/+7v/+8N//Mv//NM/ +QcBADs= ------=_NextPart_000_0007_01C71384.D868DBF0-- From elfmxy@ccl.com.pe Wed Nov 29 03:53:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpLBt-0002ZT-Fn for ospf-archive@lists.ietf.org; Wed, 29 Nov 2006 03:53:17 -0500 Received: from [222.92.192.173] (helo=hh-2bc8bf80384d) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpLBo-0003qE-Nt for ospf-archive@lists.ietf.org; Wed, 29 Nov 2006 03:53:17 -0500 Message-ID: <000b01c71393$c9e53330$6401a8c0@hh-2bc8bf80384d> From: "ceius" To: "kliment" Subject: Re: bet this is it Date: Wed, 29 Nov 2006 16:53:07 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C71393.C9E53330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C71393.C9E53330 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C71393.C9E53330" ------=_NextPart_001_0008_01C71393.C9E53330 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ----- Original Message ----- From: = ospf-archive@lists.ietf.org To: elfmxy@ccl.com.pe Sent: Friday, November 17, 2006 8:38 AM Subject: bet this is it he took him home to his cell, and taught him to speak and = Prosperochangeling boy to be my page.unhappy queen, and he ordered = Paulina, and the ladies who were her its arms around Leontes' neck. The statue then began to speak, = prayinginto that pleasant arbour, where honeysuckles, ripened by the = sun,the banished duke therefore when Frederick heard Orlando was the son asked Ganimed to give him the good counsel he talked of. The remedy that he writes how well beloved he is of the duke of Milan, who = dailyinterest for his money only Anthonio should go with him to a = lawyer,death, said, It is not so named in the bond. Portia replied, It = isThough Posthumus came over to Britain with the Roman army, he did not at their palace and Lear dispatched his servant Caius with lettersyoung = years, after shewing her to the world an illustrious example ofair with = thy sword, as make me vulnerable. I bear a charmed life, Paris with the blessings of the countess, and her kindest wishes for Paris with the blessings of the countess, and her kindest wishes forher a = week. Now the stately Katherine entered, and Petruchio firstDromio were = greater than is usual between masters and their servants.who was carrying = him to prison, and giving him the purse of gold which young maiden. Ah, said she, I fear it is my cousin Juliet. Juliether = enemy's life, sending for Claudio from his prisonhouse, where hein her = right senses but perceiving that she was mistress of a fine pay them so, he had not enough in his body to discharge, drop by drop. man was lighthearted and merry, and said that he had worn a mask = whenlighthearted. He had dreamed in the night that he was dead a = strangerevenge his foul murder. And the ghost lamented to his son, that = hisended. Iago begged pardon for having moved him but Othello, assuming anhapless = mother had never seen, was brought up by Cleon in a manneraddressed her = in courtly terms, as if the lowlyseeming maid had beyond that which they were used to have, and the four men with swine, and filled the ample hall, where Ulysses sat, with gruntings.house = a bride, I hoped in my heart that she would be loving to me andnymphs she = gave in charge from her sacred woods to cut down timber,and dutiful = submission to her parents in the choice of her future into which the king and queen heaped presents of gold and silver,trouble = them.aid a man's kindred are they that he might trust to when extremities So that day's feast was concluded without bloodshed, and the suitors, slaughtered bodies of the suitors dragged forth of the hall. And theywere = happy days! maid, with tears in her eyes, and I formed a resolution to beg of = myarrival of some visitors to our house they were to bring childrenyou = will disturb our newborn friendship. Elinor has promised to love The best suite of rooms I never saw by any other light than what spell out meanings for I was too ignorant to make out many words = butposture, the halfclosed eyes, the mumbling and muttering which Iheads, = made in a strange grotesque way I have since seen the same ------=_NextPart_001_0008_01C71393.C9E53330 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
 

3D""

----- Original Message -----
Sent: Friday, November 17, 2006 = 8:38 AM
Subject: bet this is it


he took him home to his cell, and = taught him to speak and Prosperochangeling boy to be my page.unhappy = queen, and he ordered Paulina, and the ladies who were her
its arms around Leontes' neck. The statue then began to speak, = prayinginto that pleasant arbour, where honeysuckles, ripened by the = sun,the banished duke therefore when Frederick heard Orlando was the = son
asked Ganimed to give him the good counsel he talked of. The remedy

that he writes how well beloved he is of the duke of Milan, who = dailyinterest for his money only Anthonio should go with him to a = lawyer,death, said, It is not so named in the bond. Portia replied, It = isThough Posthumus came over to Britain with the Roman army, he did = not
at their palace and Lear dispatched his servant Caius with lettersyoung = years, after shewing her to the world an illustrious example ofair with = thy sword, as make me vulnerable. I bear a charmed life,
Paris with the blessings of the countess, and her kindest wishes for

Paris with the blessings of the countess, and her kindest wishes = forher a week. Now the stately Katherine entered, and Petruchio = firstDromio were greater than is usual between masters and their = servants.who was carrying him to prison, and giving him the purse of gold = which
young maiden. Ah, said she, I fear it is my cousin Juliet. Juliether = enemy's life, sending for Claudio from his prisonhouse, where hein her = right senses but perceiving that she was mistress of a fine
pay them so, he had not enough in his body to discharge, drop by drop.

man was lighthearted and merry, and said that he had worn a mask = whenlighthearted. He had dreamed in the night that he was dead a = strangerevenge his foul murder. And the ghost lamented to his son, that = hisended.
Iago begged pardon for having moved him but Othello, assuming anhapless = mother had never seen, was brought up by Cleon in a manneraddressed her = in courtly terms, as if the lowlyseeming maid had
beyond that which they were used to have, and the four men with
swine, and filled the ample hall, where Ulysses sat, with gruntings.house = a bride, I hoped in my heart that she would be loving to me andnymphs she = gave in charge from her sacred woods to cut down timber,and dutiful = submission to her parents in the choice of her future
into which the king and queen heaped presents of gold and silver,trouble = them.aid a man's kindred are they that he might trust to when = extremities
So that day's feast was concluded without bloodshed, and the suitors, slaughtered bodies of the suitors dragged forth of the hall. And theywere = happy days! maid, with tears in her eyes, and I formed a resolution to beg of = my
arrival of some visitors to our house they were to bring = childrenyou will disturb our newborn friendship. Elinor has promised to = love The best suite of rooms I never saw by any other light than what
spell out meanings for I was too ignorant to make out many words = butposture, the halfclosed eyes, the mumbling and muttering which Iheads, = made in a strange grotesque way I have since seen the same
------=_NextPart_001_0008_01C71393.C9E53330-- ------=_NextPart_000_0007_01C71393.C9E53330 Content-Type: image/gif; name="LLTIRCA4Lg.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhHgK0AaUAAAwGDCyWLLyOVPwGDPzSXBR2FOzm5JxqNHzCfOyKjMTGxAwmbISChARm/ORK TPTOzMTS7OyeNNQiJExKTPz6/LS2vEQ+RGyq3MR+RNTSzAQChFSqTIR+hHzmRAwmdJSOlDx+xNyq dPwqLHRudPz+/OymrOxudNzW1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAHgK0AQAG/kCScEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqL jI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjYAAjaAofRgsAra4KRiMAVx+sradoHwZqtq6mUbpFE76t sEkfswa/pMzNQstmC7hE0tSzJ1ysH9gVrLtlyNhp1VWyqwvWxkfI387upNBl5NTTJAoWqlu16s/1 Yuy8/EUxJ8xCEQsChyAj0e6dQ0/xhCjopYpgt3wMZtW69U0Wx17C6k38gGyYqWsTXwkxOW9IRHou cXHwBcujqW40SfT6hezW/omN0IAmpNJyyExX+Y7ydFXBWpF9JHAWI2HuhCmo/UgI3WXTo8tZD8P6 iajMIIlhqQDUXHb1170JJDKubVpUZz1vJe0RLDYRrgV0Z9USuZfvyDyEVMEqaJVY1z2wGRmQ+KsL 2baFBizbWwBXc18tdT1bAJDZ7dJVZoeMJLFsdOldv5btE93ZdDLWYMXqXsOyYZGitZoKqbb0GoBu 07pVAAjz984JTWUJz0hipnAh3dTFWzyNmN2YRiagy+g7Kytxp5UlXzAxuWAlvZOYdAX3qVqsQ6gL A6y6LT2AvwzzDDrzVHAfaV/httuCaYxGXxIREbQSgXCdlJYyxKi1WCsf/hhTV11aIZhYXO8J8YGD vgwGQGFDjPadEIjZ84FNJLZTwQgeVThNNeZgSEwFKDKlRJD1HTFBkSHZAouDOAqhn1MqpkQMSQiu WNqSumSoFnXfMMYYg2COIaWQR0R4W2AksiMNcSNQQIQ4DHi0zUsgzgQnaTPxYyAF4pQp0AIUgpcR jhtRQN5wK47QDVzzVGMna20SoZ6bQ5Sn2k7HIVHXYtIwEJxEPZ0i3iq5YQfACcNQml+Vwfhnl6om XvMMABS0QoGlYeZ6xWM5GeYPMtqdsmGbG2WZGhJ/6YRkVkYAK4Q5chGh2TEitkjaYadAwxhmi2k3 Qa3dnQIgfy6RuwSv/ir5idqq/FSnloRDCEhEetJWKRmJbB3rZLULGJSsrgBzkSGs8/pjFWBoIXqK gaRRIAsurAQGy2d1vZSYcFW1AtssrURH5wLbhLjiT4IBqgqgz9pK0GKSKcMZpOAh4/EpqGq0TMIQ EkPwEHXJwlUxzuo0y6FEjMqzYJ+5ewJ1VuEy7C6DTjgiNazwGfDVWIzZrjXeBQYAyEPI4iGt+7Zi gTEojrDLiaW+aJ8xK+dkwHxqH2HTitrd4paDE4gtoVCpxvhdWd9mpFJmKG5dxIZTIQHAsrN+PQLI JHNkz2gs9uvLBOowzGGIsBX2taqeCwYvbm1jrfoUFSiw8+pSvG5F/uuyQ1H7Ha7ArvvuvJcx2q29 By/88FPkjivxyCev/PLMN+/889BHL/301Fdv/fXYZ6/99tx37/334Icv/vjkl2/++einr/767Lfv /vvwxy///PTXb//9+Oev//6AlOCACAAMYAmgUIIAGsEEABygFfwHQBMswQQDGEACyPCAATiQfxiU QwVFMIQSTBAKFRzAA4oQwRFiYYNLiCAJPBiGb5RgAA7IoAzfsEFVcRCEEbyhECAowiygMAk/DAMC h2DCGRpRDT+8IAkegEAllsAECUiADpeYgBIOAYE9FEIBRaDAByTAAQ/g4gpFAMYi1FAIXjSAA2JI gipKcIBbvKAX/k3wxAuawAAIHGEehfBFEXzQARFMwC5K0MUmtoOQYVTiERdZhRBGcQBoHMAARTAA A6gxgiZgIxoT8MIb3pGSJlRhBWMYwkw+4H8kUCERUEgBSlqQkiKgAA8FCUEKUECUOYQiD03AQwfw cIkcBGQJZAnDBzhyiRIkASUNEEIRzJKR0JxCCI0JyVRW84UOrOIUN3lLEbZSmT2s4Acj6CYrbtCN sDpjCJHJwTMOwJOSBOcHrSkEVYpyF5ScYBU/uE96rtCCbQRoP6NJUCeccZzVROFAVznBTprgAa30 5kBBaU03VfGhD/DND2vI0XdS4If9pGg9q0nOigYUkPpMZkAn/qhKhSZzoQWNKRLOOISWvnOlRvDi SGMJzhFeVAiULGc1L/o6dd60o+1UZUiz6E97QjKo/RxoP0s6SpzCVKZYJaJHiQDBEb5wmFelohaz CEpbOlWobjJABHehSHZGMpZIRSsJatnTmpJ0AGhVIQSzCdCVEtOr8YyqSrNK2BdisojWJGoI49lB TLoplsR8JxxhCMhdAHKrPGTqPw/rylNiMoIAVasF42nYHs7SsI98ZQ4jWIIQOsCNPQykBT8K2sUi lrBYlR0zYXW7IxAso6oi2G59OwQ3Ueq4JEgnYo1LXCEcF6K3otRwkyspiBKBub3FrXa3y93ueve7 4A2veMdL/t7ymve80jOmMY9HRPVmdJXuXaJ757sLZtIXiCZkb1alGEABtoGJpOyrEfynwDSoEoli JAUPb4sE0cKwsYEcAmzHOlhXTnCvDWGimzw4z+8ONLJf0G8YX3rTAVsxDaJdgxsZ/IkVO+GyleRj bbV6YHEO4bIf7KwQ1KrECooXppQssBaGuISBshiomk3CLY88BQNkFwwiHYWLm1DaC8K2iItFYxvn ieMd5lDGxdzhjwf7zxsy0ZmWaq0U54nAMpIAx75ps09VSsgrAnCEoPQiJ5FgWChGkZN6ZsgnlYhH P+Z0ngnwoqGJ+Oct+zSBm3TgHFcoxTC2A5QI3IWiwwjH/gbyMYocTrQHRxjGRc/VmQx5YhS3SYQC +vKUazTmQ/8HxjaXwACczCQX+yhIFlaKjrz8hhs56YACM9GDxr4sB28940iqkAIfLHCXNxtY0L5T kEdgorYFvUb/WTkBdNx2/mCKwgpOEq+tjuBryXlLDkIwAcQUwW1vysuVHjOVMax3WclsxhLSFt2V 3CUm6/mAF3YYlpv141qJAEgHPpGeVdVmQGPpRggSAZaXRaYFa43XbgYUkm4EJjIZQlJBetSVREYC wnk4yLmu1bBw3CyzATrMSrHWjbtw4zCDXGaXy3GxLGy2xkX4WiNMe7ETXCxoReAbbLp8gMMOJCC9 ONoO/tuP3B5VpdMv3kNM99DjV33hCA0AdRKndOznNncK0Q3O1l5QhSnOJwQ16da6RlnjyqQtQmmb 1KSyfQj7jq03UwnPAbKbnHQMqANzbsGQS7zIJRz2ex1ZQBhSQIHqNoArVyipm1vRxbDsJrwzvsSI whDeQl8stD9YxKODNumlBS3dRZvSSuqctZF/8P5g+lWTBhHJEAWlSFV41bsLdoJ3d2WSjXBgw/K0 qZAsoTH7fcOy3t2amcRpT8vt0d8DP6IjpGqJ+wnBJ6K0mtbsuiSNaVF+H0G0dASkqWHpwUBSapaU LwKHdbxiClz2mNBmQnNWUqkHWlokBJo0baUFVk5W/nkGSGO1R3UitFtT91O7R2YEmFAlBnjqN2LW RU7Fx1gyllLIJ4Lg9Es7Vh4Hln52NVLdZEs5tVUUdX2GNWcXtExIxU4EM4MAp4FDlUzdhFfqRgTo xHMS5n5HcFlkx1pHKEnwR2MmEFGeFEM12Fm4ZkXy94RmlFzqJlRMpXoMMXIIGGEut3BflFwftXmn NHO1d4WDt0Kv5UtP9j4LBUHf0FX/JGQ9BX5Od0t81VYh91FWRWKQJIigJH8uSELoF1AF9mzJ1HBi pVXV503XZ1IeV1EhBG3k5H172FcHVlJ01Xb+x1jYVkFL2HF8ZXV8NlsvaHM8ZYRIxlYA5Ugr9n8S /rhzEhRvHaRlTzdSX/iAJId+0+ZKCvRFxhZPGbdXPqeJg6d57qVf8JNZAMRvshWF6fZOzURMEMRT zYRY1sZMr1dbQWh76mZYYDR1RYByzvV3n2WNDjZFpld/2JhDBANFjfU/MZZ+sJRZbaV81uhKPAV/ IvhCblJBlLJPzuSFlYR0THBLCiSHF2dlz7dD3BhjmjeBDVd5dyRI4FZANddGZLRnBQdGtGVJsPVQ S5RZxuSAqQZas+ZM1sV5ZGdMnLRhffVFpzRBl5SLQwdaerhIHyU72GVcQXldMSkpBINcxdUQ2BVJ 2aYqeEQEa/VbTmYEwUVdzFUEDvBbMOhc1tWU/tl2lNRlRmI5lmYpX8pVBHO4BGt5XW4Jg23ZkGc5 l1bplltQj9a2guhlBsvXagYplX+3BbnmBXHpPhilXlu5l2dweUugdjdGj12gl+WVaLb0UdComHFQ mJj5BB/Ffpv5maAZmqI5mqRZmqZ5mqiZmqq5mqzZmq75mrAZm7I5m7RZm7Z5m2LQALq5m7zZm775 m8AZnMI5nMRZnMZ5nMiZnMq5nMzZnM75nNAZndI5nefTAEdknfiDndV5nfmjnebjnRkEnvQjnuND nvtjnvGDnuCjntnZnenDnvcDn+0jn9xDn0MAAfgJAZf5PfBpSf65C5opPfapPfRpAPj5nweq/j7q eQIZQEgOWgInEKGWJD4Dmj3yeaD/6Z8Jup3vdwIOGgIgWgIh8KAn8F78+Z5LAAEVkJ8s2qIryqFF QHaEFAICAKIhaqMjSkgS2j0Vij3oSQEVEKRCOqREKqT7eT3kWXAiWqMzKqI46qQ5GqFOMALiMQJm waDvZwFFch0L0qNI2mAXEKZiOqZkSqZHKhap4wXiSXYgyqQ4eqM2WqNPql8WkAEp4ybQgQQGYiJD 8RBeaj3mGaYgcAEgUKiGOqgX0ACHiqgXAI0VMAFa2hRHYgFNwSJz8CXz0jaYegW58xVpuqkKsgRr 2qZv+qY1KqdyaqN2egypUStcegR7CjB//lo95GkAh6qohLqbhAoCiqqog1qofaIEMtMidnoC+nKp RQAWuaGsWMAxrPEMLpGs0DqtaUoE4nkCpGqq2dqmqUqjIVA7FsAB0mIAFcABwnEieWoP18AB+QAk 5toI1XoFs0o9gVqovdoAHtCr9sqbhnoBwapkjxMvfFAqBPus0WoFzjqtCmuw0FqwSQCeFJABIIoB qSoAGNCmFysAGnuxcSoAFVA7ACCuRXACCyCuVDo1i8EQR6IXVAE5Y9CpoZoFMIs6ZaKpaTqv02Oe CmCvhsoAi/qzhdohU0o2P8EQHCCyJ0Cl0/ABfcMBE3ACHJAKT+swffOvWuCwDTsvz/ol/qDqJUYA qge7sAm7sEZwrTQqAAeAAWpLsRNLsRbLthprsQygOC4hssIgruwaIhIBFhxgEH1bAQZgt2WwrAYb r1DgrMxKtolbuGWLonpqqL66qJFrqB8AuE6QAStCFd8wEwwBABlgFargtFRBOZBqGfhAASvrBVi7 tVrLtYurrJ+aOpraulr7sEZArnG7tqcat7yrsQfwAZ6iAOylpYOhCuGaXEoLFrEqusZ6C2dAsKtL BWO7ugUbvTgroEqQCsUJAsF7pslSJCmLKk52vH0TFXw7C3Y6AXZ6sqpbu1kbrYRLre5Lu2Fbv2PL sEdAngrQu/ybuxjwu5VbASegX+EQ/ja7MAHiSqnqurdC0LeTAbixqgabyqyum6z3OyuOM7/32zbX Gz3seQI3IpwjwAACLAWWURgpGxV9c7xNMwFJkRoZQKWQ+gXUi7/Te7DRK7/4a782rAS1uhxqa7Fv u7b/6ymtkwFHaqUdMgKqsCjc8ahWIgscYKwgIx5B2qdisMEYHKrxC7YxW789bL2O22AGoADLMQK6 ma/5SigreqY7pjH9ERVmcbwjELXtILqduwt43AWzy7CJG79+vMXw+75lorCLiwTmSa4fcACM3MiM PMKVCwEn0JVPkAFH+w0nYMZ8krfLUcYV8LlmbAADnLcSLLaGjMPzO8hgHMap3MHQ/mOet8KiGXDG OMLGCqAAGwoFVkoEUiwzHMAZCmATC/C54iGuoHsiC/CqMvu1Nhu2gKwgsps7GWLIzSyqSEABZgy8 JAG87BrAA1yVl/DMr4vKq8y4O2zKYow+5pmfuIyfmbwcQ5oBkpyfbpwBq8oQZmynH8ABljTFM2LG 4UquCrCqChC1WqHMdvDM8xKgT2CeEWrPtxzRAy3JDBqh31wJfQzIGi3I73vBtdvFjavOvpWhomxJ J6CfJP2fYYDAyHvPhjCz0joGtSrKGaAAD2DPGfAAFi3KJcrTFx0J0/zFG50g0ewlXbOs1VwErvw8 6GlJwFNfYQjV3zChLaS0Lh0w/rU6wFpt0lr9zVv9zaLsEArtEgxtuyKtZFmJlWp51jGa0m791mLt xWSrBUvtPOxZmUJZmTB6XVId1X7d11BtoWM8BZS8186FBWXdO3XdPItdPuTJW3OZlHQJqIMdnu7J 1jLU2Nuj2coznZ792aAd2qI92qRd2qZ92tGJ2ZbdnqqNQZwt2K0tl4lN2axt2Gx5levz2j5a2Whd l7PtwZdt21bZW7/N1EyQ0t/J22tdO8blxrphuHStBCIaAdRd3REwolJa3MOj28Tzo3it11XpZES5 lpMKF0CysljaBahiAeEKF30LqfBttZnKzBZ8tRMMtikSOdCdyCFg3f5t3QQA/qFurABHIg0ia6lG 4cLYwQRUihAG8ahaGuEIjqxqqtzOJdVuzRBPvZ/9MgSPuhIIfQULgA0G0OH4wBocgLkTnsrjfM5S gLinzMM5bK3v19//Xd1q+98jepkfTgKYSzPH2iIiuwDsxcQrMQuiq6UGIDgvjqlyXTz3XdRIDbbc vd3XjIYw6J8kANZYeSvyfQQzsaqVGwaLQSkfrqwmK7iFLOOp/OKBzMOqPNc0PmDWjQERkOM4juN2 Xt0hwGTDoQ4OvAQs3QSZklyzUKdn8eAuS+iqDN1OAONvjs6tbOEp7dX+Cda7UMJN0DTPgh3vqhWR GjZ9U8f7fBY0o7Qj+zXB/tAUIhuyPh7icE7IrFvB8x3NGZypXNvmcy4p/o3neU7dROzft6anpRK4 gWu3SisOx7vPHaHgmcrPUVEdMFIfav7o813OUXDDsc66YFzlwoOeEorcJf2fQXqkAuIwQkCyJgsX BHG6kBqkbaEMn5u5vOwKdVO31s7m8Au7Me7F+B3T1ArTIb1KFkvda7Tnd47ne+7rdy4AkwzmqUMB nDsZH4C69cHSBtIUFsAnJSIyj8OlM2zfH83FzWzra+6ph8zBFp5cmYzp/3krJh2kX07sJHEdLJ23 C8EarF4fIWvSEzC+1f4TJqEqrs7o+k7IIF3OWgzwO7zfRnACRLxGB48B/lNP9VJPxGp7AJZrBBO/ OGChvi0LI60OCyGbAcFwXTPSMS2y6G7usLTexbH7tUwPu1S+8iw/0BmK6cshvC/O5MdLtQRRC327 qiXyqFYquCTh4SVS9ExQw9XrzKYs9+Y897qu1LcrAA5g9XYu9Zyf+VQf9Q4gAYryOgbi0nCRwkk7 qSsx9u7yNfectJXC+CHPqZE/1DO+9BrM9ELg7cHTnyD8uRkKzw8vBQ9TNAncFClMqfzwHkAi9kTw y+1QLYy/BBlNzkNduLNLwbce49asliEw9Z7/+Vi/tmskAYxsruC8CtMA+ymrDHpcH8fLGgAdsYOu rvfs7JPB9k8gztyf/vJrfshAQBIChMMiiXgUNpRN5xMalU6pVesVm1UyqQZFRfGtfCoZilZoAFSK lcWkAhhVJoAPxQLQWygfuYLEr4LjDVCIA8DiQ2HiowixkSrpSE+p0ggTiZJoskiv8vMTM9Szikvp BEPCgbXV1VVC4uCAg+zB4Owpw2JE4WOEhGIEgOPE7sNiocLNwlfOb24ko0hBb5EDWAh5gQMtc7Q0 czLpspRc06lz/OnU2/0dPl7evT2KwuBkmaziIdfbsciJLxRO1CIxhsSIRXHAgDGgjYMBA8XaUMjA gcM0IRQaPpxnZV06fx+P1NuoQNWqVw5ixZr1gUwGiRRGOjHwwSAJ/i9lSCjgACimwy8KcOE8ccSA TJxsqIHRqCXUpXLoqKrj1IRU1HNIRH3bQhJsWLFjpZh0co9mWpr4JJL1BMjAhJpux3ZNR9dssBMC ZsWy4PLACIXLbqmdSxexvJBYD7/LmxhyZMmPNz5UGwyzzraN5TGaMIKzZNFhH1tUwOADaowYlil4 cALX5dGz0djFSpp2bt0fS488QzNY2iLAdxc3burJPYkGXp84IXN5dFyZj1fXTdl69uLYs4TW/j2y WeXSyZdfTh18etzq2efm3h7+d/Gbfxtei8vyxt/x+Xt73x9AegIcUD57MNtvvyMSRI/ABpv4z8EI oYBQwgpJygvB/gMzE26j4IizMEIKQaywgRJNPBHFFFVckcUWXXwRxhhlnJHGGm28EcccddyRxx55 HBHIsoIcUiwRiTxyCSSRNFLJJktyEsoJowSSySmXtBJLEqrMMjsKpeNyRC/bOg9M/rYs07j/vDgh hDZDgM0jNAmEsK3K6pRTvTPxdG+K19x0swI3n9rTzCriJA82QgtUtNAo2PwTUjcNYbQ97u40L9Es crKCKUqF9LRSRyMdtc0KvAP1OikulQg68k5VYgELpuhGm2yO7GQePVFF7DEDSG1TgUhN3VU77Dxq Kx/oxvMiTioqyGPQJk6YwDrbPrJrqk2myjZJYsF7bK9ZAis1/oQSQmBgBAYEcPOoKaa1YIJuOJjA AlqPeLeNKHEtMopjJRqKLem+aFaKEYzJpqAvPiNhWm4qKMgRnLrBiagReDlqkIIUmWcxjjXpOBxw qCpCV2/HystXAWBahgE3BRhsGUBfPbgIhZ6Io9bZuOWW4215zpbnB/tNQ6IyzMOnAoKhMACYOoSY 9hg7mG6GIHoDsYOEeUlQBA9qT4i1gmGUhooSsK4q+zZz0CbZ5EWlDWHdpJEW4GUGFIANgjbpHtuJ PGrmu5ricN2KpKsIH1wcr5yg7KHlMmj1vOXy4bsJbOZd4xBqt5ZX1syF4CXroyY4ymIh4h2iU4/v kmrwszex/uQutUPutm3r8spg3b2FyCCEwJLW6c8PooVCECFs/WACOIQIHOKDfgokooSfdWSE0VX/ Zl94XFdn7Y+7X3zo6J6Q/Hcq5ggDAM056Px0rQ/p3A+md68e3s9pBWBSxaBgPXGu0uH+f1L5Xslq d6EnwI1uAhgWRw7wgaOkDG69y58U0ncQgFQvIUlgntW+1g2GxGUNiODAs2ylve5l72PkaN3IhoBC ABrhhewI39EkAqfJOQsgGXyI++qVNVlRy30kiJUhAHCG9Znufqkz4f5CRjgWwnB2sYuhlgpou7Mg kG4HAARBwHAG3CWQLxOMwjBOAJpDRCwJOMua5nqIBEAc/hEJbAjiErH3BP5VpYX/S9vsXPfEryxN MzQkH+XaYIGNlTF9dLDDs5rhB580DCBwNAZMkrEMsPnBevFAYRPDMUWRbRKPUSRgFeUhHiwm0DLT MQAY+aJFK2SAGLZi2mc0mAQ4ni6OaxzCGzunyRPakZMjy14f98U9T/5xfJq5B2wy8ByBOKeG5XPU wHTSETA4xyGBcIQBrrmRpwzCVIvIwEAaoj8KBhMdQEun4qLoRNqRcje3OwBf+MKakfRunvmUxhXy kEPlBa4ntmQjMNTAy13q0px1jF0oj7mVYZbtmE8C5HLCEAYwhKGGSCNkhLQCzP7lsZjYgp0feTZK eDpG/hetFNcB3uQcfK60gRtVQvw8MYc6OHAYxZjAAhwRh3olsp+YVGQO34E4P340JOo8xyYPx05k 2kQz+XjNcm7ROI3uCmSeeBUWTHpS/yTnpTDFAEwPMNYDSJMKHEGKQcbAEQXIpJskeJxc7zYwi3rh bgn1BCgXY5UnZiUq4ljhFBgXSLmRRzPLkCmarPW9Uno1nsnJAFkpK656mcFkWR3CVgW0tKSI4WgZ WMYJOAvZLHTVtFxdWgUqS1ZeoJVYjY0iv5YmkIraMDr5wGhpU2sF1PYWOVA4wQdaa9kDMIC0wIUM 4/Ah2otW9LbQVa4BpxseKFhEZa01ZGAEsNjqwoM7/sqBTXOgidjvxuO35wXf+AQyhhFUthbX9K56 tWApzBwtGDOhb2f3ezL24uM5+oDJyggjk0z1lzcGssKdEKzaBpPGRxGW8IQpXGELXxjDGdbwjh4M FgxJRy39MEx0eNthGZp4NultcGkaN2IPoWUtJUbxU2e83Bo/VgrAMcyBdnxjNKjYx+sN8leHzKci 4+XIP05yipdMFiD398lNFrKUqUtlKkTZymzLcoK3/KkryDjLWC4gKIncZSl1QSIQgACZzOzl2Syg CvRqV0CG5xagkfkKtpHtnafcZho3Ic1qFvSg52tlypyhcTpRdKIZzaAoFG8KalCi8iQDQDxLwnuh /uzkpv/s53cCes2CNkCoB71mTwvtLPcRpHniXEFJiHE0Hbv0OWX9yymK+bwfLvWuB02UKxgAXhYY BL3s1WGUrVqQcxbuL4p4xmkBY15MsUPypjEIQ9BhBA/BSUIofT1L+w/ce/2rC209wFOjGtS8VjcE YO0oVzeDUbNGaRMQLR04BYyGB34CaGDpCAogggzpU0DpkECtEcC5gwcBxgfgHIcJKMCQheNjHsGd 1GEWc6RQFOW5O92TL1yA3RWAwDJEvoyRlxwCWECEPtQTtLr47OKWuPR8JFdVaJaXLbC5t0z6VS9E dE6NPQQo5iS9OSEuBADTwF9AJa7QvioUdp40/qa5Oa5lJXBTHxW4wD5M3nWRhyELeShhGUEHvYTA m2EWA8a/47upa0XGcB8V2TrdjBTJOcc55LX3vQH86EUMPOlMJ8Hphk5EQJxODhjhwBkwB1Bvo+3p wpQiO6e+8ap/+mnLuADJNU9yi4pBsViApeYYlnQ19DSROy29TKQ2DDJksumJ2d4vZedUqysIUZLD 9y34zk1C9pJmQe/G0B1hjIf0kKdPO8rSHa/XpiKV4rLr40iTiu6qmyUfnO+81rmu/SzsAnM6kQse 7gcInMWFJm0cRgljD5KKrzCkHq1jRG9vd2Qf7WFQWL+2F2CH9TMybOSAAhIhbHpqiPyADNBo/gIy YP3e7nXQya9CChQCqyoGq+P8DPu07gI2cAw+YANhYgNDcAyG5QqAIQ88Atu44aAAKgVpRQ34QCzk TdwqrpNiLuPmz7E6jSDurzyyrzF24tq+QLTeagjbSyZEa4Qyz9cGASAARgiPQ7OQAMyiANe+yyy4 yQNDcOu2bsC0ECaUjQooYvR6gn2SiOkgDomEAAzkIAazIPIaSvJukJjqrgi4KQyc6W6aKQ+fSQ+z 7wMeAFRky/b46/qeYLgGDBG7MBFJsAr2LwP6TyFC6A3GIH0Y8BkkEQ4ODpFIzwHzLJjgkO7kMA7P jN78MBFPcREfptAQrAqr6zF8IRG5EBHR/uUDCo0CKkonwmAajOLf7FAB3GoXi+HfxgkQdDEsZBD6 RgFxloqJGIqwrku8ck4adS5gHG3IWnG6KGO40uUUGcByYCtIkFHTIhArRKGjKlDmriyt9EM2hMMf pjDXLg/zFOQL0EUw7pEbwdFborDZ3KJK4HHGsFG5ekXQxCABW4PQqkgQj6rK5DG4Lg9l1Gw5eC06 1AwiHfIKBBK4jm05loWGChEjHxIklcAfWizRQlKiUJIOTw1D6uNDMqQ+RlIlSVEmZzIjbZIKHVIj k2wnTawnTesnrxEnaZLjNswojxIpk1Ipl5Ipl3Ion5IooVIqp5Iqq9IqrxIrs1Irt5Ir/rvSK78S LMNSLMeSLMvSLM8SLdNSLdeSLdvSLd8SLuNSLueSLuvSLu8SL/NSL/eSL/vSL/8SMANTMD0F7wrT MA8TMRNTMReTMRvTMR8TMiNTMieTMivTMi8TMzNTMxOzLjfTMz8TNENTNEeTNEvTNDWzM7/GAxaA NVezNVlzAVwzNmFTNmuTNm/zNXNzNnXTNnkTN3cTOHszOH9TOIuTOI/TN5NzOJXTOJkTOZcTOpsz Op9TOquTOq/TObMzNVeTOxUCNb4zNRiOO2dzPMuTPM/TPNMTPddTPduTPd/TPeMTPudTPuuTPu/T PvMTP/dTP/uTP/9TPlPzNtmvCJAH/junMzsRVEGtM0EZdEEP1EEjFEIntEEp9EErFEMvdEEBsiud ozzNqAkcYaf8k0QB1ERLFEVPVEVTlEVX1EVbFEb3k0O50jmA01ZKpAjoxZAsVEIzVEJpokc1tDZp QkgplEh9lEeTtEHTIkibVEkRdEa30kPJUwNOhIrk6hcsYDXVQj2B9EXJk0jL0zDyM0y/1APGdD29 NEa7lALElEu/FEjLND7RtD7DVE5dVE3vtE4pwESjVCtrtDU1gAw8wAMgoAF+IykMdEvbFDYbdQHK 1FEjVVIn9Ugb9Uhlc1ItlU+L1De9NDkr1UmZE1If4kmN01Ojk1R/lFGR9FM3lVNf/vVM6XJKPUBQ KeBQtaREEDUDJoA7zyA20fRNY4NRccEDDOBM31QDPORX0yI2NeBRhYg7cSE2pVVY+TRWl/VIqZVQ hXVa+dRYe9VasdVLXbJZPWQ1q7VcmXQBhHU1k1U4xvMMzJNdF8BdiZRY17VNtTVOmfVe79VZhUBe 1RVdj5UEjrVbmVRai9Vb8/Vc1ZVLw5RbFVZdnfVRrTViKXZeV7Esa3Q1R4AAVOQ+GoY1fbViR5ZP SfZZTdYDjsBgS1YITPZZMRXOzPVlY7ZmiTRe7bRNWdZXDZZlYVPHTpZR4xRaKxVmb5ZPa3Zkhchl mVZpY5VZU7ZpafNlY3Vli8Bg/kn2an+VaVnzaWO2Yrc2a5nWV0kWSAHWZrE2Nhf1Wtm2Z4kUaTW1 bR01XsP2Lqd0BEIABHJ1OO5BJ3a1V4u2aE+2YLn2QMC2beG2Q9q0Zy0VWmfzXWfWbYWobol2Nkly bgMXTAcXbCtXxzp3Zx+XYH9DchHXcIMhVg8Xbbe0cOO1aiX3dY+1cb22cMF1WUG3bV+2cgu2an11 dSs2OBAXZ1uXcTm3NYcXdR13OGZWQGPlAzygRMYJehsAP/Bhp5aWdbP3deu2NV8XbV33cWlXN7WW dqu2d4XoZW8WfQtXai+XfYF2VaXWd52WcgsXYM93Zl+Te2PTfMN3N3X3fcV2/mkHGG1TtoCf9YDn doANmGzXV3uhNX0bOH8XOIKBdn0JuHXfl2SHQzbJF4Fl9QRWUwA8QEtRBD904gS0lGtX+FpXt3Gz l4XnV0xFl4VZOIJX834dOG3dd4bR84XfVofBl3+DmHdF94U7t3ZvU4jhVYPtt4h5OHZLl4nddIhL d4lveIe31oUhWIdb2InF9odFN3aP+G5Vczb1wEQix3qXNhgmeIPDdHEnWGprlh1NdlNZN3g3eH3V Fm0zQ3wht0MmuIPrw4qfWGxhhY6dlllT942LgDbzg2mvFjO81mH9QZB7NjhcE2U7WFk/uIq1WIKZ V31zQYA/2H6HF4/p94+z/teSczMXwHc7dxM01KJ6rXdNzfQ+6/aWbXOXcZlQe7k9j/g1e/l3gVlF h/k8m3c2s208AmmNGzVUYRVCX5dVoZNipbmao1mbLTibr5M4uhmchdRPs3JWWbMXnAmdnQNwffmY r5md9TNSjblEkVme35M1r7me3ZOeXdQ3x5Ne9zmV45JjYbN6ksegD5peSvVJJ3WbqxmaFdqh7/mh w9lBJxqbNdSiGxo4MxU3xxkryzmfzxNJ/dlRY/Q1r9mdJfo26/mkS3ql//mh7ROlIZo2Z1qlK1Q+ WzqjKdSmYVpmSTqg4VKdH2ecnoOojxqpibqunmmpm5qpn9qpoxqqn/px/qTaqqdaqpO6qp3pqK/a q7EarPNQqcG6mbo6rKlaq7/6qpHaqMv6cdq6qNUartd6rOU6q9sar816q53ao6/SObwRIwCbA7yR AQrbsA1b8QJb8QSbsRfbsRUbsgf7sSV7sAGbsCPbsitbshsbsw/7sDe7sB2bsymbtEfbtBcbsTNb sT07tE97tVm7tSebsy+btAMbthE7sV07tHN7s0E7tktbtoNbs2H7sWn7slOTAQZTuZ3krxnmNJ8b uqNbuqebuqtbMZHbua1bu7ebu7vbu7Ubu79bvMebvMvbvBkzvM9bvdebvdvbNNPbveNbvuebvq8b hJO7vvNbv/f7vOHb/jEBgDQBnL/3W8ADfMA9078LMyqMgcEvc8EVnMELPDILHMAl3DMf3DIrPDQx fDGTLsMh/DA9/MAzM8HxzsKd48QlM8VR3MQpk8IN/DNXPDNlPMQdHMQNk8ZHHDJLnMUhXMA/YTJP PBQiXA9UvMV/vMgb/MeNHMeT/MWNwckjHMqRnMKTXMWbCcWtHMiNoZm2HDIl3MO3POmGXMcnk8en vMg1/Mm/XMyPvMGDXMnfXMPjfMLJ3M1Z/MWjfM3nvDL3XM6l3MUXPM//vMwj88wBvKylnMP/m6sZ vMulHMsnHJYeXdAV3cgTHZaAHJa4/M8HPcuBXA8i/cpRHMvHvNQn/t3KJ5yrxzwUUP3UC33H7zu7 cZzWK1zUVf3G1bzP49zCdT3HazzX8bzHAZ3YUzzVv7zFhV3ZoZzJ8VzU+fzXYR3vDj2ddf3Rb73D q93Noz0xER3SHd3DJ/3SW/zaHd3cNZzSncnbvV3cR13cXZ3Uw93cH7PA4d3Vw13EpR29Zb3ba/3T g5zMhzzMuZ3We9zL1xzZm1zLFTzKDZ7K/93FGb7Kw3zK4TzZ29zO9X3f57K5E/PWMb3RIxPkRz7k JTPSSZ7kRR4xUx7vQF6dGx3l01nlXz7mXZ4yaz7p3lrjG/PQFz3Dfd7BgV40tcK7ib40tWLFCX7n z5zmZd4yWR7b/k0e5p+b5bfb5kcz5gsz0XfeMZme678e7PXb68Oe7Mt+vcfe7NNe7bsb7dfe7d8e urH7tuee7uve7u8e7/Ne7/ee7/ve7/8e8ANf8Aef8A0bu5cb8Ymk4+Ge8Rtfutve8SNf8ikT8ie/ vfHb8tme3zN/vQdOABYT8xdT8ziQvT9/wM8c9B6m8znvM7VP+4qhMV2f82AfMtuEAPJhABwA9Gcd MTdvzUZtA9U7BAjA9Pe7xC/KtkjOvJHfokZLM5VoIyCAAy4g9s9C+qn/MYefALafADAAA6J+8RNz GdJAIjfvvEOAAopf7Dcf71R/nLRPeDATuTzT/VN/DMA/MqE//g2mH/sVU/91Agg4l8upaDwaQ4Ql M4LJII8MUvRYgZAMWi2EWP2Cq4AwuagUKMrqNZutIMHj8jm9br/j8/o9v+//AwYKwhVNWZ0oKFSc GJxUPFZ8RDFQMqgZtoEtJj46QkZmVlXYQXxwcJCN1pWelikxLUU8PGCkVWF+XRhAaFFseR0BCI+F GhEXI76GQIkNHyOPPSMfKWwMXmNna29zd/sVUhlVcJ5QUHh+Ik3BWZLhTheNKy76fnbCq5KUGGQ9 kEBUQBUmH4IAASAE2KVAIBhYTR6YUyCJmZRwuXb1gmMAWBFp0zySCSFyJIklGEaKDAZPzEp1ASh4 iylzJs2a/tfAiYPEqJ49SRVxVjIS1FC7afbG8TPwyadROA9EODDgQAQjAwy/qCpo0CCXolUcEogg y5wviSco4gRzAQIvOV2QAEB7YpgxYR3ndrTrbI0SmHCYwKSwJEQwuXTx3p1rF2+0DMOgHFYM8ksB azYvY86seVtadOXMIXnEtFDQcOxOWIozJTWYSpSwHv2sVHRr12rjmBCh2wSXq1UuwDn4j6sW31FK NBlrbouiSRZFVTBgLs69YIuPSYtG7Bl2vmAJCF6Cxnrku93Pb5/L7HymDJU3w48vfz4h1BYfKZCe NAvP0fZPo1YJCbi89twtlNQXGlK+8JcUbbWtkwsJgekm/gJGEBiHBHBxULBVb6koEFYEJZDFBVuL qGPgEQREshYX1R0BhWOOOQPZY3GdheNdkKkBRQWvAEaAAMtQNONZR9bIWI7rGTmjjs7EtZgaBVDZ AX1XYpklZ/blRI8vRvgIyk/2pTagmUINeEmCCr4RmJue+OecikZ8oNFUujnAFgQjkFHndHCwtcue qZxYAVkScaDAic59ccYjQwyBIhjRwGUMYpdeOhkYQJoTggJyYZqpeYkpOSqp1qmxgapWatmqq6/e 0Vk60mVwlH+YrBZOrmiipsac8RylwJeQxBnFr0X4+RRvJuTJVoZHfMDPVgnpCQEDoFpR7XIfjDCC ogAx/hqFSR+kge0XUcqI7pI4GknqGOZGEYIBS5gzGKjsdpSuvkvmy666TeL7LhkZrAqrwQe32tk8 nYC21K2lBYhgxFz2Os3CDFNBbLFtcBBYVYKyxWcYdRqwFS8HhUwoQIb6wu0IV8DYmREmCSApGXvl hR1d3OllKRshhCeAdEKyBFdkPOPYnWI5M90jwawiHLXUmsn8wSf5zWa1V0bIwXUcRXwdTgbHqmE1 JFrAWcHWxXCg34XVigxG2yVPu4GecWuysi+ljMABzDbLfMK4FWQALxIyHom44omDyXgRhiORhpDL CJCBYAIcfmSMjCP+OOefL754GVAo8NLUp6MuU+Bm/vekNuAtrcT6IqK53lLHW1R7NxlzH4TABgjA DUEZZ2thitUXjBNuEhhY/QDsz4dEwpDMKAA05tBjD0YGwqbevfc3UQzmB2ZbPT4Dr2dfzPi0m49+ KHNzAXLIwsuNe+4pD5wB8lrMk0hrz9XKap1LX/o8pbnCGZCACnzc9xroQD4ELh4foAQHxrfAlkSC ghZ83ik66EEGjACEu/PgB0OIt1TgR3P/i0IGnHfBF8IQhg+cIQ3nEMEY4nCBouvRkYRXOMgh4x2b yyERi4iMGiJxhjc0IhObWIZGODGKUsRhEqv4vSVOMYsEhNwAtejFLxbDimJEHThcY8YzojGNalwj /hvb6MY3wjGOcnwjBxhQxzrG8Y523OMc++hHM+oxkHz8IyHlOMZDRg0ciFwkIxvpyEdqCYs4LCQl K2nJS2Iyk5q8JNmyB8lPwkeSMWSABUppylOiMpWqXCUrW+nKV8IylrKcJS1ractb4jKVJ1DRH9Dm K1AC8zKihCEDJhDMY4ZyDRPYJRKy4DtVQTOaG5gWP9aAzGt6Y5gvJCU2u0mTXeqBlMw8AgkQYE5z /k6a0NxKJ73mzXcGQpsXLCY866mNcYahmPgE2+/O6btnqjMABTjHL+1p0DzIc4HcPChDv9FOcRqI BP1Ep6ogQAFpGqQAJAAiOBvq0a+FrwzZgR09/j9qUjvs8wv6jOhEAwBNv6xzmgO15kk9GkEpFSan K1loIACgDZ/CAag0EepPG5rSW1ggpRJNpzTjMM2tDNQw5ampTUOal6L5bKfGFARRSSDUruLhqzYB 6zXI+s6jTmKZLFUnNOHQIagaaDJUNapVk1YXYdgIr5SSzF2bJhQLDKKrYuXDYIfaDbNq5gH7gNU4 oSQliDbTpWxVVRzgijiQCGOuDA1cekSFHndhajIl7ekwgprZ0jojDoUFKmuD6lXXvra1r51Dab1a W9v6FLVfzaxpeXtb1fp2tqntgwEekIAEOMABAxiAAxhrEShJQa2RVRVZqjuHjD7HI8TQ7EE5/ssj gIHXXzWSEl4nAViuqna26h3samHbWtnm1r13iK9riQrf9eLXrGINrmv9UgfFJoBZyx3wgJv7KnzS CF+oSWpEJetfO2CXItvRKxS4a1CZOdazllKa0eqijq32NL3tha0c2BvbE8c3xSemLWpFXGL5Qim/ ZN1vekkshwcwS7kE3vGAJZDcHwM5yEEuwQBmklIdCUW65JTsZCuLXZVsGGwWrieGE6cu9TwJvPz6 Lr/+GlgXk7iwNRYuisusYvqOGc1oJvOK0wxc2oJZvSC+cXIlwOM7+1jIek6uCUyQAAMUWXUG6iJk lzxZy5BgWhpVnL+MNGUqh5Q7OUvajcjT/rTyFGLOf6BxmGs8Yvx2OtRsbvOa78tp9bL51EIdQR4M UIIA65jHJvCDfwMdE7R+WKkGYauT4WoEKOKMt4/2psxCB7rPec7YXSzEeUPsXtbm9rayRfWnqw1c YVBguLhNdW+vHe3V8re3mr7DcozLLDsz98F9sHU2H8rgyDL5pcGZlkApoGzGDfusVo1ChrM32pkg VsygRCy5J0QCxfIjEOzuBq6jq9QC7DqaWKD3kwua72sO09jQ4ynA5ztmSP5WEOr2w8K50fC/6nor 03wqxSOswi9cvJsJVeC/Y+69knPmjUo2Qoeo1HKKU4mgUASDzTG+7y9wtBgcL3rqcK6N/lmmVAsC pRLVq251y+3QWEwP5swJuDYwgj3syBhAFg2khQlVlyxyqO7QybB1rh+diG//ntPjw0IZ/RDv94bc 3EFJmk0CPvCCHzzhBz+AwiP+jX3/pJQXT9W6Oz7ykp88HyBP+ctjnvKWzzznO8/0zXs+9KLnLuhH b/rTM7T0qF8966+p+tbDPvaNfL3sa297JNL+9rrffdN57/vf0zD3wB8+8eUj/OIjP/k0Ob7ym+98 bDD/+dKf/h6iT/3rYz8O1s9+TWdx3O+DP/ziHz/5y2/+86M//epfP/vb7/73wz/+8p8//cm/WO6/ yrg/rj//++///wNgAArgABLg+Z2b/gSYgD/g35WUQHL92QJingEglwMoIAQmVnJVoAVm3gNgoAZe RgJIQAl4YOhRQAOK4AjKBHIlHAp6ngFIQAKwYDeoYAyKnlScIA1eQwPi4Oi54A3u4B9wYAb+IOcF 4RD+gQP4oBFyng4q4R404Mg1IeVRAAVGYR5QYRV2HgdioR1o4RZ23hV6YRwcVxhy3hiSIRxExRli 3gNIgBp2oRpengSsoBeWwKzB4eWBoRea4R1OngkkIRa+Gh9S3h56YZ8J4uQR4hYm4iHO3SJWoSMy YhwgYB9IQCXeoAlU4qyVQCVyoiXqQydO4o2h2wumDiQ2oSlqAwNAyTp4Q37ogQVw/gAJcECz2RDB qcYC/EGd0IEuJtEDDEAbVt5yGRgJ9BgJJMCdweAx8ljC+eIvohsMng4qGqE0YoMqCgUAsJo3jMEr TgGD1MFc8AEU3sHSDQgt1pAvAmP1/WKgoeMvGuMAQOMcHCM0TqE7koByKWAzog41/iA/DgLHKQAA +FdA5EPXkEBAdFQW2NHXAAAvysEEvQEJwKJGUIffEIJQJeQceOMKdhRBxsEEbKMcgCQjyEHC7ZLa JORCOKRThOImGtgmeiIJYCI0YmIlaoRNZoGPzUGs2SE6moAwyoGOpSExMtcA+MMxKlcbzmMdLKUk GiUJ2JkD+MUs2IGOSUAFWuIA/swaG/7iJtphTPgjDoZlICwdAIyCAQiDBQibt5klHICkWrblMLCi aamlMVnAapxXWmYWOKLluKkGYPHUNo4AAMDlgPyWKgrDB3zVGxDmMKiCWsLlHBIlHKAbGq6jgS0X MGZmoP3kUyKlHESlMopgM75gVFImcyUlHCwXkc2anRGZUv5i+MFBU84mPOpDj5mAOIbmaqrmgJHI cgmYPYJlPOohccYEA+CiHNylRJ5Xtq0kYcJBKWUBAETkYAZVRkrnRgnkRM4iCSimaqUBAPQlHiCn LDZbXHjVY8IEKakbe2YbP1QAa53Xd34nHIyAOdqZPwyYfg4ABSzXwQ0YgCKg/lZCJXAWaAYaFxz8 JAzqY28KKBrmJlH6Zxv+Ijq+I4/VJnE2pTIO2FeKIXO51X8SJU3apkwKpzeMZQym6B8s3XJSZxzc J22BEzepYontUkiC5xwsJzdZQDYy5FrWAY2e5y5BZj6Q40Jho0Ru1YteJ2SWEpAeox8WJQWCKD4q l3LVITxO6IS6o4jKAQgOGIMKZ37Spvb1p2syl4Ui5SywaYZ+aYnCBAfu5xzkp1Pyp1/U6YOmoHFi 4Yr6QVmOAnrCQXeW2NgMCC4S6nV6laGqFnbGYndOZNc0ZkTaATclakgi5ouW5xxs6ncyKY7GRSmR kEb+onIBmo8NgAgSmQPY/hmgsWp/Fug8KtdngmZszqqeHmiZ9mY9uqaaaqnBfShx4uPBnSBM3Gqt YuVTemmeWuienqGf9gFAshYrWoCmYSpgxSdDwgSOBhUvLtNEctMENJsFCaRiimM5ouuEbKMuUoB0 Hul5Wme3upVPiSuHUKpTLlc95mtvptsoKuiAudqcxkGzLigFNKiEriocNCB/3ma++iqfviNx5qt/ DsAKHitulOhkaqyJ2uFPpiOKQmwUQisfWGMRcAAAxKJhSsJgZuS1BlVSBWRedowcnOwiDGa7PqoF nAPKnoBiEg5QLcB5ZeShHmRDKoBajg1hbg8AGJM1cmpIqqWPCsM4QOdc/iRVfI6bMkolkYGoZabq PS4XNALaL5rDgMHEf46tYoUtgKZpao5oM54trGamwbrjMYLiJNotJ/Im2GolmMJqnVJsAnClHXop xQbnx8pgyJ6i4qYilKQsOwzDvSpquhoAXILYWz6tMLzBjp5XQAqDIQCVc3pVRi4USFLnNnou08IE WgpkSWJb0fpXQwoDiKWuX1LsCe5tw8bpvp6mgZmmxvKkO6KjVfoFBaDb12qsnW1l3eLZhfZYBsYa 2Z5mPh7vV3rpwdnZVZ5o4j4r48ITKnCqOWaDuTaqHZwrHUChf50vsKIvRLCvwRWXus3C+qrb+uLB /J5v/JKbfzXrcHbv/kn5KOT65T82pI3GnP3qwWvOgp157yCMrAY+MDJlJzf06BwsgGSK3vFuL/eS YQRHogMZLEQgsCB48AKW8Acz1AlznwqjsD2xMPa9cAu/UwxTHw3LMDbZsPTl8A0f0w47nw/zMCgB sfKV8HJmAzlGajbZoiAUZk2A48GsQ6J6Q3c+MR1UMTaspLN2cAPvwQiHk/gasRLfGnVisBgbzBOT 4zYs1NBeZCqKr/9usTZIB0VWkB0YgB0VpAJYwqYeJAPgrFtJRByYQkJC5EMmihX71PjMwQQ5JAUE 8hzc8eMqZjkYZNjAgUdSpCXvUpm0sSLbqy5aBSt2VEetoCncaySX/uQd28EkmycFMMBKTtAo9zEb H6RFmichUMf5tDEu04EeOyQ/vPJHCqp3cvIuga8Dc/EOFvFq6CVYxWdjbtVbpiVdfq5haq7n1iU1 Z6NeBjAVQElgNDPkaq5INqZZSsZcMql1sm4TG/ETpyUtSoYwAHPkSrNZZhtMzMU6xGVjZqMqwuUo KEYF16JdIGYTYzPT9tbU0kE4c5M7l7M3B9W4QebrFnRmZSoJHPSSEuYb98EQJ98yG2ZScKtXpWxA TmfCQWd9ouWjfpUqvOdcwEQGGBNMU4GmzUXKSmeMBtXYnCwdoGV1+tQVu2Ve1kl2im6kunM3e/M6 uCtQ/bR95lad/pwsYKGlN+OzMaFlwpn0XEiupA6qeE5n0ro0WEMncy7yYlJxIi/mXIznWcMoYJ2s SBuzzqbnvPJDkmKDRyMfSAfm0J4DKflUjdonYAk0Saer1ZoSAEzB7FIqYyNyHJg0IXzASKarHAj2 dQo1RvsUWm4rpcZoO7PW0FaxSS/UZY/ud/aoT+m0YxvmKW0HHqDxkCL2ky42OEmxRHZzQ/tUYV/k 6+roRhdmX6PrbKtlbWeDXhdfCS/AaiTn6M6B6T7pLbMDLiYxdwotynrQLlGA6bbudg/Dg1UxOD5z tW7jbUv3dTpGHZhlvA4zpKasOzMqQ8r3pvLx6GabV6HlXLg0/ndTwMmS0M7CNlBdakeQ0I3atjkm 8aACFjgudy2qZVeLqgedN3qmNQklLS37AXITH18PKW35RXxSQLZGp87Wa1Dh5bx2pDmMtR+rAlrO JU0bplex6zaSo4hbdWaTwH0WsFdRq12mrIiPtFVDbrraOE1j426DpFu1uGKDOHVAdKwAVV9nW4o7 d2UPtSBP0ILT67hKQrm2rkjSdRa8gXBz05Q7eZVfg4YPH4eXbxysdM/6VlJNtXaiglrmbByo5SKo 5c6iQnwugmI7Qlv+qCKgrFdZQK3g1XmX2AIgAgDgIo6zrmo05AmwLAmAJKGHNiJTZ3zGYmAeesxC tc6ebOvm/nOgByp1eu6TUwEiv8Gljk2en8CeV/ltl7rPprU3o4LPPvEEw4FjXC1CD7gsbuMCmLOs BzkgqDnwsfnkSrrmvmjlEuZ9woTn3men0yJ3R+SoF7o1bztDPnNJO2aSmncWWO4uLzQtZmpEtith 1meQ63c1V/a6I/S8xuJc8GKmpiy0EyY+f9XQJmawW3rkTi45pq61P3nqgu68rmTtskOHZxtYYzuz I/P/ykf6AoIX09r7/lRBJhEnfxLGd3Qyi6XIX1wFqOUhKfWwJfvvrXwwmXwZiyzJq6jMB7FHtTzv 3XzNV5GfnWEg6vzF+eEZvuHPP1oebqFUEH2+DSUZLn3S/mvW0Idhzjt9A0n97kH91J+U0Yeh1mN9 Q119GDJh15sU12/9H4q9PdXhIRbh2R/U2gviE7K9Pbn9ISKXEMY9MhmAH4J8FDYgzN89JLEhzQNi CP59D5M9I+LY4Re+GHFgAv48BzqA4C7+IRmXj7lv0usfnxXg5nN+53v+54O+559b5Ns90a8ugIV+ 6qv+6rN+63f+A/j95Mv+7NN+7dv+7eN+7uv+7vN+7/v+7wN/8Av/8BN/8Rv/8SN/8iv/8jN/8zv/ 80N/9Ev/9FN/9Vv/9WN/9mv/9nN/93v/94N/+Iv/+JN/+Zv/+aN/+qv/+rN/+7v/+8N//Mv//NN/ /dv/Cf3jf/7rP/4FAQA7 ------=_NextPart_000_0007_01C71393.C9E53330-- From ospf-bounces@ietf.org Wed Nov 29 15:15:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpVoi-0002jK-J0; Wed, 29 Nov 2006 15:14:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpVog-0002im-Ny; Wed, 29 Nov 2006 15:14:02 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpVof-0004eE-9g; Wed, 29 Nov 2006 15:14:02 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-3.cisco.com with ESMTP; 29 Nov 2006 12:13:47 -0800 X-IronPort-AV: i="4.09,475,1157353200"; d="scan'208"; a="450038177:sNHT37141518758" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kATKDlkc007321; Wed, 29 Nov 2006 12:13:47 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kATKDidE008775; Wed, 29 Nov 2006 12:13:44 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 15:13:44 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 15:13:43 -0500 In-Reply-To: <452C0A97.5010501@cisco.com> References: <452C089D.5090204@cisco.com> <452C0A97.5010501@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Wed, 29 Nov 2006 15:13:43 -0500 To: Acee Lindem X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 29 Nov 2006 20:13:44.0077 (UTC) FILETIME=[DE968BD0:01C713F2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3964; t=1164831227; x=1165695227; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Fwd=3A=20[mpls]=20WG=20Last=20Call=20on=20draft-ietf -mpls-number-0-bw-te-lsps-02.txt] |Sender:=20; bh=52IPIdryCAUvug2z2zcTWmbAp2unYXDTdGxToQmF0iY=; b=HRnQXXG8rXPfGsQCgREYdYyldVDj/kf7mBLYBDx7tSdq9hGecywYLYEaVNeAicE0xLVAyuh0 e5X9JbNpvpki/ZLErP4W080Lykov7T0UZHKow+ffzxhcc8IPTTmg0/pc; Authentication-Results: sj-dkim-6; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: George Swallow , rtg-dir@ietf.org, isis-wg@ietf.org, ospf@ietf.org, David Ward , Loa Andersson Subject: [OSPF] Re: [Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt] X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Acee, Thanks for your comments - As soon as you ACK that the changes address your comments I'll post the updated ID. see in line, On Oct 10, 2006, at 5:03 PM, Acee Lindem wrote: > JP, > > One more comment - Please write the document so that it can > apply to OSPFv3 TE as well. The existing draft can be an informative > reference (draft-ietf-ospf-ospfv3-traffic-07.txt) > OK. Text added: OLD: The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST appear at most once within the Link TLV (Type 2) that is itself carried within the Traffic Engineering LSA specified in [RFC3630]. If a second instance of the Number of 0-bandwidth TE LSP(s) sub-TLV is present, the receiving system MUST only process the first instance of the sub-TLV. NEW: The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST appear at most once within the Link TLV (Type 2) that is itself carried within the OSPFv2 Traffic Engineering LSA specified in [RFC3630] or the OSPFv3 Intra-Area-TE LSA (function code 10) defined in draft-ietf-ospf-ospfv3-traffic. If a second instance of the Number of 0-bandwidth TE LSP(s) sub- TLV is present, the receiving system MUST only process the first instance of the sub-TLV. see below > Thanks, > Acee > > Acee Lindem wrote: >> I've reviewed the subject document and don't have any comments on it >> from the perspective of the OSPF WG. However, I have the following >> comments as a member of the routing directorate (copying JP): >> >> 1. Why the cryptic sub-TLV name? RFC 3630 doesn't define short >> cryptic names for sub-TLVs so I don't really see why you've >> defined >> NB-0-BW-LSP? Why not just call it the Unconstrained LSP >> Count sub-TLV? >> Or at least come up with a better short name :^), e.g. BW-0- >> LSP-CNT. Yes, no problem. I renamed it ;-) Number of 0-bandwidth TE LSP(s) sub-TLV. >> 2. How did you arrive at 19 for the suggested value for the sub- >> TLV type? I checked >> IANA and 18 is the next available. I may be missing a >> document though. As documented, 18 looks the next one available (when I first wrote the ID I vaguely remember having seen another ID using 18 but I'm not quite sure). Let's propose 18 and will see with IANA. >> 3. Do you want to reserve a value (e.g., 0xffffffff) to >> indicate no unconstrained >> LSPs are to traverse a given link. Let's just use the value 0. >> 4. Nit - in section 4, replace "OSPF LSA" with "OSPF LSAs" and >> "ISIS LSP" >> with "ISIS LSPs". Thanks. Cheers. JP. >> >> Thanks, >> Acee >> David Ward wrote: >>> Do you want our WG to review? Co-Last Call (as we have for other >>> WG that >>> affect our protocol)? Do you have a desired date for end of last >>> call from >>> the IGPs? >>> >>> Thanks >>> >>> -DWard >>> >>> >>> On 9/4/06 5:01 AM, "Loa Andersson" wrote: >>> >>> >>>> All, >>>> >>>> the MPLS working group want to notify the ospf and is-s >>>> working groups, as well as the routing directorate that >>>> we are currently doing a wg last call on >>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt. >>>> >>>> Loa and George >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te- >>>> lsps-02.txt >>>> Date: Fri, 01 Sep 2006 10:08:10 +0200 >>>> From: Loa Andersson >>>> Organization: Acreo AB >>>> To: mpls@ietf.org >>>> >>>> Working Group, >>>> >>>> this initiates a two week working group last call on >>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt >>>> >>>> The wg last call ends on September 17. >>>> >>>> Please send comments to the working group mailing list and/or >>>> the working group chairs. >>>> >>>> /Loa and George >>>> >>> >>> >> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 30 01:27:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpfMv-0007Bl-QE; Thu, 30 Nov 2006 01:26:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpfMu-0007Bc-GG for ospf@ietf.org; Thu, 30 Nov 2006 01:26:00 -0500 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpfMi-0007CB-1Q for ospf@ietf.org; Thu, 30 Nov 2006 01:26:00 -0500 Received: by wx-out-0506.google.com with SMTP id h27so2585154wxd for ; Wed, 29 Nov 2006 22:25:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=OIUc07YmyU2yH6qSGlG38nu63ZKr7hZtRL0z9jm3+A9vvTfMZdZsns8rvQsTIwGlwpZxUI8x8JElsywLNJXjAwp59+VUvIOkcRM5L1QH8ydBRIYlGQqR6rb0cvpBSUSJDa8fIpVbe1ZU2N2g1n5v0SyQ+uW96xnoyLfQctqBFTw= Received: by 10.90.104.14 with SMTP id b14mr3113064agc.1164867947727; Wed, 29 Nov 2006 22:25:47 -0800 (PST) Received: by 10.90.33.7 with HTTP; Wed, 29 Nov 2006 22:25:47 -0800 (PST) Message-ID: Date: Thu, 30 Nov 2006 14:25:47 +0800 From: "satyapraveenkumar pasalapudi" To: ospf@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [OSPF] Query regarding draft-ietf-ospf-ospfv3-graceful-restart-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0677563971==" Errors-To: ospf-bounces@ietf.org --===============0677563971== Content-Type: multipart/alternative; boundary="----=_Part_34523_27011089.1164867947704" ------=_Part_34523_27011089.1164867947704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, In section *3.1 Preservation of LSA ID to Prefix Correspondence* * In OSPFv2 there is a direct correspondence between type 3 and type 5 LSA IDs and the prefixes being advertised. For OSPFv3, the LSA ID for inter-area prefix LSAs and external LSAs is simply an unsigned 32 bit integer. To avoid network churn during graceful restart, the restarting router SHOULD preserve the LSA ID to prefix correspondence across graceful restarts.* ** My query is why is to maintain LS-ID prefix correspondence? How it will cause network churn ? Rgds, Praveen. ** ------=_Part_34523_27011089.1164867947704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
In section

3.1  Preservation of LSA ID to Prefix Correspondence

    In OSPFv2 there is a direct correspondence between type 3 and type 5
    LSA IDs and the prefixes being advertised.  For OSPFv3, the LSA ID
    for inter-area prefix LSAs and external LSAs is simply an unsigned 32
    bit integer.  To avoid network churn during graceful restart, the
    restarting router SHOULD preserve the LSA ID to prefix correspondence
    across graceful restarts.

 

My query is why is to maintain LS-ID prefix correspondence?

How it will cause network churn ?

 

Rgds,

Praveen.

 

------=_Part_34523_27011089.1164867947704-- --===============0677563971== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0677563971==-- From ospf-bounces@ietf.org Thu Nov 30 06:28:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpk3E-0002nS-7Y; Thu, 30 Nov 2006 06:26:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpk3C-0002ix-02 for ospf@ietf.org; Thu, 30 Nov 2006 06:25:58 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpk3A-0007eh-Lt for ospf@ietf.org; Thu, 30 Nov 2006 06:25:57 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 30 Nov 2006 03:25:56 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kAUBPuNp030346; Thu, 30 Nov 2006 03:25:56 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kAUBPtdE012115; Thu, 30 Nov 2006 03:25:55 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 06:25:55 -0500 Received: from [10.82.224.37] ([10.82.224.37]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 06:25:54 -0500 Message-ID: <456EBFC2.5050700@cisco.com> Date: Thu, 30 Nov 2006 06:25:54 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: satyapraveenkumar pasalapudi Subject: Re: [OSPF] Query regarding draft-ietf-ospf-ospfv3-graceful-restart-04.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2006 11:25:55.0043 (UTC) FILETIME=[4CC93330:01C71472] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1546; t=1164885956; x=1165749956; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20[OSPF]=20Query=20regarding=09draft-ietf-ospf-ospfv3-g raceful-restart-04.txt |Sender:=20; bh=P6U8WLhdXnioWfTXWrlqTt1UxO74RwryVVWhSKGY8NM=; b=VKby4RJ6G0NFW+yi/7MgNHODzK/oUH/EflcKEmZ7ZEJYbfRzzubSPWhjV+eUhzPWe2rEmO+B NQPFdU5uHepxCC09WBp/+641xtHCePQOt4O8QJSdA2ivzNemtktVKMVX; Authentication-Results: sj-dkim-6; header.From=acee@cisco.com; dkim=pass (si g from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Praveen, satyapraveenkumar pasalapudi wrote: > Hi, > > In section > > *3.1 Preservation of LSA ID to Prefix Correspondence* > > * In OSPFv2 there is a direct correspondence between type 3 and type 5 > LSA IDs and the prefixes being advertised. For OSPFv3, the LSA ID > for inter-area prefix LSAs and external LSAs is simply an unsigned 32 > bit integer. To avoid network churn during graceful restart, the > restarting router SHOULD preserve the LSA ID to prefix correspondence > across graceful restarts.* > > ** > > My query is why is to maintain LS-ID prefix correspondence? If we don't maintain the correspondence, it will cause churn since one or more of the restarting router's self-originated LSAs containing prefixes will appear to have changed. This, in turn, will result in unnecessary SPF calculations in all the OSPFv3 routers in the flooding domain of the changed LSAs. Granted, this will be an incremental or partial SPF for external, NSSA, inter-area-prefix LSAs and inter-area-router LSAs. Furthermore, if demand circuits (RFC 1793) or flooding reduction (RFC 4136) is deployed, the changed LSAs will need to be flooded over these links. Hope this helps, Acee > > How it will cause network churn ? > > > > Rgds, > > Praveen. > > ** > > ------------------------------------------------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 30 11:58:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppDO-0002qT-M7; Thu, 30 Nov 2006 11:56:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppDN-0002qE-JV; Thu, 30 Nov 2006 11:56:49 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GppDM-0007Kb-4M; Thu, 30 Nov 2006 11:56:49 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 30 Nov 2006 08:56:47 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAUGukgo012783; Thu, 30 Nov 2006 11:56:46 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAUGukYJ005588; Thu, 30 Nov 2006 11:56:46 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 11:56:45 -0500 Received: from [10.82.224.37] ([10.82.224.37]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 11:56:45 -0500 Message-ID: <456F0D4C.2070209@cisco.com> Date: Thu, 30 Nov 2006 11:56:44 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: JP Vasseur References: <452C089D.5090204@cisco.com> <452C0A97.5010501@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2006 16:56:45.0364 (UTC) FILETIME=[847FCF40:01C714A0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4384; t=1164905806; x=1165769806; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20[Fwd=3A=20[mpls]=20WG=20Last=20Call=20on=20draft-ietf -mpls-number-0-bw-te-lsps-02.txt] |Sender:=20 |To:=20JP=20Vasseur=20; bh=I+70JaJfV5d2Tn3iDx8cCBGNTPlUijVXXjkXF9iT4iU=; b=QfucUAOzPCqU11THGaTNs/G3PPEBED/oQdFpTYFgoBW48kqul0kZjNkS3Wwr7jZJbIZqAm2V mwlIRQ5KHa2YKMrvIY/p4m2uGh+T3mzwzJdfmEZJl+/OkPF7sTyF8N6W; Authentication-Results: rtp-dkim-1; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: George Swallow , rtg-dir@ietf.org, isis-wg@ietf.org, ospf@ietf.org, David Ward , Loa Andersson Subject: [OSPF] Re: [Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt] X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi JP, Looks good. See one question below. JP Vasseur wrote: > Hi Acee, > > Thanks for your comments - > > As soon as you ACK that the changes address your comments I'll post > the updated ID. > > see in line, > > On Oct 10, 2006, at 5:03 PM, Acee Lindem wrote: > >> JP, >> >> One more comment - Please write the document so that it can >> apply to OSPFv3 TE as well. The existing draft can be an informative >> reference (draft-ietf-ospf-ospfv3-traffic-07.txt) >> > > OK. Text added: > > OLD: > > The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST > appear at most once within the Link TLV (Type 2) that is itself > carried within the Traffic Engineering LSA specified in [RFC3630]. If > a second instance of the Number of 0-bandwidth TE LSP(s) sub-TLV is > present, the receiving system MUST only process the first instance of > the sub-TLV. > > > NEW: > > The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST > appear at most once within the Link TLV (Type 2) that is itself > carried within the OSPFv2 Traffic Engineering LSA specified in > [RFC3630] > or the OSPFv3 Intra-Area-TE LSA (function code 10) defined in > draft-ietf-ospf-ospfv3-traffic. > If a second instance of the Number of 0-bandwidth TE LSP(s) sub-TLV is > present, the receiving system MUST only process the first instance of > the sub-TLV. > > see below > >> Thanks, >> Acee >> >> Acee Lindem wrote: >>> I've reviewed the subject document and don't have any comments on it >>> from the perspective of the OSPF WG. However, I have the following >>> comments as a member of the routing directorate (copying JP): >>> >>> 1. Why the cryptic sub-TLV name? RFC 3630 doesn't define short >>> cryptic names for sub-TLVs so I don't really see why you've >>> defined >>> NB-0-BW-LSP? Why not just call it the Unconstrained LSP Count >>> sub-TLV? >>> Or at least come up with a better short name :^), e.g. >>> BW-0-LSP-CNT. > > Yes, no problem. I renamed it ;-) > > Number of 0-bandwidth TE LSP(s) sub-TLV. > >>> 2. How did you arrive at 19 for the suggested value for the >>> sub-TLV type? I checked >>> IANA and 18 is the next available. I may be missing a document >>> though. > > As documented, 18 looks the next one available (when I first wrote the > ID I vaguely remember having seen another ID using 18 but I'm not > quite sure). Let's propose 18 and will see with IANA. > >>> 3. Do you want to reserve a value (e.g., 0xffffffff) to indicate >>> no unconstrained >>> LSPs are to traverse a given link. > > Let's just use the value 0. Since this is the current number wouldn't there be ambiguity between designating there are currently no BW-0 LSPs traversing this link and no BW-0 LSPs are allowed to traverse this linke? Thanks, Acee > >>> 4. Nit - in section 4, replace "OSPF LSA" with "OSPF LSAs" and >>> "ISIS LSP" >>> with "ISIS LSPs". > > Thanks. > > Cheers. > > JP. > >>> >>> Thanks, >>> Acee >>> David Ward wrote: >>>> Do you want our WG to review? Co-Last Call (as we have for other WG >>>> that >>>> affect our protocol)? Do you have a desired date for end of last >>>> call from >>>> the IGPs? >>>> >>>> Thanks >>>> >>>> -DWard >>>> >>>> >>>> On 9/4/06 5:01 AM, "Loa Andersson" wrote: >>>> >>>> >>>>> All, >>>>> >>>>> the MPLS working group want to notify the ospf and is-s >>>>> working groups, as well as the routing directorate that >>>>> we are currently doing a wg last call on >>>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt. >>>>> >>>>> Loa and George >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: [mpls] WG Last Call on >>>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt >>>>> Date: Fri, 01 Sep 2006 10:08:10 +0200 >>>>> From: Loa Andersson >>>>> Organization: Acreo AB >>>>> To: mpls@ietf.org >>>>> >>>>> Working Group, >>>>> >>>>> this initiates a two week working group last call on >>>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt >>>>> >>>>> The wg last call ends on September 17. >>>>> >>>>> Please send comments to the working group mailing list and/or >>>>> the working group chairs. >>>>> >>>>> /Loa and George >>>>> >>>> >>>> >>> >>> >> > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 30 14:31:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprcA-0006DX-IW; Thu, 30 Nov 2006 14:30:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gprc8-0006DJ-Jj; Thu, 30 Nov 2006 14:30:32 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gprc7-0001El-08; Thu, 30 Nov 2006 14:30:32 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2006 11:30:30 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kAUJUT5G022768; Thu, 30 Nov 2006 11:30:29 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAUJTwOv018677; Thu, 30 Nov 2006 11:30:29 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 14:29:51 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 14:29:50 -0500 In-Reply-To: <456F0D4C.2070209@cisco.com> References: <452C089D.5090204@cisco.com> <452C0A97.5010501@cisco.com> <456F0D4C.2070209@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4354A088-B93C-457F-93FD-55B8EB4A861A@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 30 Nov 2006 14:29:49 -0500 To: Acee Lindem X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 30 Nov 2006 19:29:51.0057 (UTC) FILETIME=[E7995410:01C714B5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4888; t=1164915029; x=1165779029; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Fwd=3A=20[mpls]=20WG=20Last=20Call=20on=20draft-ietf -mpls-number-0-bw-te-lsps-02.txt] |Sender:=20; bh=XinVuCa99B5apwocItWwwFeGZ3wQ8tJieHOtpZ7mmsM=; b=vq81QcR1/WFcK1GToIqKpw5G++TJKci5Ili9OW25m/F8ftlSODkFm4yVEEt6k2JQnlnr9eLN foaAKZgqsX8BFAzfbjjxrIleJYdFn9aerS25sisMeDHR1qYPmhPbQVLF; Authentication-Results: sj-dkim-5; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: George Swallow , rtg-dir@ietf.org, isis-wg@ietf.org, ospf@ietf.org, David Ward , Loa Andersson Subject: [OSPF] Re: [Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt] X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Acee, On Nov 30, 2006, at 11:56 AM, Acee Lindem wrote: > Hi JP, > Looks good. See one question below. > > JP Vasseur wrote: >> Hi Acee, >> >> Thanks for your comments - >> >> As soon as you ACK that the changes address your comments I'll >> post the updated ID. >> >> see in line, >> >> On Oct 10, 2006, at 5:03 PM, Acee Lindem wrote: >> >>> JP, >>> >>> One more comment - Please write the document so that it can >>> apply to OSPFv3 TE as well. The existing draft can be an informative >>> reference (draft-ietf-ospf-ospfv3-traffic-07.txt) >>> >> >> OK. Text added: >> >> OLD: >> >> The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST >> appear at most once within the Link TLV (Type 2) that is itself >> carried within the Traffic Engineering LSA specified in >> [RFC3630]. If >> a second instance of the Number of 0-bandwidth TE LSP(s) sub- >> TLV is >> present, the receiving system MUST only process the first >> instance of >> the sub-TLV. >> >> >> NEW: >> >> The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST >> appear at most once within the Link TLV (Type 2) that is itself >> carried within the OSPFv2 Traffic Engineering LSA specified in >> [RFC3630] >> or the OSPFv3 Intra-Area-TE LSA (function code 10) defined in >> draft-ietf-ospf-ospfv3-traffic. >> If a second instance of the Number of 0-bandwidth TE LSP(s) sub- >> TLV is >> present, the receiving system MUST only process the first >> instance of >> the sub-TLV. >> >> see below >> >>> Thanks, >>> Acee >>> >>> Acee Lindem wrote: >>>> I've reviewed the subject document and don't have any comments >>>> on it >>>> from the perspective of the OSPF WG. However, I have the following >>>> comments as a member of the routing directorate (copying JP): >>>> >>>> 1. Why the cryptic sub-TLV name? RFC 3630 doesn't define short >>>> cryptic names for sub-TLVs so I don't really see why >>>> you've defined >>>> NB-0-BW-LSP? Why not just call it the Unconstrained LSP >>>> Count sub-TLV? >>>> Or at least come up with a better short name :^), e.g. >>>> BW-0-LSP-CNT. >> >> Yes, no problem. I renamed it ;-) >> >> Number of 0-bandwidth TE LSP(s) sub-TLV. >> >>>> 2. How did you arrive at 19 for the suggested value for the >>>> sub-TLV type? I checked >>>> IANA and 18 is the next available. I may be missing a >>>> document though. >> >> As documented, 18 looks the next one available (when I first wrote >> the ID I vaguely remember having seen another ID using 18 but I'm >> not quite sure). Let's propose 18 and will see with IANA. >> >>>> 3. Do you want to reserve a value (e.g., 0xffffffff) to >>>> indicate no unconstrained >>>> LSPs are to traverse a given link. >> >> Let's just use the value 0. > Since this is the current number wouldn't there be ambiguity > between designating there > are currently no BW-0 LSPs traversing this link and no BW-0 LSPs > are allowed > to traverse this linke? Other attributes such as affinity should be used to not allows 0-bw TE LSP to traverse a specific link. This TLV is only used to report the number of such TE LSPs traversing the link. Thanks. JP. > > Thanks, > Acee > >> >>>> 4. Nit - in section 4, replace "OSPF LSA" with "OSPF LSAs" and >>>> "ISIS LSP" >>>> with "ISIS LSPs". >> >> Thanks. >> >> Cheers. >> >> JP. >> >>>> >>>> Thanks, >>>> Acee >>>> David Ward wrote: >>>>> Do you want our WG to review? Co-Last Call (as we have for >>>>> other WG that >>>>> affect our protocol)? Do you have a desired date for end of >>>>> last call from >>>>> the IGPs? >>>>> >>>>> Thanks >>>>> >>>>> -DWard >>>>> >>>>> >>>>> On 9/4/06 5:01 AM, "Loa Andersson" wrote: >>>>> >>>>> >>>>>> All, >>>>>> >>>>>> the MPLS working group want to notify the ospf and is-s >>>>>> working groups, as well as the routing directorate that >>>>>> we are currently doing a wg last call on >>>>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt. >>>>>> >>>>>> Loa and George >>>>>> >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te- >>>>>> lsps-02.txt >>>>>> Date: Fri, 01 Sep 2006 10:08:10 +0200 >>>>>> From: Loa Andersson >>>>>> Organization: Acreo AB >>>>>> To: mpls@ietf.org >>>>>> >>>>>> Working Group, >>>>>> >>>>>> this initiates a two week working group last call on >>>>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt >>>>>> >>>>>> The wg last call ends on September 17. >>>>>> >>>>>> Please send comments to the working group mailing list and/or >>>>>> the working group chairs. >>>>>> >>>>>> /Loa and George >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 30 14:32:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpre9-000755-Ja; Thu, 30 Nov 2006 14:32:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpre8-00074t-Ue; Thu, 30 Nov 2006 14:32:36 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpre7-0001bJ-Bi; Thu, 30 Nov 2006 14:32:36 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2006 11:32:34 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAUJWXhN024136; Thu, 30 Nov 2006 14:32:33 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAUJWXYN016309; Thu, 30 Nov 2006 14:32:33 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 14:32:33 -0500 Received: from [10.82.224.37] ([10.82.224.37]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 14:32:33 -0500 Message-ID: <456F31D0.3050809@cisco.com> Date: Thu, 30 Nov 2006 14:32:32 -0500 From: Acee Lindem User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: JP Vasseur References: <452C089D.5090204@cisco.com> <452C0A97.5010501@cisco.com> <456F0D4C.2070209@cisco.com> <4354A088-B93C-457F-93FD-55B8EB4A861A@cisco.com> In-Reply-To: <4354A088-B93C-457F-93FD-55B8EB4A861A@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2006 19:32:33.0263 (UTC) FILETIME=[4847FFF0:01C714B6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5083; t=1164915153; x=1165779153; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20 |Subject:=20Re=3A=20[Fwd=3A=20[mpls]=20WG=20Last=20Call=20on=20draft-ietf -mpls-number-0-bw-te-lsps-02.txt] |Sender:=20 |To:=20JP=20Vasseur=20; bh=Ck1ZzJRmpGyNAUg/g4HrySDgyo+nOY3C4aL7iYDBsMk=; b=J8hWVLsd0zkk1ztbZSVIXR5hBDAjHl3a1lN9j8drcsSR8Rb9sgYQ+zgx0uhprW3/U2vLLNer LYsrPvmz8zf4FTrNopmiRs+vCPDOdSb9Lcul5qi4ayvuaKxHO/T6Qcl8; Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: George Swallow , rtg-dir@ietf.org, isis-wg@ietf.org, ospf@ietf.org, David Ward , Loa Andersson Subject: [OSPF] Re: [Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt] X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org JP - Sounds good. Acee JP Vasseur wrote: > Hi Acee, > > On Nov 30, 2006, at 11:56 AM, Acee Lindem wrote: > >> Hi JP, >> Looks good. See one question below. >> >> JP Vasseur wrote: >>> Hi Acee, >>> >>> Thanks for your comments - >>> >>> As soon as you ACK that the changes address your comments I'll post >>> the updated ID. >>> >>> see in line, >>> >>> On Oct 10, 2006, at 5:03 PM, Acee Lindem wrote: >>> >>>> JP, >>>> >>>> One more comment - Please write the document so that it can >>>> apply to OSPFv3 TE as well. The existing draft can be an informative >>>> reference (draft-ietf-ospf-ospfv3-traffic-07.txt) >>>> >>> >>> OK. Text added: >>> >>> OLD: >>> >>> The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST >>> appear at most once within the Link TLV (Type 2) that is itself >>> carried within the Traffic Engineering LSA specified in >>> [RFC3630]. If >>> a second instance of the Number of 0-bandwidth TE LSP(s) sub-TLV is >>> present, the receiving system MUST only process the first >>> instance of >>> the sub-TLV. >>> >>> >>> NEW: >>> >>> The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST >>> appear at most once within the Link TLV (Type 2) that is itself >>> carried within the OSPFv2 Traffic Engineering LSA specified in >>> [RFC3630] >>> or the OSPFv3 Intra-Area-TE LSA (function code 10) defined in >>> draft-ietf-ospf-ospfv3-traffic. >>> If a second instance of the Number of 0-bandwidth TE LSP(s) >>> sub-TLV is >>> present, the receiving system MUST only process the first >>> instance of >>> the sub-TLV. >>> >>> see below >>> >>>> Thanks, >>>> Acee >>>> >>>> Acee Lindem wrote: >>>>> I've reviewed the subject document and don't have any comments on it >>>>> from the perspective of the OSPF WG. However, I have the following >>>>> comments as a member of the routing directorate (copying JP): >>>>> >>>>> 1. Why the cryptic sub-TLV name? RFC 3630 doesn't define short >>>>> cryptic names for sub-TLVs so I don't really see why you've >>>>> defined >>>>> NB-0-BW-LSP? Why not just call it the Unconstrained LSP >>>>> Count sub-TLV? >>>>> Or at least come up with a better short name :^), e.g. >>>>> BW-0-LSP-CNT. >>> >>> Yes, no problem. I renamed it ;-) >>> >>> Number of 0-bandwidth TE LSP(s) sub-TLV. >>> >>>>> 2. How did you arrive at 19 for the suggested value for the >>>>> sub-TLV type? I checked >>>>> IANA and 18 is the next available. I may be missing a >>>>> document though. >>> >>> As documented, 18 looks the next one available (when I first wrote >>> the ID I vaguely remember having seen another ID using 18 but I'm >>> not quite sure). Let's propose 18 and will see with IANA. >>> >>>>> 3. Do you want to reserve a value (e.g., 0xffffffff) to >>>>> indicate no unconstrained >>>>> LSPs are to traverse a given link. >>> >>> Let's just use the value 0. >> Since this is the current number wouldn't there be ambiguity between >> designating there >> are currently no BW-0 LSPs traversing this link and no BW-0 LSPs are >> allowed >> to traverse this linke? > > Other attributes such as affinity should be used to not allows 0-bw TE > LSP to traverse a specific link. This TLV is only used to report the > number of such TE LSPs traversing the link. > > Thanks. > > JP. > >> >> Thanks, >> Acee >> >>> >>>>> 4. Nit - in section 4, replace "OSPF LSA" with "OSPF LSAs" and >>>>> "ISIS LSP" >>>>> with "ISIS LSPs". >>> >>> Thanks. >>> >>> Cheers. >>> >>> JP. >>> >>>>> >>>>> Thanks, >>>>> Acee >>>>> David Ward wrote: >>>>>> Do you want our WG to review? Co-Last Call (as we have for other >>>>>> WG that >>>>>> affect our protocol)? Do you have a desired date for end of last >>>>>> call from >>>>>> the IGPs? >>>>>> >>>>>> Thanks >>>>>> >>>>>> -DWard >>>>>> >>>>>> >>>>>> On 9/4/06 5:01 AM, "Loa Andersson" wrote: >>>>>> >>>>>> >>>>>>> All, >>>>>>> >>>>>>> the MPLS working group want to notify the ospf and is-s >>>>>>> working groups, as well as the routing directorate that >>>>>>> we are currently doing a wg last call on >>>>>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt. >>>>>>> >>>>>>> Loa and George >>>>>>> >>>>>>> >>>>>>> -------- Original Message -------- >>>>>>> Subject: [mpls] WG Last Call on >>>>>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt >>>>>>> Date: Fri, 01 Sep 2006 10:08:10 +0200 >>>>>>> From: Loa Andersson >>>>>>> Organization: Acreo AB >>>>>>> To: mpls@ietf.org >>>>>>> >>>>>>> Working Group, >>>>>>> >>>>>>> this initiates a two week working group last call on >>>>>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt >>>>>>> >>>>>>> The wg last call ends on September 17. >>>>>>> >>>>>>> Please send comments to the working group mailing list and/or >>>>>>> the working group chairs. >>>>>>> >>>>>>> /Loa and George >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 30 14:34:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gprg9-00005Z-Fd; Thu, 30 Nov 2006 14:34:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gprg8-00005M-00; Thu, 30 Nov 2006 14:34:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gprg6-0001ql-Dl; Thu, 30 Nov 2006 14:34:39 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2006 11:34:37 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAUJYatM022987; Thu, 30 Nov 2006 14:34:36 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAUJYaYV017791; Thu, 30 Nov 2006 14:34:36 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 14:34:23 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 14:34:22 -0500 In-Reply-To: <456F31D0.3050809@cisco.com> References: <452C089D.5090204@cisco.com> <452C0A97.5010501@cisco.com> <456F0D4C.2070209@cisco.com> <4354A088-B93C-457F-93FD-55B8EB4A861A@cisco.com> <456F31D0.3050809@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C99B47A-3512-48B5-9BF3-5EF924D7F39E@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 30 Nov 2006 14:34:21 -0500 To: Acee Lindem X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 30 Nov 2006 19:34:22.0614 (UTC) FILETIME=[8975A360:01C714B6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5449; t=1164915276; x=1165779276; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Fwd=3A=20[mpls]=20WG=20Last=20Call=20on=20draft-ietf -mpls-number-0-bw-te-lsps-02.txt] |Sender:=20 |To:=20Acee=20Lindem=20; bh=LpEJ/OeHhHrpUdSUU7/QMglN5zxCu8nPzZSRVo0ZI+w=; b=HpcxUTDTUMS3NiMEGSjBtoGtdQ0ptPFv00rvdTD0im5CMb6LXTpY/gDHPClrEZSSZ+Zv39mQ 1JKDDWfiJ4vDrq4qusK2OVU/qcApW+Bh2cbydMVbLURw0uU3kxFzjCv9; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: George Swallow , rtg-dir@ietf.org, isis-wg@ietf.org, ospf@ietf.org, David Ward , Loa Andersson Subject: [OSPF] Re: [Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt] X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org OK thanks so I'll now post the revised version. Cheers. JP. On Nov 30, 2006, at 2:32 PM, Acee Lindem wrote: > JP - Sounds good. > Acee > JP Vasseur wrote: >> Hi Acee, >> >> On Nov 30, 2006, at 11:56 AM, Acee Lindem wrote: >> >>> Hi JP, >>> Looks good. See one question below. >>> >>> JP Vasseur wrote: >>>> Hi Acee, >>>> >>>> Thanks for your comments - >>>> >>>> As soon as you ACK that the changes address your comments I'll >>>> post the updated ID. >>>> >>>> see in line, >>>> >>>> On Oct 10, 2006, at 5:03 PM, Acee Lindem wrote: >>>> >>>>> JP, >>>>> >>>>> One more comment - Please write the document so that it can >>>>> apply to OSPFv3 TE as well. The existing draft can be an >>>>> informative >>>>> reference (draft-ietf-ospf-ospfv3-traffic-07.txt) >>>>> >>>> >>>> OK. Text added: >>>> >>>> OLD: >>>> >>>> The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST >>>> appear at most once within the Link TLV (Type 2) that is itself >>>> carried within the Traffic Engineering LSA specified in >>>> [RFC3630]. If >>>> a second instance of the Number of 0-bandwidth TE LSP(s) sub- >>>> TLV is >>>> present, the receiving system MUST only process the first >>>> instance of >>>> the sub-TLV. >>>> >>>> >>>> NEW: >>>> >>>> The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST >>>> appear at most once within the Link TLV (Type 2) that is itself >>>> carried within the OSPFv2 Traffic Engineering LSA specified >>>> in [RFC3630] >>>> or the OSPFv3 Intra-Area-TE LSA (function code 10) defined in >>>> draft-ietf-ospf-ospfv3-traffic. >>>> If a second instance of the Number of 0-bandwidth TE LSP(s) >>>> sub-TLV is >>>> present, the receiving system MUST only process the first >>>> instance of >>>> the sub-TLV. >>>> >>>> see below >>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> Acee Lindem wrote: >>>>>> I've reviewed the subject document and don't have any comments >>>>>> on it >>>>>> from the perspective of the OSPF WG. However, I have the >>>>>> following >>>>>> comments as a member of the routing directorate (copying JP): >>>>>> >>>>>> 1. Why the cryptic sub-TLV name? RFC 3630 doesn't define short >>>>>> cryptic names for sub-TLVs so I don't really see why >>>>>> you've defined >>>>>> NB-0-BW-LSP? Why not just call it the Unconstrained LSP >>>>>> Count sub-TLV? >>>>>> Or at least come up with a better short name :^), e.g. >>>>>> BW-0-LSP-CNT. >>>> >>>> Yes, no problem. I renamed it ;-) >>>> >>>> Number of 0-bandwidth TE LSP(s) sub-TLV. >>>> >>>>>> 2. How did you arrive at 19 for the suggested value for the >>>>>> sub-TLV type? I checked >>>>>> IANA and 18 is the next available. I may be missing a >>>>>> document though. >>>> >>>> As documented, 18 looks the next one available (when I first >>>> wrote the ID I vaguely remember having seen another ID using 18 >>>> but I'm not quite sure). Let's propose 18 and will see with IANA. >>>> >>>>>> 3. Do you want to reserve a value (e.g., 0xffffffff) to >>>>>> indicate no unconstrained >>>>>> LSPs are to traverse a given link. >>>> >>>> Let's just use the value 0. >>> Since this is the current number wouldn't there be ambiguity >>> between designating there >>> are currently no BW-0 LSPs traversing this link and no BW-0 LSPs >>> are allowed >>> to traverse this linke? >> >> Other attributes such as affinity should be used to not allows 0- >> bw TE LSP to traverse a specific link. This TLV is only used to >> report the number of such TE LSPs traversing the link. >> >> Thanks. >> >> JP. >> >>> >>> Thanks, >>> Acee >>> >>>> >>>>>> 4. Nit - in section 4, replace "OSPF LSA" with "OSPF LSAs" >>>>>> and "ISIS LSP" >>>>>> with "ISIS LSPs". >>>> >>>> Thanks. >>>> >>>> Cheers. >>>> >>>> JP. >>>> >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> David Ward wrote: >>>>>>> Do you want our WG to review? Co-Last Call (as we have for >>>>>>> other WG that >>>>>>> affect our protocol)? Do you have a desired date for end of >>>>>>> last call from >>>>>>> the IGPs? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -DWard >>>>>>> >>>>>>> >>>>>>> On 9/4/06 5:01 AM, "Loa Andersson" wrote: >>>>>>> >>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> the MPLS working group want to notify the ospf and is-s >>>>>>>> working groups, as well as the routing directorate that >>>>>>>> we are currently doing a wg last call on >>>>>>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt. >>>>>>>> >>>>>>>> Loa and George >>>>>>>> >>>>>>>> >>>>>>>> -------- Original Message -------- >>>>>>>> Subject: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw- >>>>>>>> te-lsps-02.txt >>>>>>>> Date: Fri, 01 Sep 2006 10:08:10 +0200 >>>>>>>> From: Loa Andersson >>>>>>>> Organization: Acreo AB >>>>>>>> To: mpls@ietf.org >>>>>>>> >>>>>>>> Working Group, >>>>>>>> >>>>>>>> this initiates a two week working group last call on >>>>>>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt >>>>>>>> >>>>>>>> The wg last call ends on September 17. >>>>>>>> >>>>>>>> Please send comments to the working group mailing list and/or >>>>>>>> the working group chairs. >>>>>>>> >>>>>>>> /Loa and George >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 30 20:38:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpxKq-0005rv-1E; Thu, 30 Nov 2006 20:37:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpxKo-0005qE-HL; Thu, 30 Nov 2006 20:37:02 -0500 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpxKn-0005O6-5w; Thu, 30 Nov 2006 20:37:02 -0500 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id kB11m8o2061362; Thu, 30 Nov 2006 20:48:08 -0500 (EST) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200612010148.kB11m8o2061362@workhorse.brookfield.occnc.com> To: JP Vasseur Subject: Re: [OSPF] Re: [Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt] In-reply-to: Your message of "Thu, 30 Nov 2006 14:29:49 EST." <4354A088-B93C-457F-93FD-55B8EB4A861A@cisco.com> Date: Thu, 30 Nov 2006 20:48:08 -0500 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: George Swallow , rtg-dir@ietf.org, isis-wg@ietf.org, ospf@ietf.org, David Ward , Loa Andersson X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org In message <4354A088-B93C-457F-93FD-55B8EB4A861A@cisco.com> JP Vasseur writes: > > Other attributes such as affinity should be used to not allows 0-bw > TE LSP to traverse a specific link. This TLV is only used to report > the number of such TE LSPs traversing the link. > > Thanks. > > JP. The provider already has the necessary tools that can be used to accomplish this. If a general purpose tool (attributes and affinities) is available which accomplishes something a special purpose tool to accomplish the same thing is not needed. Such a tool would only be useful if the administration of the MPLS midpoint (where the attribute is set) had no control over the administration of the MPLS ingress or a border that is doing route computation (where the affinity is set). I don't see any anticipated real world deployment that would benefit from this. If you do, then please explain the deployment scenario. Curtis _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 30 20:53:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpxak-00021b-D2; Thu, 30 Nov 2006 20:53:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpxaj-0001wm-5o; Thu, 30 Nov 2006 20:53:29 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpxah-0007nm-Sa; Thu, 30 Nov 2006 20:53:29 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2006 17:53:27 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB11rQRw030038; Thu, 30 Nov 2006 20:53:26 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kB11rQDM020910; Thu, 30 Nov 2006 20:53:26 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 20:53:25 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 20:53:25 -0500 In-Reply-To: <200612010148.kB11m8o2061362@workhorse.brookfield.occnc.com> References: <200612010148.kB11m8o2061362@workhorse.brookfield.occnc.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <133D69D4-43D7-46D0-88E5-80FD8CB25CCF@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [OSPF] Re: [Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt] Date: Thu, 30 Nov 2006 20:53:21 -0500 To: curtis@occnc.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 01 Dec 2006 01:53:25.0540 (UTC) FILETIME=[7D4CBE40:01C714EB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1224; t=1164938006; x=1165802006; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[OSPF]=20Re=3A=20[Fwd=3A=20[mpls]=20WG=20Last=20Call= 20on=20draft-ietf-mpls-number-0-bw-te-lsps-02.txt]=20 |Sender:=20 |To:=20curtis@occnc.com; bh=BPd12xBa+zoogHIUHSGXIoNHXmlxfeVqo2nFkl4ftu4=; b=eF4MHklYLO/qAFxc2g6ArfpIJNA1nRibHI6GRLjR9VdSSbqkgCQZ/W1vcEpiwyjhIeOldCvx ypI7CpmHKdQH8uMGnOMaRYFtVuyF9Vbk9AvmhCVadFfuYhRoLRaPbs/W; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: George Swallow , rtg-dir@ietf.org, isis-wg@ietf.org, ospf@ietf.org, David Ward , Loa Andersson X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Curtis, On Nov 30, 2006, at 8:48 PM, Curtis Villamizar wrote: > > In message <4354A088-B93C-457F-93FD-55B8EB4A861A@cisco.com> > JP Vasseur writes: >> >> Other attributes such as affinity should be used to not allows 0-bw >> TE LSP to traverse a specific link. This TLV is only used to report >> the number of such TE LSPs traversing the link. >> >> Thanks. >> >> JP. > > > The provider already has the necessary tools that can be used to > accomplish this. If a general purpose tool (attributes and > affinities) is available which accomplishes something a special > purpose tool to accomplish the same thing is not needed. > > Such a tool would only be useful if the administration of the MPLS > midpoint (where the attribute is set) had no control over the > administration of the MPLS ingress or a border that is doing route > computation (where the affinity is set). I don't see any anticipated > real world deployment that would benefit from this. If you do, then > please explain the deployment scenario. > not sure to see your point here ... I was mentioning that the aim of this TLV was not to avoid some links. Looks like you're saying the same thing. JP. > Curtis _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Nov 30 21:29:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpy8y-0000v8-6c; Thu, 30 Nov 2006 21:28:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpy8w-0000tO-U9; Thu, 30 Nov 2006 21:28:50 -0500 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpy8v-0006Vi-Hc; Thu, 30 Nov 2006 21:28:50 -0500 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id kB12hPqt062617; Thu, 30 Nov 2006 21:43:25 -0500 (EST) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200612010243.kB12hPqt062617@workhorse.brookfield.occnc.com> To: JP Vasseur Subject: Re: [OSPF] Re: [Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt] In-reply-to: Your message of "Thu, 30 Nov 2006 20:53:21 EST." <133D69D4-43D7-46D0-88E5-80FD8CB25CCF@cisco.com> Date: Thu, 30 Nov 2006 21:43:25 -0500 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: George Swallow , rtg-dir@ietf.org, isis-wg@ietf.org, ospf@ietf.org, David Ward , Loa Andersson X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org In message <133D69D4-43D7-46D0-88E5-80FD8CB25CCF@cisco.com> JP Vasseur writes: > > Hi Curtis, > > On Nov 30, 2006, at 8:48 PM, Curtis Villamizar wrote: > > > > > In message <4354A088-B93C-457F-93FD-55B8EB4A861A@cisco.com> > > JP Vasseur writes: > >> > >> Other attributes such as affinity should be used to not allows 0-bw > >> TE LSP to traverse a specific link. This TLV is only used to report > >> the number of such TE LSPs traversing the link. > >> > >> Thanks. > >> > >> JP. > > > > > > The provider already has the necessary tools that can be used to > > accomplish this. If a general purpose tool (attributes and > > affinities) is available which accomplishes something a special > > purpose tool to accomplish the same thing is not needed. > > > > Such a tool would only be useful if the administration of the MPLS > > midpoint (where the attribute is set) had no control over the > > administration of the MPLS ingress or a border that is doing route > > computation (where the affinity is set). I don't see any anticipated > > real world deployment that would benefit from this. If you do, then > > please explain the deployment scenario. > > > > not sure to see your point here ... I was mentioning that the aim of > this TLV was not to avoid some links. > Looks like you're saying the same thing. > > JP. > > > Curtis My point was regarding a mention in that conversation that the value of zero might mean no zero-BW LSPs have been set up or none are allowed. Looks like I cut the wrong paragraph out of the conversation. The existing link attributes and affinity are sufficient to indicate the condition that no zero-BW LSPs are allowed if the administration of that network decides to use an attribute for that purpose. I'm agreeing with you. Curtis _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf