STOP procrastinating! now is the time = to take=20 action, gain confidence with the girls starting from today! http://www.gesstore.com/ ------=_NextPart_000_0008_01C83483.2EABCBB0-- From candi415@MAIL.NDHU.EDU.TW Sun Dec 02 19:22:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyz4v-0004WD-Cs for ospf-archive@megatron.ietf.org; Sun, 02 Dec 2007 19:22:29 -0500 Received: from [190.3.80.172] (helo=[190.3.80.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyz4u-0006ln-4P for ospf-archive@megatron.ietf.org; Sun, 02 Dec 2007 19:22:29 -0500 Received: from gabriel ([102.149.151.166] helo=gabriel) by [190.3.80.172] ( sendmail 8.13.3/8.13.1) with esmtpa id 1UwVDv-000QUB-Jc for ospf-archive@megatron.ietf.org; Sun, 2 Dec 2007 21:23:02 -0300 Message-ID: <93EE558E.150B4A32@MAIL.NDHU.EDU.TW> Date: Sun, 2 Dec 2007 21:22:30 -0300 From: "candi Fincham" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: tednavdu Content-Type: multipart/alternative; boundary="------------040602080300010402050105" X-Spam-Score: 2.1 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 --------------040602080300010402050105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit are you the next man in the world to get super sized in the pants? http://ohvpark.com/ --------------040602080300010402050105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit are you the next man in the world to get super sized in the pants? http://ohvpark.com/
--------------040602080300010402050105-- From Gregory411@alashryco.com Mon Dec 03 21:59:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzO03-00022u-34 for ospf-archive@megatron.ietf.org; Mon, 03 Dec 2007 21:59:07 -0500 Received: from taco.fdorm1.nccu.edu.tw ([140.119.131.160]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzO00-00052z-Dq for ospf-archive@megatron.ietf.org; Mon, 03 Dec 2007 21:59:04 -0500 Received: by 10.236.44.164 with SMTP id FSKRxkdaAQHZl; Tue, 4 Dec 2007 10:59:16 +0800 (GMT) Received: by 192.168.127.189 with SMTP id GntarKZzrTKCaP.7953921846128; Tue, 4 Dec 2007 10:59:14 +0800 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 4 Dec 2007 10:59:11 +0800 To: ospf-archive@megatron.ietf.org From: "Gregory loeffler" Subject: beruhtet Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.7 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 my lover grabbed my dick and asked me what i had done to it, it feels so big all of a sudden http://coavnsys.com/ From ospgroundskeeper@seattleartmuseum.org Tue Dec 04 01:47:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzRZ2-0003ou-PS for ospf-archive@megatron.ietf.org; Tue, 04 Dec 2007 01:47:29 -0500 Received: from [86.66.194.171] (helo=battosai) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IzRZ2-00046u-4F for ospf-archive@megatron.ietf.org; Tue, 04 Dec 2007 01:47:28 -0500 Received: from Jillian Ila (10.12.10.16) by battosai (PowerMTA(TM) v3.2r4) id hfp14o72d87j61 for ; Tue, 4 Dec 2007 07:47:41 +0100 Message-Id: <20071204084741.2531.qmail@battosai> To: Subject: November 76% OFF From: VIAGRA Ž Official Site MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8

From ospf-bounces@ietf.org Tue Dec 04 11:26:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzabM-0000xA-GS; Tue, 04 Dec 2007 11:26:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzabL-0000wy-1v for ospf@ietf.org; Tue, 04 Dec 2007 11:26:27 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzabI-000358-De for ospf@ietf.org; Tue, 04 Dec 2007 11:26:27 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lB4GQN8X006476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 4 Dec 2007 08:26:23 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lB4GQMkZ018192 for ; Tue, 4 Dec 2007 10:26:22 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lB4GQ8gZ017705 for ; Tue, 4 Dec 2007 10:26:22 -0600 (CST) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 08:26:19 -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 Date: Tue, 4 Dec 2007 08:25:31 -0800 Message-ID: <08590A72DC26A54B85632FF97C2C22DA019ED569@XCH-NW-5V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OSPF-MDR options Thread-Index: Acg2knL3SrsE8jWNS4uaPkpFwUmD5A== From: "Spagnolo, Phillip A" To: X-OriginalArrivalTime: 04 Dec 2007 16:26:19.0366 (UTC) FILETIME=[668C6060:01C83692] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [OSPF] OSPF-MDR options 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 All, I listened to the discussion during the meeting yesterday, and I was surprised at how Thomas and Emmanuel were trying to cast OSPF-MDR as having too many options. I strongly disagree that it has too many options. MANETs are not for one size fits all protocols. The environments in which they run require flexibility. The protocol needs to be able to be configured to match the operational environment. OSPF-MDR provides options to configure your MANET for varying environments. I have found the options very useful for testing. ---Adjacency graph options--- List goes from most overhead efficient adjacency set to most robust to link failure 1. AdjConnectivity=3D1 (maintain a uniconnected MDR backbone) 2. AdjConnectivity=3D2 (maintain a biconnected MDR backbone) 3. AdjConnectivity=3D0 (maintain a completely connected MDR backbone) = same as ptmp ---Network graph options--- 1. LSAFullness=3D0 (only advertise adjacencies) "most overhead = efficient" 2. LSAFullness=3D1 (advertise links to have one mincost routing path) 3. LSAFullness=3D2 (advertise links to have two mincost routing paths) 4. LSAFullness=3D3 (advertise all routable links on MDRs) 5. LSAFullness=3D4 (advertise all routable links) "most available = routing paths" Is this complicated? I don't think so. It is flexible for the MANET environment. Thomas and Emmanuel, I would agree with your comments that we might need more explanation on when to configure which options. That would be no problem to add before the experimental RFCs are published. Would you like to see something like a tutorial? I say we move forward as planned with three experimental RFCs. Sincerely, Phil Phillip A. Spagnolo M&CT Network Technology Boeing Phantom Works 425-373-2810 phillip.a.spagnolo@boeing.com _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From Katesrncja@alenquer.com Tue Dec 04 12:43:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzboG-0002DJ-6o for ospf-archive@megatron.ietf.org; Tue, 04 Dec 2007 12:43:52 -0500 Received: from [77.195.143.114] (helo=[77.195.143.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzboF-0006g1-Li for ospf-archive@megatron.ietf.org; Tue, 04 Dec 2007 12:43:52 -0500 Received: by 10.15.164.99 with SMTP id LnKaraOXbCstS; Tue, 4 Dec 2007 18:43:50 +0100 (GMT) Received: by 192.168.35.146 with SMTP id oLRzPDGlRdnCxo.4202913149346; Tue, 4 Dec 2007 18:43:48 +0100 (GMT) Message-ID: Date: Tue, 4 Dec 2007 18:43:45 +0100 From: "sada Kates" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: dicchion Content-Type: multipart/alternative; boundary="------------060501080805040107040701" X-Antivirus: avast! (VPS 071204-1, 04/12/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.1 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 --------------060501080805040107040701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit would you prefer to have an average cock or something that will really knock the fucking socks off her http://oopyjoe.com/ --------------060501080805040107040701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit would you prefer to have an average cock or something that will
really knock the fucking socks off her http://oopyjoe.com/
--------------060501080805040107040701-- From ospf-bounces@ietf.org Tue Dec 04 14:07:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izd7J-0003GI-Na; Tue, 04 Dec 2007 14:07:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izd7J-0003EK-3V for ospf@ietf.org; Tue, 04 Dec 2007 14:07:37 -0500 Received: from sernt12.essex.ac.uk ([155.245.48.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izd7I-0005Uy-H4 for ospf@ietf.org; Tue, 04 Dec 2007 14:07:36 -0500 Received: from sernt14.essex.ac.uk ([155.245.48.26]) by sernt12.essex.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Dec 2007 19:07:35 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [OSPF] OSPF-MDR options Date: Tue, 4 Dec 2007 19:06:18 -0000 Message-ID: <7AC902A40BEDD411A3A800D0B7847B661CEAD942@sernt14.essex.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OSPF-MDR options Thread-Index: Acg2knL3SrsE8jWNS4uaPkpFwUmD5AAFk1ml References: <08590A72DC26A54B85632FF97C2C22DA019ED569@XCH-NW-5V2.nw.nos.boeing.com> From: "Thomas, Matthew R" To: "Spagnolo, Phillip A" , X-OriginalArrivalTime: 04 Dec 2007 19:07:35.0072 (UTC) FILETIME=[EDB7F200:01C836A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 not this Thomas (just for clarity)... I Like it =20 Matthew R Thomas ________________________________ From: Spagnolo, Phillip A [mailto:phillip.a.spagnolo@boeing.com] Sent: Tue 04/12/2007 16:25 To: ospf@ietf.org Subject: [OSPF] OSPF-MDR options All, I listened to the discussion during the meeting yesterday, and I was surprised at how Thomas and Emmanuel were trying to cast OSPF-MDR as having too many options. I strongly disagree that it has too many options. MANETs are not for one size fits all protocols. The environments in which they run require flexibility. The protocol needs to be able to be configured to match the operational environment. OSPF-MDR provides options to configure your MANET for varying environments. I have found the options very useful for testing. ---Adjacency graph options--- List goes from most overhead efficient adjacency set to most robust to link failure 1. AdjConnectivity=3D1 (maintain a uniconnected MDR backbone) 2. AdjConnectivity=3D2 (maintain a biconnected MDR backbone) 3. AdjConnectivity=3D0 (maintain a completely connected MDR backbone) = same as ptmp ---Network graph options--- 1. LSAFullness=3D0 (only advertise adjacencies) "most overhead = efficient" 2. LSAFullness=3D1 (advertise links to have one mincost routing path) 3. LSAFullness=3D2 (advertise links to have two mincost routing paths) 4. LSAFullness=3D3 (advertise all routable links on MDRs) 5. LSAFullness=3D4 (advertise all routable links) "most available = routing paths" Is this complicated? I don't think so. It is flexible for the MANET environment. Thomas and Emmanuel, I would agree with your comments that we might need more explanation on when to configure which options. That would be no problem to add before the experimental RFCs are published. Would you like to see something like a tutorial? I say we move forward as planned with three experimental RFCs. Sincerely, Phil Phillip A. Spagnolo M&CT Network Technology Boeing Phantom Works 425-373-2810 phillip.a.spagnolo@boeing.com _______________________________________________ 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 Dec 04 15:55:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izen9-00030y-Vm; Tue, 04 Dec 2007 15:54:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izen9-00030V-Ak for ospf@ietf.org; Tue, 04 Dec 2007 15:54:55 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izen9-0005Me-0x for ospf@ietf.org; Tue, 04 Dec 2007 15:54:55 -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.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lB4KssH9022616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 4 Dec 2007 12:54:54 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lB4KsrEY026858 for ; Tue, 4 Dec 2007 12:54:53 -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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lB4Ksq7M026757 for ; Tue, 4 Dec 2007 12:54:53 -0800 (PST) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 12:54:52 -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 Date: Tue, 4 Dec 2007 12:54:24 -0800 Message-ID: <08590A72DC26A54B85632FF97C2C22DA019ED56C@XCH-NW-5V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OSPF-MDR in Quagga Thread-Index: Acg2uAQRkWjlvOJiSZyxNkVJ9yogew== From: "Spagnolo, Phillip A" To: X-OriginalArrivalTime: 04 Dec 2007 20:54:52.0473 (UTC) FILETIME=[EAB56290:01C836B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [OSPF] OSPF-MDR in Quagga 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 Joe, During the meeting, you asked when Boeing will release an update to the OSPF-MDR Quagga implementation. We are actively cleaning up the code right now. We plan to release this code in the near future. The new code will contain the OSPF-MDR draft 7 and Address Families which we haven't previously released. It supports IPv4 or IPv6 data routing over a v6 control plane. Sincerely, Phil Phillip A. Spagnolo M&CT Network Technology Boeing Phantom Works 425-373-2810 phillip.a.spagnolo@boeing.com _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Dec 05 20:18:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05NP-0000mP-BC; Wed, 05 Dec 2007 20:18:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05NO-0000m9-45 for ospf@ietf.org; Wed, 05 Dec 2007 20:18:06 -0500 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J05NM-00024l-A0 for ospf@ietf.org; Wed, 05 Dec 2007 20:18:06 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=lMpZdqna3oJqMsnQy7NPe5CnVKQ1ZdWwIUNTcgsUMSgaxq8cNVT94RIxn4gSgIY1; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.245.103.22] (helo=[4.245.103.22]) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J05NK-0001AY-KE; Wed, 05 Dec 2007 20:18:04 -0500 Message-ID: <47574E50.4010104@earthlink.net> Date: Wed, 05 Dec 2007 17:20:16 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ospf@ietf.org Subject: Re: [OSPF] OSPF-MDR options References: <08590A72DC26A54B85632FF97C2C22DA019ED569@XCH-NW-5V2.nw.nos.boeing.com> In-Reply-To: <08590A72DC26A54B85632FF97C2C22DA019ED569@XCH-NW-5V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478f72793e7d63ff910c8ff3564dd2f719dd22e4140d2460141350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.245.103.22 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 All, I listened to the audio recording of the meeting, and will respond to the comments by the authors of INRIA's proposal for OSPF-MANET (Emmanuel Baccelli and Thomas Clausen). I will mainly respond to the comments that there may be too many options, and that it is not clear which options are preferred and which are compatible with each other. I may not have fully understood all of the comments/questions, so feel free to ask questions. Phil already summarized the main options, so this will complement his message. First, I agree that clearer guidance could be provided for choosing among the different options (although I think such guidance can be found interspersed throughout the draft), so we will work on providing this. As Phil mentioned, these options provide a good deal of flexibility, and I consider this to be one of the advantages over INRIA's proposal. It may very well be that some of these options will be dropped if OSPF-MDR becomes standards track, but since the intended status is Experimental, I think it would be good to experiment with the different options before eliminating any. For example, one can use either partial-topology LSAs or full-topology LSAs, either with or without adjacency reduction. The only restriction is that LSAFullness = 0 (minimal LSAs) cannot be used with AdjConnectivity = 0 (no adjacency reduction), since this would result in empty LSAs, and this is mentioned in Section 9.2.1. Thomas mentioned that with all the options, OSPF-MDR appears to be multiple protocols, rather than a single protocol. The reason that OSPF-MDR is NOT multiple protocols is because it has a single main (default) configuration, and has several options that require very little additional coding (in addition to the default configuration). In contrast, multiple protocols would have a separate chunk of code for each protocol that is not used by the other protocols. The main default configuration is AdjConnectivity = 1 and LSAFullness = 1 (with the other default parameter values). This is the most scalable configuration that provides shortest-path routing. One example of an optional configuration is to instead use LSAFullness = 4, which simply includes all routable neighbors in the router-LSA, to provide full-topology LSAs. Similarly, one can use AdjConnectivity = 0 so that each router becomes adjacent with each neighbor. One might argue that the LSAFullness = 0 option (minimal LSAs) should be omitted, since it does not provide shortest-path routing. However, implementing this option requires almost no additional code once the default configuration is implemented, i.e., it essentially comes for free. It's advantage is that it achieves a significant reduction in overhead and therefore may allow scalability to larger networks. Therefore, I think it makes sense to keep this option, at least for the Experimental draft. Richard _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Dec 06 14:40:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MZq-00072y-V8; Thu, 06 Dec 2007 14:40:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MZp-0006zW-5b for ospf@ietf.org; Thu, 06 Dec 2007 14:40:05 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0MZo-0002xo-GT for ospf@ietf.org; Thu, 06 Dec 2007 14:40:05 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=aD9JFOGJr9Yx2cPLVUJGU2MW1555wV3PAAg7k9PVu1dSeczCMr8JDym/xvNB07kk; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.245.98.249] (helo=[4.245.98.249]) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J0MZl-0000T2-8D; Thu, 06 Dec 2007 14:40:03 -0500 Message-ID: <47585099.9030108@earthlink.net> Date: Thu, 06 Dec 2007 11:42:17 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Clausen Subject: Re: [OSPF] OSPF-MDR options References: <08590A72DC26A54B85632FF97C2C22DA019ED569@XCH-NW-5V2.nw.nos.boeing.com> <47574E50.4010104@earthlink.net> <2D9DF80A-AC4C-4307-B269-2EEA5FEB2F09@computer.org> In-Reply-To: <2D9DF80A-AC4C-4307-B269-2EEA5FEB2F09@computer.org> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478f72793e7d63ff91090ebc7830ff2ea6420c23c3b10cb0ab5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.245.98.249 X-Spam-Score: 1.7 (+) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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="===============0428397834==" Errors-To: ospf-bounces@ietf.org --===============0428397834== Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas Clausen wrote:

On Dec 6, 2007, at 2:20 AM, Richard Ogier wrote:
All, I listened to the audio recording of the meeting, and will respond to the comments by the authors of INRIA's proposal for OSPF-MANET (Emmanuel Baccelli and Thomas Clausen).
Y'know, I am not with INRIA, right? :)

I know, but most of the authors are with INRIA.

Thomas mentioned that with all the options, OSPF-MDR appears to be multiple protocols, rather than a single protocol. The reason that OSPF-MDR is NOT multiple protocols is because it has a single main (default) configuration, and has several options that require very little additional coding (in addition to the default configuration). In contrast, multiple protocols would have a separate chunk of code for each protocol that is not used by the other protocols.
I am not sure that I agree that the number of code-lines to change is a good measure as to what is and is not one protocol, so I'll clarify a bit what I meant. To me, I consider that (i) compatibility of the information conveyed in signaling, and (ii) compatibility of operation are what determines if two "pieces of code" implement the same or different protocols -- or maybe rather, that an protocol specification should contain what is necessary for interoperability. It seems to me that the OSPF-MDR options -- despite perhaps being implementable in a similar number of code-lines -- do not yield interoperability between two different "pieces of code" with each activating different options. Is this not accurate?

I think I understand what you mean now. I think you are talking about the interoperability of two routers using different options. (My previous interpretation addressed which combinations of parameter values are allowed for a given router, which I think was also an issue raised at the meeting.) OSPF handles this by rejecting Hello packets received from neighbors that have selected options or parameters that do not match that of the receiving interface. For example, the HelloInterval of a received Hello must match that of the receiving interface. Although ideally all routers should select the same values for LSAFullness and AdjConnectivity, OSPF-MDR was carefully designed to allow different routers to select different values for these parameters. For example, the last paragraph of Section 2.5 states: "The above LSA options are interoperable with each other, because they all require the router-LSA to include a minimum set of neighbors, and because the construction of the router-LSA (described in Section 9.2.3) ensures that the router-LSAs originated by different routers are consistent." Also, it is allowable for some routers to choose AdjConnectivity = 1 (uniconnected adjacencies) while others choose AdjConnectivity = 2 (biconnected adjacencies). The only constraint is the following, as stated in Section 3.2: "AdjConnectivity MUST either be zero for all routers or nonzero (1 or 2) for all routers." Thus, the only case in which interoperability is an issue is if some routers use adjacency reduction while others do not. This can be handled by adding an option bit for adjacency reduction to the Hello TLV, and rejecting Hellos when this bit does not match the receiving interface. I recently thought about adding such a bit, but decided to wait for comments. I will plan to add such a bit in the next draft update. Richard

Cheers, Thomas

--===============0428397834== 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 --===============0428397834==-- From ospf-bounces@ietf.org Thu Dec 06 15:03:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Mwg-00055c-7s; Thu, 06 Dec 2007 15:03:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Mwe-00055X-NM for ospf@ietf.org; Thu, 06 Dec 2007 15:03:40 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Mwe-00042I-6d for ospf@ietf.org; Thu, 06 Dec 2007 15:03:40 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=knunekkxKZLWPZYr+Ccv+TaKkaPUxbQBabRwgXCixar0/sl+CeYcg/zGmgU05jUw; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.245.99.37] (helo=[4.245.99.37]) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J0Mwb-0006o3-LR; Thu, 06 Dec 2007 15:03:40 -0500 Message-ID: <47585622.9020804@earthlink.net> Date: Thu, 06 Dec 2007 12:05:54 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: T.Clausen@computer.org Subject: Re: [OSPF] OSPF-MDR options Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478f72793e7d63ff9106b567e065fdd0532864d88f383b478a8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.245.99.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 I just realized an error in my last paragraph. Here is a corrected paragraph: Thus, the only case in which interoperability is an issue is if some routers use adjacency reduction while others do not. This can be handled by adding an option bit for adjacency reduction to the Hello TLV, and always forming an adjacency with a neighbor that has selected LSAFullness = 0. I recently thought about adding such a bit, but decided to wait for comments. I will plan to add such a bit in the next draft update. With this option bit, interoperability is achieved even if each router chooses LSAFullness and AdjConnectivity independently of the other routers. Richard Thomas Clausen wrote: > > On Dec 6, 2007, at 2:20 AM, Richard Ogier wrote: > >> All, >> >> I listened to the audio recording of the meeting, and will >> respond to the comments by the authors of INRIA's proposal for >> OSPF-MANET (Emmanuel Baccelli and Thomas Clausen). >> > > Y'know, I am not with INRIA, right? :) I know, but most of the authors are with INRIA. > >> Thomas mentioned that with all the options, OSPF-MDR appears >> to be multiple protocols, rather than a single protocol. >> The reason that OSPF-MDR is NOT multiple protocols is because >> it has a single main (default) configuration, and has several >> options that require very little additional coding (in addition >> to the default configuration). >> In contrast, multiple protocols would have a separate chunk of >> code for each protocol that is not used by the other protocols. > > > I am not sure that I agree that the number of code-lines to change is > a good measure as to what is and is not one protocol, so I'll clarify > a bit what I meant. > > To me, I consider that (i) compatibility of the information conveyed > in signaling, and (ii) compatibility of operation are what determines > if two "pieces of code" implement the same or different protocols -- > or maybe rather, that an protocol specification should contain what > is necessary for interoperability. > > It seems to me that the OSPF-MDR options -- despite perhaps being > implementable in a similar number of code-lines -- do not yield > interoperability between two different "pieces of code" with each > activating different options. Is this not accurate? I think I understand what you mean now. I think you are talking about the interoperability of two routers using different options. (My previous interpretation addressed which combinations of parameter values are allowed for a given router, which I think was also an issue raised at the meeting.) OSPF handles this by rejecting Hello packets received from neighbors that have selected options or parameters that do not match that of the receiving interface. For example, the HelloInterval of a received Hello must match that of the receiving interface. Although ideally all routers should select the same values for LSAFullness and AdjConnectivity, OSPF-MDR was carefully designed to allow different routers to select different values for these parameters. For example, the last paragraph of Section 2.5 states: "The above LSA options are interoperable with each other, because they all require the router-LSA to include a minimum set of neighbors, and because the construction of the router-LSA (described in Section 9.2.3) ensures that the router-LSAs originated by different routers are consistent." Also, it is allowable for some routers to choose AdjConnectivity = 1 (uniconnected adjacencies) while others choose AdjConnectivity = 2 (biconnected adjacencies). The only constraint is the following, as stated in Section 3.2: "AdjConnectivity MUST either be zero for all routers or nonzero (1 or 2) for all routers." Thus, the only case in which interoperability is an issue is if some routers use adjacency reduction while others do not. This can be handled by adding an option bit for adjacency reduction to the Hello TLV, and rejecting Hellos when this bit does not match the receiving interface. I recently thought about adding such a bit, but decided to wait for comments. I will plan to add such a bit in the next draft update. Richard > > Cheers, > > Thomas > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From dkoerner@outdoorpatiolight.com Thu Dec 06 22:32:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0TwW-00045T-Ti; Thu, 06 Dec 2007 22:32:00 -0500 Received: from [190.173.30.168] (helo=desktop) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0TwV-0003a9-PY; Thu, 06 Dec 2007 22:32:00 -0500 Received: from [190.173.30.168] by smtp.secureserver.net; Fri, 7 Dec 2007 05:34:54 +0200 From: "Kyra Nolan" To: Subject: It can help children Date: Fri, 7 Dec 2007 05:34:54 +0200 Message-ID: <01c83892$e5181300$a81eadbe@dkoerner> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Hi I'm 23 years old I read your profile online and I was intrested in getting to know you better Reply to me and tell me about yourself if you want to chat I will send a pic and some of my info right away email me at Circle@EngineRide.info , that will be sent to me directly Thank you From ospf-bounces@ietf.org Fri Dec 07 00:00:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0VK2-0002py-5a; Fri, 07 Dec 2007 00:00:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0VK0-0002ps-Ph for ospf@ietf.org; Fri, 07 Dec 2007 00:00:20 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0VK0-0006XE-Dp for ospf@ietf.org; Fri, 07 Dec 2007 00:00:20 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id lB750Jq5028051 for ; Fri, 7 Dec 2007 00:00:19 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lB750JsJ117274 for ; Thu, 6 Dec 2007 22:00:19 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lB750Ji7004200 for ; Thu, 6 Dec 2007 22:00:19 -0700 Received: from d03nmx01.boulder.ibm.com (d03nmx01.boulder.ibm.com [9.17.195.63]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lB750Juo004185 for ; Thu, 6 Dec 2007 22:00:19 -0700 From: Edgar Polanco Gomez/Mexico/IBM To: ospf@ietf.org Message-ID: Date: Thu, 6 Dec 2007 22:00:17 -0700 X-MIMETrack: Serialize by Router on D03NMX01/03/M/IBM(Release 7.0.2FP2HF366 | October 15, 2007) at 12/06/2007 22:00:18 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [OSPF] Edgar Polanco Gomez is out of the office. 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 will be out of the office starting 12/06/2007 and will not return until 12/07/2007. I will respond to your message when I return. For anything urgent related to SNA CPS, please contact to Luz Estela Rios (leri@mx1.ibm.com). For anything related to RIPng or OSPF please contact Jose Delgado (josedel@mx1.ibm.com). For anything else contact my manager Lupita Torres (ltorres@mx1.ibm.com) _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Dec 07 09:13:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0dx0-0000nZ-UA; Fri, 07 Dec 2007 09:13:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0dx0-0000lK-DR for ospf@ietf.org; Fri, 07 Dec 2007 09:13:10 -0500 Received: from mail1-relais-roc.national.inria.fr ([192.134.164.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0dwz-00066E-Ag for ospf@ietf.org; Fri, 07 Dec 2007 09:13:10 -0500 X-IronPort-AV: E=Sophos;i="4.23,267,1194217200"; d="scan'208";a="5386031" Received: from unknown (HELO [192.168.112.250]) ([129.104.11.1]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Dec 2007 15:13:08 +0100 Message-ID: <475954F3.2070400@inria.fr> Date: Fri, 07 Dec 2007 15:13:07 +0100 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.13 (Macintosh/20070809) MIME-Version: 1.0 To: ospf@ietf.org Subject: Re: [OSPF] OSPF-MDR options References: <08590A72DC26A54B85632FF97C2C22DA019ED569@XCH-NW-5V2.nw.nos.boeing.com> <47574E50.4010104@earthlink.net> <2D9DF80A-AC4C-4307-B269-2EEA5FEB2F09@computer.org> <47585099.9030108@earthlink.net> In-Reply-To: <47585099.9030108@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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 All, I didn't listen to the audio recording of the meeting, therefore I don't know how the question of options came out from the discussion. I will just only give my general feeling. I feel there are two kinds of options in network protocol engineering: the upward options and the downward options. The upward options are when they add functions to the protocol that can be used by the user. For example the kind of metric used, the auto-configuration protocols, etc. The aims of the protocol are changed by upward options. The downward options are when the aims of the protocol are not changed but the conditions of use (the lower layers) change. For example if the protocol is used on wireless, on electric wires, or on gas. According to the current discussion it may look that the MDR options might be more downward options than upward options. In this case the condition of application should be very clearly stated. This is easy if it is related to some physical aspect of the router such as to distinguish between a wireless interface or a wired interface. But this is less easy when the options are related to some scenario situation. An open wireless network is subject to scenario changes, therefore the options should be changed during operations and this would require: - an automaton that distinguish when the current scenario conditions change - a distributed consensus protocol that make the whole network to switch consistently from one option to another. As engineers we all love to have options in order to play indefinitely with them, and this may be OK for experimental status. But if we consider a non expert user, imagine a soldier on a battlefield, I don't know how he will select the best option in the case the radio device displays a switch for this. I hope this helps. Best regards, Philippe Richard Ogier a écrit : > Thomas Clausen wrote: >> >> On Dec 6, 2007, at 2:20 AM, Richard Ogier wrote: >> >>> All, >>> >>> I listened to the audio recording of the meeting, and will >>> respond to the comments by the authors of INRIA's proposal for >>> OSPF-MANET (Emmanuel Baccelli and Thomas Clausen). >>> >> >> Y'know, I am not with INRIA, right? :) > I know, but most of the authors are with INRIA. >> >>> Thomas mentioned that with all the options, OSPF-MDR appears >>> to be multiple protocols, rather than a single protocol. >>> The reason that OSPF-MDR is NOT multiple protocols is because >>> it has a single main (default) configuration, and has several >>> options that require very little additional coding (in addition >>> to the default configuration). >>> In contrast, multiple protocols would have a separate chunk of >>> code for each protocol that is not used by the other protocols. >> >> I am not sure that I agree that the number of code-lines to change is >> a good measure as to what is and is not one protocol, so I'll clarify >> a bit what I meant. >> >> To me, I consider that (i) compatibility of the information conveyed >> in signaling, and (ii) compatibility of operation are what determines >> if two "pieces of code" implement the same or different protocols -- >> or maybe rather, that an protocol specification should contain what >> is necessary for interoperability. >> >> It seems to me that the OSPF-MDR options -- despite perhaps being >> implementable in a similar number of code-lines -- do not yield >> interoperability between two different "pieces of code" with each >> activating different options. Is this not accurate? > > I think I understand what you mean now. I think you are talking about > the interoperability of two routers using different options. (My > previous interpretation addressed which combinations of parameter values > are allowed for a given router, which I think was also an issue raised > at the meeting.) > > OSPF handles this by rejecting Hello packets received from neighbors > that have selected options or parameters that do not match that of the > receiving interface. For example, the HelloInterval of a received Hello > must match that of the receiving interface. > > Although ideally all routers should select the same values for > LSAFullness and AdjConnectivity, OSPF-MDR was carefully designed to > allow different routers to select different values for these > parameters. For example, the last paragraph of Section 2.5 states: > > / / "The above LSA options are interoperable with each other, because they > all require the router-LSA to include a minimum set of neighbors, and > because the construction of the router-LSA (described in Section > 9.2.3) ensures that the router-LSAs originated by different routers > are consistent." > > Also, it is allowable for some routers to choose AdjConnectivity = 1 > (uniconnected adjacencies) while others choose AdjConnectivity = 2 > (biconnected adjacencies). The only constraint is the following, as > stated in Section 3.2: > > "AdjConnectivity MUST either be zero for all routers or nonzero (1 > or 2) for all routers." > > Thus, the only case in which interoperability is an issue is if some > routers use adjacency reduction while others do not. This can be > handled by adding an option bit for adjacency reduction to the Hello > TLV, and rejecting Hellos when this bit does not match the receiving > interface. I recently thought about adding such a bit, but decided to > wait for comments. I will plan to add such a bit in the next draft update. > > Richard > > >> >> Cheers, >> >> Thomas >> > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Fri Dec 07 13:50:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0iHa-0006do-28; Fri, 07 Dec 2007 13:50:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0iHY-0006bi-It for ospf@ietf.org; Fri, 07 Dec 2007 13:50:40 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0iHX-0001AH-VI for ospf@ietf.org; Fri, 07 Dec 2007 13:50:40 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gfJ8XMgsbhGxggpPRUv9EHtZchMmZXmbnSGmikhFfonnCufAIcBC1sf5BHDHfRd5; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.246.93.71] (helo=[4.246.93.71]) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J0iHW-0008Ks-3b; Fri, 07 Dec 2007 13:50:39 -0500 Message-ID: <47599688.9070406@earthlink.net> Date: Fri, 07 Dec 2007 10:52:56 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philippe Jacquet Subject: Re: [OSPF] OSPF-MDR options References: <08590A72DC26A54B85632FF97C2C22DA019ED569@XCH-NW-5V2.nw.nos.boeing.com> <47574E50.4010104@earthlink.net> <2D9DF80A-AC4C-4307-B269-2EEA5FEB2F09@computer.org> <47585099.9030108@earthlink.net> <475954F3.2070400@inria.fr> In-Reply-To: <475954F3.2070400@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787b0d50f491adcf1e0d56f8de8143237b47e17a8a4f8a68d7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.93.71 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Philippe, The MDR draft gives some guidance regarding the options, e.g., that uniconnected adjacencies and partial-topology LSAs should be used to minimize overhead, but I agree that it would be good to include a better explanation of parameter choices. The default configuration is recommended for most scenarios. The optional configurations are included either because some people have expressed a preference to use full-topology adjacencies and LSAs (which also simplifies the protocol), or to provide greater scalability (LSAFullness = 0) or greater robustness (AdjConnectivity = 2). More experimentation is needed to evaluate the benefits of these optional configurations. I expect that the configuration will be selected before deployment depending on the scenario, and not changed during operations based on automatic scenario recognition. However, if one chooses to change the parameters during operations, a nice property of OSPF-MDR is that each router can change its options independently of the other routers (as discussed in my previous message). BTW, I noticed an error in the "corrected" paragraph of my previous message: "LSAFullness" should be changed to "AdjConnectivity", as follows: Thus, the only case in which interoperability is an issue is if some routers use adjacency reduction while others do not. This can be handled by adding an option bit for adjacency reduction to the Hello TLV, and always forming an adjacency with a neighbor that has selected AdjConnectivity = 0 (no adjacency reduction). With this option bit, interoperability is achieved even if each router chooses LSAFullness and AdjConnectivity independently of the other routers. Richard Philippe Jacquet wrote: > All, > > I didn't listen to the audio recording of the meeting, therefore I > don't know how the question of options came out from the discussion. I > will just only give my general feeling. > > I feel there are two kinds of options in network protocol engineering: > the upward options and the downward options. > > The upward options are when they add functions to the protocol that > can be used by the user. For example the kind of metric used, the > auto-configuration protocols, etc. The aims of the protocol are > changed by upward options. > > The downward options are when the aims of the protocol are not changed > but the conditions of use (the lower layers) change. For example if > the protocol is used on wireless, on electric wires, or on gas. > > According to the current discussion it may look that the MDR options > might be more downward options than upward options. In this case the > condition of application should be very clearly stated. This is easy > if it is related to some physical aspect of the router such as to > distinguish between a wireless interface or a wired interface. But > this is less easy when the options are related to some scenario > situation. An open wireless network is subject to scenario changes, > therefore the options should be changed during operations and this > would require: > - an automaton that distinguish when the current scenario conditions > change > - a distributed consensus protocol that make the whole network to > switch consistently from one option to another. > > As engineers we all love to have options in order to play indefinitely > with them, and this may be OK for experimental status. But if we > consider a non expert user, imagine a soldier on a battlefield, I > don't know how he will select the best option in the case the radio > device displays a switch for this. > > I hope this helps. > > Best regards, > Philippe > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Dec 07 14:23:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0in3-0000cm-NF; Fri, 07 Dec 2007 14:23:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0in2-0000cf-1t for ospf@ietf.org; Fri, 07 Dec 2007 14:23:12 -0500 Received: from sernt12.essex.ac.uk ([155.245.48.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0in1-0003XM-Al for ospf@ietf.org; Fri, 07 Dec 2007 14:23:11 -0500 Received: from sernt14.essex.ac.uk ([155.245.48.26]) by sernt12.essex.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Dec 2007 19:23:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [OSPF] OSPF-MDR options Date: Fri, 7 Dec 2007 19:18:35 -0000 Message-ID: <7AC902A40BEDD411A3A800D0B7847B661CEAD95F@sernt14.essex.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF-MDR options Thread-Index: Acg5Ai7LAu7g0wuSSb2zTDOehfjTbgAA8ee1 References: <08590A72DC26A54B85632FF97C2C22DA019ED569@XCH-NW-5V2.nw.nos.boeing.com> <47574E50.4010104@earthlink.net> <2D9DF80A-AC4C-4307-B269-2EEA5FEB2F09@computer.org> <47585099.9030108@earthlink.net> <475954F3.2070400@inria.fr> <47599688.9070406@earthlink.net> From: "Thomas, Matthew R" To: "Richard Ogier" , "Philippe Jacquet" X-OriginalArrivalTime: 07 Dec 2007 19:23:06.0812 (UTC) FILETIME=[98516FC0:01C83906] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Philippe for that last clarification. It took me back to the = drawing board to make sure I understood the Fullness :o) With the type = of scarios needing to be covered these features seem to be a minimum = required. The fact that the routers can independently change and still = work together is very useful. =20 Matthew ________________________________ From: Richard Ogier [mailto:ogier@earthlink.net] Sent: Fri 07/12/2007 18:52 To: Philippe Jacquet Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF-MDR options Philippe, The MDR draft gives some guidance regarding the options, e.g., that uniconnected adjacencies and partial-topology LSAs should be used to minimize overhead, but I agree that it would be good to include a better explanation of parameter choices. The default configuration is recommended for most scenarios. The optional configurations are included either because some people have expressed a preference to use full-topology adjacencies and LSAs (which also simplifies the protocol), or to provide greater scalability (LSAFullness =3D 0) or greater robustness (AdjConnectivity =3D 2). More experimentation is needed to evaluate the benefits of these optional configurations. I expect that the configuration will be selected before deployment depending on the scenario, and not changed during operations based on automatic scenario recognition. However, if one chooses to change the parameters during operations, a nice property of OSPF-MDR is that each router can change its options independently of the other routers (as discussed in my previous message). BTW, I noticed an error in the "corrected" paragraph of my previous message: "LSAFullness" should be changed to "AdjConnectivity", as = follows: Thus, the only case in which interoperability is an issue is if some routers use adjacency reduction while others do not. This can be handled by adding an option bit for adjacency reduction to the Hello TLV, and always forming an adjacency with a neighbor that has selected AdjConnectivity =3D 0 (no adjacency reduction). With this option bit, interoperability is achieved even if each router chooses LSAFullness and AdjConnectivity independently of the other routers. Richard Philippe Jacquet wrote: > All, > > I didn't listen to the audio recording of the meeting, therefore I > don't know how the question of options came out from the discussion. I > will just only give my general feeling. > > I feel there are two kinds of options in network protocol engineering: > the upward options and the downward options. > > The upward options are when they add functions to the protocol that > can be used by the user. For example the kind of metric used, the > auto-configuration protocols, etc. The aims of the protocol are > changed by upward options. > > The downward options are when the aims of the protocol are not changed > but the conditions of use (the lower layers) change. For example if > the protocol is used on wireless, on electric wires, or on gas. > > According to the current discussion it may look that the MDR options > might be more downward options than upward options. In this case the > condition of application should be very clearly stated. This is easy > if it is related to some physical aspect of the router such as to > distinguish between a wireless interface or a wired interface. But > this is less easy when the options are related to some scenario > situation. An open wireless network is subject to scenario changes, > therefore the options should be changed during operations and this > would require: > - an automaton that distinguish when the current scenario conditions > change > - a distributed consensus protocol that make the whole network to > switch consistently from one option to another. > > As engineers we all love to have options in order to play indefinitely > with them, and this may be OK for experimental status. But if we > consider a non expert user, imagine a soldier on a battlefield, I > don't know how he will select the best option in the case the radio > device displays a switch for this. > > I hope this helps. > > Best regards, > Philippe > > _______________________________________________ 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 Fri Dec 07 14:25:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ior-0001ia-Dj; Fri, 07 Dec 2007 14:25:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ioq-0001iM-FV for ospf@ietf.org; Fri, 07 Dec 2007 14:25:04 -0500 Received: from sernt12.essex.ac.uk ([155.245.48.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0ioo-0004Gq-Iq for ospf@ietf.org; Fri, 07 Dec 2007 14:25:04 -0500 Received: from sernt14.essex.ac.uk ([155.245.48.26]) by sernt12.essex.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Dec 2007 19:25:01 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [OSPF] OSPF-MDR options Date: Fri, 7 Dec 2007 19:23:48 -0000 Message-ID: <7AC902A40BEDD411A3A800D0B7847B661CEAD960@sernt14.essex.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF-MDR options Thread-Index: Acg5Ai7LAu7g0wuSSb2zTDOehfjTbgAA8ee1AAAusKU= References: <08590A72DC26A54B85632FF97C2C22DA019ED569@XCH-NW-5V2.nw.nos.boeing.com> <47574E50.4010104@earthlink.net> <2D9DF80A-AC4C-4307-B269-2EEA5FEB2F09@computer.org> <47585099.9030108@earthlink.net> <475954F3.2070400@inria.fr> <47599688.9070406@earthlink.net> <7AC902A40BEDD411A3A800D0B7847B661CEAD95F@sernt14.essex.ac.uk> From: "Thomas, Matthew R" To: X-OriginalArrivalTime: 07 Dec 2007 19:25:01.0333 (UTC) FILETIME=[DC93F450:01C83906] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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 Sorry I meant "Thanks Richard".. my turn for a typo.. ________________________________ From: Thomas, Matthew R Sent: Fri 07/12/2007 19:18 To: Richard Ogier; Philippe Jacquet Cc: ospf@ietf.org Subject: RE: [OSPF] OSPF-MDR options Thanks Philippe for that last clarification. It took me back to the = drawing board to make sure I understood the Fullness :o) With the type = of scarios needing to be covered these features seem to be a minimum = required. The fact that the routers can independently change and still = work together is very useful. =20 Matthew ________________________________ From: Richard Ogier [mailto:ogier@earthlink.net] Sent: Fri 07/12/2007 18:52 To: Philippe Jacquet Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF-MDR options Philippe, The MDR draft gives some guidance regarding the options, e.g., that uniconnected adjacencies and partial-topology LSAs should be used to minimize overhead, but I agree that it would be good to include a better explanation of parameter choices. The default configuration is recommended for most scenarios. The optional configurations are included either because some people have expressed a preference to use full-topology adjacencies and LSAs (which also simplifies the protocol), or to provide greater scalability (LSAFullness =3D 0) or greater robustness (AdjConnectivity =3D 2). More experimentation is needed to evaluate the benefits of these optional configurations. I expect that the configuration will be selected before deployment depending on the scenario, and not changed during operations based on automatic scenario recognition. However, if one chooses to change the parameters during operations, a nice property of OSPF-MDR is that each router can change its options independently of the other routers (as discussed in my previous message). BTW, I noticed an error in the "corrected" paragraph of my previous message: "LSAFullness" should be changed to "AdjConnectivity", as = follows: Thus, the only case in which interoperability is an issue is if some routers use adjacency reduction while others do not. This can be handled by adding an option bit for adjacency reduction to the Hello TLV, and always forming an adjacency with a neighbor that has selected AdjConnectivity =3D 0 (no adjacency reduction). With this option bit, interoperability is achieved even if each router chooses LSAFullness and AdjConnectivity independently of the other routers. Richard Philippe Jacquet wrote: > All, > > I didn't listen to the audio recording of the meeting, therefore I > don't know how the question of options came out from the discussion. I > will just only give my general feeling. > > I feel there are two kinds of options in network protocol engineering: > the upward options and the downward options. > > The upward options are when they add functions to the protocol that > can be used by the user. For example the kind of metric used, the > auto-configuration protocols, etc. The aims of the protocol are > changed by upward options. > > The downward options are when the aims of the protocol are not changed > but the conditions of use (the lower layers) change. For example if > the protocol is used on wireless, on electric wires, or on gas. > > According to the current discussion it may look that the MDR options > might be more downward options than upward options. In this case the > condition of application should be very clearly stated. This is easy > if it is related to some physical aspect of the router such as to > distinguish between a wireless interface or a wired interface. But > this is less easy when the options are related to some scenario > situation. An open wireless network is subject to scenario changes, > therefore the options should be changed during operations and this > would require: > - an automaton that distinguish when the current scenario conditions > change > - a distributed consensus protocol that make the whole network to > switch consistently from one option to another. > > As engineers we all love to have options in order to play indefinitely > with them, and this may be OK for experimental status. But if we > consider a non expert user, imagine a soldier on a battlefield, I > don't know how he will select the best option in the case the radio > device displays a switch for this. > > I hope this helps. > > Best regards, > Philippe > > _______________________________________________ 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 lechat.Minton@armannski.is Sun Dec 09 05:39:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1JZI-0001l4-6Q for ospf-archive@megatron.ietf.org; Sun, 09 Dec 2007 05:39:28 -0500 Received: from i04m-87-90-83-132.d4.club-internet.fr ([87.90.83.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1JZG-0001Ar-MC for ospf-archive@megatron.ietf.org; Sun, 09 Dec 2007 05:39:26 -0500 Received: from maingraud ([197.102.148.4] helo=maingraud) by i04m-87-90-83-132.d4.club-internet.fr ( sendmail 8.13.3/8.13.1) with esmtpa id 1FGQnF-000IDN-Qi for ospf-archive@megatron.ietf.org; Sun, 9 Dec 2007 11:40:13 +0100 Message-ID: Date: Sun, 9 Dec 2007 11:39:39 +0100 From: "lechat Minton" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: fidences Content-Type: multipart/alternative; boundary="------------000707080104000402020503" X-Antivirus: avast! (VPS 071208-0, 08/12/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.5 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 --------------000707080104000402020503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit i'd be scared too if my dick was that small http://illyoung.com/ --------------000707080104000402020503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit i'd be scared too if my dick was that small http://illyoung.com/
--------------000707080104000402020503-- From Pechacekootgv@theclclaw.com Sun Dec 09 11:46:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1PIJ-0005ts-LO for ospf-archive@megatron.ietf.org; Sun, 09 Dec 2007 11:46:19 -0500 Received: from aazc102.neoplus.adsl.tpnet.pl ([83.6.140.102] helo=abbm103.neoplus.adsl.tpnet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1PIJ-00032Q-5C for ospf-archive@megatron.ietf.org; Sun, 09 Dec 2007 11:46:19 -0500 Received: from dom-57b636cf262 by theclclaw.com with ASMTP id B35CAE81 for ; Sun, 9 Dec 2007 17:47:01 +0100 Received: from dom-57b636cf262 ([113.127.48.127]) by theclclaw.com with ESMTP id E786C6045A71 for ; Sun, 9 Dec 2007 17:47:01 +0100 Message-ID: <0BC4D026.047C1D83@theclclaw.com> Date: Sun, 9 Dec 2007 17:46:24 +0100 From: "jinah Pechacek" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: anglions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 stretch her ass wide open with your new dick size http://illtuft.com/ From chin@stswithuns.com Sun Dec 09 18:22:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1VTv-0007ga-Rp for ospf-archive@lists.ietf.org; Sun, 09 Dec 2007 18:22:43 -0500 Received: from dsl-p7-208.gibconnect.com ([212.120.224.208]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1VTv-0000D3-8y for ospf-archive@lists.ietf.org; Sun, 09 Dec 2007 18:22:43 -0500 Received: from [212.120.224.208] by dns02e.hants.gov.uk; Sun, 09 Dec 2007 23:22:42 +0000 Message-ID: <000801c83aba$05bc8ec8$2e1c9c9b@jhvgnc> From: "gabbie jong" To: Subject: Home-based job opportunity Date: Sun, 09 Dec 2007 21:35:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.6 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 We are Looking for partners worldwide. The position is home-based. Our Company Head Office is located in UK with branches all over the world. We are looking for talented, honest, reliable representatives from different regions. The ideal candidate will be an intelligent person, someone who can work autonomously with a high degree of enthusiasm. Our Company offers a very competitive salary to the successful candidate, along with an unrivalled career progression opportunity. If you would like to work with our active, dynamic team, we invite you to apply for employment. Preference will be given to applicants with knowledge of multiple languages. Please send the following information to MiloMcconnellNG@gmail.com. 1. Full name 2 Address of residence 3 Contact Phone numbers 4 Languages spoken 5 Whether you are interested in part time job or full time employment. Thank you. We look forward to working with you. If you received this message in error, please send a blank email to: CyrusPhillipsKH@gmail.com. From ewan@i-gts.com Sun Dec 09 18:41:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1Vm0-0007U2-AC for ospf-archive@megatron.ietf.org; Sun, 09 Dec 2007 18:41:24 -0500 Received: from [201.30.97.135] (helo=201.30.97.135) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1Vlz-0000bk-D0 for ospf-archive@megatron.ietf.org; Sun, 09 Dec 2007 18:41:24 -0500 Received: from [201.30.97.135] by dns.netvision.net.il; Sun, 09 Dec 2007 23:49:41 +0000 Message-ID: <000901c83abe$07ebd547$4f25929c@qlaigdqo> From: "gerrit ikuo" To: Subject: High paid position with us Date: Sun, 09 Dec 2007 22:02:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.7 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 We are Looking for partners worldwide. The position is home-based. Our Company Head Office is located in UK with branches all over the world. We are looking for talented, honest, reliable representatives from different regions. The ideal candidate will be an intelligent person, someone who can work autonomously with a high degree of enthusiasm. Our Company offers a very competitive salary to the successful candidate, along with an unrivalled career progression opportunity. If you would like to work with our active, dynamic team, we invite you to apply for employment. Preference will be given to applicants with knowledge of multiple languages. Please send the following information to EverettMayoJA@gmail.com. 1. Full name 2 Address of residence 3 Contact Phone numbers 4 Languages spoken 5 Whether you are interested in part time job or full time employment. Thank you. We look forward to working with you. If you received this message in error, please send a blank email to: OdisShafferMX@gmail.com. From guanersan@neera.screaming.net Mon Dec 10 07:45:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1i0w-0007E1-LP for ospf-archive@megatron.ietf.org; Mon, 10 Dec 2007 07:45:38 -0500 Received: from ip-89-102-194-48.karneval.cz ([89.102.194.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1i0w-0002h9-6M for ospf-archive@megatron.ietf.org; Mon, 10 Dec 2007 07:45:38 -0500 Received: by 10.15.86.13 with SMTP id hHmwNDuFYcGSB; Mon, 10 Dec 2007 13:47:51 +0100 (GMT) Received: by 192.168.36.219 with SMTP id laiFLOJUJWeRLz.8224586936992; Mon, 10 Dec 2007 13:47:49 +0100 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Dec 2007 13:47:46 +0100 To: ospf-archive@megatron.ietf.org From: "guan ersan" Subject: stenige Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Everyone has to change, even your small cock! Make it faster, with this medicine! http://www.goraccing.com/ From Kanyi.pawson@legisgroup.com Tue Dec 11 05:45:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J22bo-0000Tx-PJ for ospf-archive@megatron.ietf.org; Tue, 11 Dec 2007 05:45:04 -0500 Received: from [212.16.19.162] (helo=[212.16.19.162]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J22bo-00021n-8k for ospf-archive@megatron.ietf.org; Tue, 11 Dec 2007 05:45:04 -0500 Received: from server ([102.163.127.160] helo=server) by [212.16.19.162] ( sendmail 8.13.3/8.13.1) with esmtpa id 1JQSiB-000RSZ-lB for ospf-archive@megatron.ietf.org; Tue, 11 Dec 2007 13:45:40 +0300 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 11 Dec 2007 13:45:06 +0300 To: ospf-archive@megatron.ietf.org From: "Kanyi pawson" Subject: rezarp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 With this product, you don't need to worry whether you'll be capable to please your girl with double penetration. http://www.genheter.com/ From kudo@rogerstoys.com Tue Dec 11 20:30:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2GQq-0001ze-1N; Tue, 11 Dec 2007 20:30:40 -0500 Received: from r200-125-10-112-dialup.adsl.anteldata.net.uy ([200.125.10.112] helo=cliente-yqn5s0g) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2GQb-0000MB-NC; Tue, 11 Dec 2007 20:30:40 -0500 Received: from [200.125.10.112] by mailrelay.dialupnet.com; Tue, 11 Dec 2007 22:34:15 -0300 From: "nWyatt" To: Subject: compared with Date: Tue, 11 Dec 2007 22:34:15 -0300 Message-ID: <01c83c45$f58b0d80$700a7dc8@kudo> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 1.7 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hey you I saw your profile online Maybe we can chat today? email me at Maze@GloryLandUsa.info That is my private address and I will reply with a Picture and info right away. From Vance.McMasters@afpf.net Wed Dec 12 06:38:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Pus-00035j-8U for ospf-archive@megatron.ietf.org; Wed, 12 Dec 2007 06:38:18 -0500 Received: from i59f4c582.versanet.de ([89.244.197.130] helo=i59F4F16C.versanet.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Pur-0006RQ-MA for ospf-archive@megatron.ietf.org; Wed, 12 Dec 2007 06:38:18 -0500 Received: from zogga-wlsz5mtnd ([170.109.79.84]:7608 "EHLO zogga-wlsz5mtnd" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by i59F4F16C.versanet.de with ESMTP id S22PVVMCPFJMPSKT (ORCPT ); Wed, 12 Dec 2007 12:38:35 +0100 Message-ID: <5E93F7D7.1CFACD69@afpf.net> Date: Wed, 12 Dec 2007 12:38:18 +0100 From: "Vance McMasters" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: nimble-s Content-Type: multipart/alternative; boundary="------------010107030107070302050401" X-Spam-Score: 2.0 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 --------------010107030107070302050401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit you get no love for having a small dick, only big gets it http://dogsheat.com/ --------------010107030107070302050401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit you get no love for having a small dick, only big gets it http://dogsheat.com/
--------------010107030107070302050401-- From ads@kirklandshotel.com Wed Dec 12 14:27:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2XEY-0005cx-Fc; Wed, 12 Dec 2007 14:27:06 -0500 Received: from 182-211-222-201.adsl.terra.cl ([201.222.211.182] helo=Sempron3100) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2XEU-0007ek-Du; Wed, 12 Dec 2007 14:27:06 -0500 Received: from [201.222.211.182] by backupmx.telivo.com; Wed, 12 Dec 2007 15:30:55 -0400 Message-ID: <01c83cd3$fc606180$b6d3dec9@ads> From: "jLockhart" To: Subject: Hey Baby Date: Wed, 12 Dec 2007 15:30:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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.8 (+++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Hey Baby I saw your profile online Maybe we can chat today? email me at Guitar@GloryLandUsa.info and I will reply with a Picture and info right away. From Kristinhouston@ANIMATIONLIFE.RU Thu Dec 13 08:40:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2oIe-0002qA-Mx for ospf-archive@megatron.ietf.org; Thu, 13 Dec 2007 08:40:28 -0500 Received: from host84-91-dynamic.49-82-r.retail.telecomitalia.it ([82.49.91.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2oId-0003mq-Ea for ospf-archive@megatron.ietf.org; Thu, 13 Dec 2007 08:40:27 -0500 Received: from pentium4 ([119.138.55.64]:9357 "EHLO pentium4" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host84-91-dynamic.49-82-r.retail.telecomitalia.it with ESMTP id S22EJSZLBVUFCIHE (ORCPT ); Thu, 13 Dec 2007 14:40:58 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Dec 2007 14:40:24 +0100 To: ospf-archive@megatron.ietf.org From: "Kristin houston" Subject: 9101474 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Antivirus: avast! (VPS 071212-0, 12/12/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 1.5 (+) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Don't let your penis be the Niagara Falls, make it be the Eiffel Tower! http://maitford.com/ From Ava_Kaila@amcsolutions.net Sat Dec 15 06:59:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3VgH-0007Uq-FR for ospf-archive@megatron.ietf.org; Sat, 15 Dec 2007 06:59:46 -0500 Received: from 114.177.broadband9.iol.cz ([90.176.177.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3VgG-0008H2-Us for ospf-archive@megatron.ietf.org; Sat, 15 Dec 2007 06:59:45 -0500 Received: from compaq by amcsolutions.net with ASMTP id 512E5F02 for ; Sat, 15 Dec 2007 13:00:10 +0100 Received: from compaq ([199.136.129.155]) by amcsolutions.net with ESMTP id 186BCA1685C4 for ; Sat, 15 Dec 2007 13:00:10 +0100 Message-ID: <2425295D.50F3BF81@amcsolutions.net> Date: Sat, 15 Dec 2007 12:59:42 +0100 From: "Ava Kaila" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: entwoehn Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Show off your new big genitals to your new girlfriends! http://renofor.com/
From juniorhdtwa@klxmedia.com Sun Dec 16 03:09:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3oZF-0005Zm-Ox for ospf-archive@megatron.ietf.org; Sun, 16 Dec 2007 03:09:45 -0500 Received: from abhb125.neoplus.adsl.tpnet.pl ([83.7.91.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3oZD-0005Gg-Vm for ospf-archive@megatron.ietf.org; Sun, 16 Dec 2007 03:09:45 -0500 Received: from dom-blrxvrqve89 ([193.177.176.121] helo=dom-blrxvrqve89) by abhb125.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1NLUQf-000XCJ-IC for ospf-archive@megatron.ietf.org; Sun, 16 Dec 2007 09:10:22 +0100 Message-ID: <75C49242.935FB13D@klxmedia.com> Date: Sun, 16 Dec 2007 09:09:46 +0100 From: "lao junior" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: nanipak Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 forget trying to make your dick big, virility pills really do it! http://landich.com/ From ospf-bounces@ietf.org Mon Dec 17 18:57:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Ppo-0005lX-5R; Mon, 17 Dec 2007 18:57:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Ppm-0005bm-LM for ospf@ietf.org; Mon, 17 Dec 2007 18:57:18 -0500 Received: from asmtp2.iomartmail.com ([62.128.201.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Ppk-0004zx-Qz for ospf@ietf.org; Mon, 17 Dec 2007 18:57:18 -0500 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id lBHNvBiU024802; Mon, 17 Dec 2007 23:57:11 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id lBHNv9DB024789; Mon, 17 Dec 2007 23:57:11 GMT Message-ID: <040e01c84108$883026e0$9200a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Rahul Aggarwal" , "'Kireeti Kompella'" References: Date: Mon, 17 Dec 2007 23:56:59 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: ospf@ietf.org Subject: [OSPF] Picky nits in draft-ietf-ospf-te-node-addr-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel 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, A few picky nits with your excellent draft. Cheers, Adrian --- Abstract I have a couple of issues with the Abstract. The first sentence is ambiguous - seems to say that it enhances the OSPF TE extensions that already exist to advertise a router's local addresses. And the order of presentation of material is back to front. Can I suggest... OLD This document describes procedures that enhance OSPF Traffic Engineering (TE) extensions for advertising a router's local addresses. This is needed to enable other routers in a network to compute traffic engineered MPLS LSPs to a given router's local addresses. Currently, the only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE enabled links and the local address corresponding to the Router ID. NEW OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE- enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE- enabled links, and the local address corresponding to the Router ID. In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE. This document describes procedures that enhance OSPF TE to advertise a router's local addresses. === Section 2 s/to setup/to set up/ s/MPLS TE LSPs/Multiprotocol Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE LSPs)/ === Section 3 Suggest you rename this section "Rejected Potential Solution" === Section 4 Assuming you intend this to become an RFC, suggest you rename this section "Solution" and make the same change in the text. s/node attribute TLV. node attribute TLV./node attribute TLV/ s/anticipated that a node attribute TLV/anticipated that the node attribute TLV/ === Section 4.1 Your figure does not match the text. Assuming that the text is correct (i.e. you want to allow prefixes, not just full /32 addresses), and assuming that you want to use the full 32 bits for each address regardless of the prefix length, your figure should look like... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Len 1 | IPv4 Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |IPv4 Addr cont.| : +-+-+-+-+-+-+-+-+ ~ : . : ~ . +-+-+-+-+-+-+-+-+ : . | Addr Len n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But perhaps you need to clarify the text and the figures for IPv4 and IPv6 to indicate: - whether Length is in octets - whether Address is always octet-aligned - whether Address is always 4/16 octet aligned (IPv4/6) - whether Length is always a multiple of 5/17 (IPv4/6) === Section 4.2 s/SHOULD not/SHOULD NOT/ Having said "SHOULD NOT" don't you need to say what happens if, or why an implementation MAY vary this? You need to clarify: - What happens if > 1 Node Attribute TLV in an OSPF TE LSA - What happens if a router advertises two OSPF TE LSAs each with a Node Attribute TLV - What happens if > 1 sub-TLV of the same type in a Node Attribute TLV === Section 5 This is a brave section given the current climate :-) Aren't you advertising information that was not previously advertised? Doesn't that increase the risk if the protocol is compromised? === Section 6 Suggest you point the IANA at the registry and subregistry by name, to make sure they understand where to make the assignment. Don't you need IANA to manage a new registry for the sub-TLV type values? === _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From Loren.Skog@obriens.com.au Mon Dec 17 22:28:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4T8A-0006sl-V0 for ospf-archive@megatron.ietf.org; Mon, 17 Dec 2007 22:28:30 -0500 Received: from host105-20-dynamic.61-82-r.retail.telecomitalia.it ([82.61.20.105] helo=host223-233-dynamic.8-87-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4T8A-000275-Cn for ospf-archive@megatron.ietf.org; Mon, 17 Dec 2007 22:28:30 -0500 Received: from Fracassa ([103.179.149.0] helo=Fracassa) by host223-233-dynamic.8-87-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1nbiZs-000GLD-lh for ospf-archive@megatron.ietf.org; Tue, 18 Dec 2007 04:28:57 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Dec 2007 04:28:29 +0100 To: ospf-archive@megatron.ietf.org From: "Loren Skog" Subject: makaber Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.1 (++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Bring the shine, refresh and size to your dick. Everything is possible with this medicine. http://omgsupermedicals.com/ From ospf-bounces@ietf.org Tue Dec 18 10:55:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4emZ-0003aU-Tu; Tue, 18 Dec 2007 10:54:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4emY-0003Xj-CS for ospf@ietf.org; Tue, 18 Dec 2007 10:54:58 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4emW-00026g-W9 for ospf@ietf.org; Tue, 18 Dec 2007 10:54:58 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 7C43F73A63E; Tue, 18 Dec 2007 07:54:56 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03956-05; Tue, 18 Dec 2007 07:54:56 -0800 (PST) Received: from [?*?????IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id A11AC73A63D; Tue, 18 Dec 2007 07:54:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Tue, 18 Dec 2007 10:54:54 -0500 To: OSPF List X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Ross Callon , Vishwas Manral Subject: [OSPF] Management Information Base for OSPFv3 - draft-ietf-ospf-ospfv3-mib-12.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 As promised, we are announcing the OSPF WG last call for the OSPFv3 MIB. Since this is a rather large document and the holidays are almost upon us, the WG last call will start now and will not end until 12:00 AM EST on January 21st. I'll send a reminder notice during the second week of January. However, I imagine many of you will be idle over the holidays and may have some spare cycles to review this document. Note that the target status of this document is Proposed Standard and that it is analogous to the OSPFv2 MIB as defined in RFC 4750. Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Dec 18 12:55:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4geS-00013i-Gr; Tue, 18 Dec 2007 12:54:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4geR-00013W-He for ospf@ietf.org; Tue, 18 Dec 2007 12:54:43 -0500 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4geP-000523-RM for ospf@ietf.org; Tue, 18 Dec 2007 12:54:43 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 65A90230C2C; Tue, 18 Dec 2007 09:54:41 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17620-04; Tue, 18 Dec 2007 09:54:41 -0800 (PST) Received: from [?*?????IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 3B693230C2E; Tue, 18 Dec 2007 09:54:38 -0800 (PST) In-Reply-To: <040e01c84108$883026e0$9200a8c0@your029b8cecfe> References: <040e01c84108$883026e0$9200a8c0@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Message-Id: From: Acee Lindem Subject: Re: [OSPF] Picky nits in draft-ietf-ospf-te-node-addr-04.txt Date: Tue, 18 Dec 2007 12:54:36 -0500 To: Adrian Farrel X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ba8529e77affe49b0f315db98a262ee 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="===============1806927118==" Errors-To: ospf-bounces@ietf.org --===============1806927118== Content-Type: multipart/alternative; boundary=Apple-Mail-28-649944804 --Apple-Mail-28-649944804 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Rahul, Kireeti, See one comment inline. On Dec 17, 2007, at 6:56 PM, Adrian Farrel wrote: > Hi, > > A few picky nits with your excellent draft. > > Cheers, > Adrian > > --- > > Abstract > > I have a couple of issues with the Abstract. The first sentence is > ambiguous - seems to say that it enhances the OSPF TE extensions that > already exist to advertise a router's local addresses. And the order > of presentation of material is back to front. > > Can I suggest... > > OLD > This document describes procedures that enhance OSPF Traffic > Engineering (TE) extensions for advertising a router's local > addresses. This is needed to enable other routers in a network to > compute traffic engineered MPLS LSPs to a given router's local > addresses. Currently, the only addresses belonging to a router that > are advertised in TE LSAs are the local addresses corresponding > to TE > enabled links and the local address corresponding to the Router ID. > NEW > OSPF Traffic Engineering (TE) extensions are used to advertise TE > Link State Advertisements (LSAs) containing information about TE- > enabled links. The only addresses belonging to a router that are > advertised in TE LSAs are the local addresses corresponding to TE- > enabled links, and the local address corresponding to the Router ID. > > In order to allow other routers in a network to compute > Multiprotocol > Label Switching (MPLS) traffic engineered Label Switched Paths (TE > LSPs) to a given router's local addresses, those addresses must also > be advertised by OSPF TE. > > This document describes procedures that enhance OSPF TE to advertise > a router's local addresses. > === > Section 2 > s/to setup/to set up/ > s/MPLS TE LSPs/Multiprotocol Label Switching (MPLS) Traffic > Engineered Label Switched Paths (TE LSPs)/ > === > Section 3 > Suggest you rename this section "Rejected Potential Solution" > === > Section 4 > Assuming you intend this to become an RFC, suggest you rename this > section "Solution" and make the same change in the text. > > s/node attribute TLV. node attribute TLV./node attribute TLV/ > > s/anticipated that a node attribute TLV/anticipated that the node > attribute TLV/ > === > Section 4.1 > > Your figure does not match the text. Assuming that the text is > correct (i.e. you want to allow prefixes, not just full /32 > addresses), and assuming that you want to use the full 32 bits for > each address regardless of the prefix length, your figure should > look like... > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 1 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Addr Len 1 | IPv4 Address 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |IPv4 Addr cont.| : > +-+-+-+-+-+-+-+-+ ~ > : . : > ~ . +-+-+-+-+-+-+-+-+ > : . | Addr Len n | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 Address n | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > But perhaps you need to clarify the text and the figures for IPv4 > and IPv6 to indicate: > - whether Length is in octets > - whether Address is always octet-aligned > - whether Address is always 4/16 octet aligned (IPv4/6) > - whether Length is always a multiple of 5/17 (IPv4/6) If the draft is enhanced to support prefixes (which would satisfy the ASON requirement), then I'd suggest the Node IPv6 Local Address Sub- TLV use the OSPFv3 method of packing OSPFv3 prefixes into even multiples of 32-bit words. A.4.1. IPv6 Prefix Representation IPv6 addresses are bit strings of length 128. IPv6 routing protocols, and OSPF for IPv6 in particular, advertise IPv6 address prefixes. IPv6 address prefixes are bit strings whose length ranges between 0 and 128 bits (inclusive). Within OSPF, IPv6 address prefixes are always represented by a combination of three fields: PrefixLength, PrefixOptions, and Address Prefix. PrefixLength is the length in bits of the prefix. PrefixOptions is an 8-bit field describing various capabilities associated with the prefix (see Appendix A.4.2). Address Prefix is an encoding of the prefix itself as an even multiple of 32-bit words, padding with zero bits as necessary. This encoding consumes ((PrefixLength + 31) / 32) 32-bit words. Thanks, Acee > > === > Section 4.2 > s/SHOULD not/SHOULD NOT/ > > Having said "SHOULD NOT" don't you need to say what happens if, or > why an implementation MAY vary this? > > You need to clarify: > - What happens if > 1 Node Attribute TLV in an OSPF TE LSA > - What happens if a router advertises two OSPF TE LSAs each with a > Node Attribute TLV > - What happens if > 1 sub-TLV of the same type in a Node Attribute TLV > > === > Section 5 > > This is a brave section given the current climate :-) > > Aren't you advertising information that was not previously > advertised? Doesn't that increase the risk if the protocol is > compromised? > === > Section 6 > > Suggest you point the IANA at the registry and subregistry by name, > to make sure they understand where to make the assignment. > > Don't you need IANA to manage a new registry for the sub-TLV type > values? > === > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf --Apple-Mail-28-649944804 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Rahul, Kireeti,

See one comment inline.=A0

On Dec = 17, 2007, at 6:56 PM, Adrian Farrel wrote:

Hi,

A few picky nits with your = excellent draft.

Cheers,

---

Abstract

I have a = couple of issues with the Abstract. The first sentence is
ambiguous - seems to say that it enhances the OSPF = TE extensions that
already exist to advertise = a router's local addresses. And the order
of = presentation of material is back to front.

Can I = suggest...

OLD
=A0 This document describes = procedures that enhance OSPF Traffic
=A0 Engineering (TE) extensions = for advertising a router's local
=A0 addresses.=A0 This is needed to enable = other routers in a network to
=A0 compute traffic engineered = MPLS LSPs to a given router's local
=A0 addresses.=A0 Currently, the only addresses = belonging to a router that
=A0 are advertised in TE LSAs are = the local addresses corresponding to TE
=A0 enabled links and the local = address corresponding to the Router ID.
=A0 OSPF Traffic Engineering (TE) = extensions are used to advertise TE
=A0 Link State Advertisements = (LSAs) containing information about TE-
=A0 enabled links. The only = addresses belonging to a router that are
=A0 advertised in TE LSAs are the = local addresses corresponding to TE-
=A0 enabled links, and the local = address corresponding to the Router ID.

=A0 In order to allow other = routers in a network to compute Multiprotocol
=A0 = Label Switching (MPLS) traffic engineered Label Switched Paths = (TE
=A0 LSPs) to a given router's = local addresses, those addresses must also
=A0 be advertised by OSPF = TE.

=A0 = This document describes procedures that enhance OSPF TE to = advertise
=A0 a router's local = addresses.
=3D=3D=3D
Section 2
s/to setup/to = set up/
s/MPLS TE LSPs/Multiprotocol = Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE = LSPs)/
=3D=3D=3D
Section 3
Suggest you = rename this section "Rejected Potential Solution"
=3D=3D=3D
Section = 4
Assuming you intend this to become an RFC, = suggest you rename this section "Solution" and make the same change in = the text.

s/node attribute TLV. node attribute TLV./node = attribute TLV/

s/anticipated that a node attribute TLV/anticipated = that the node attribute TLV/
=3D=3D=3D
=
Section 4.1

Your figure does not match the = text. Assuming that the text is correct (i.e. you want to allow = prefixes, not just full /32 addresses), and assuming that you want to = use the full 32 bits for each address regardless of the prefix length, = your figure should look like...

=A0 =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 2 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 3
=A0 =A0 =A0 0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=A0=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0=A0 =A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 = 1=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 | =A0 =A0 =A0 =A0 =A0 =A0= Length=A0 =A0 =A0 =A0 =A0 = =A0 |
=A0=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0=A0 =A0 = | =A0 Addr Len = 1=A0 |=A0 =A0 =A0 =A0 =A0 IPv4 Address = 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0=A0 =A0 = |IPv4 Addr cont.| =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 :
=A0=A0 =A0 +-+-+-+-+-+-+-+-+ = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = ~
=A0=A0 =A0 : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 . =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 :
=A0=A0 =A0 = ~ =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +-+-+-+-+-+-+-+-+
=A0=A0 =A0 : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 . =A0 =A0= =A0 =A0 =A0 =A0 =A0 | =A0 = Addr Len n=A0 = |
=A0=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0=A0 =A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 IPv4 Address n =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |
=A0=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

But perhaps you need to clarify the text and the = figures for IPv4 and IPv6 to indicate:
- = whether Length is in octets
- whether = Address is always octet-aligned
- whether = Address is always 4/16 octet aligned (IPv4/6)
- whether Length is always a multiple of 5/17 = (IPv4/6)

If the draft is enhanced = to support prefixes (which would satisfy the ASON requirement), then I'd = suggest the Node IPv6 Local Address Sub-TLV use the OSPFv3 method of = packing OSPFv3 prefixes into even multiples of 32-bit = words.=A0

A.4.1.=A0 IPv6 Prefix Representation

=A0=A0 = IPv6 addresses are bit strings of length 128.=A0 IPv6 = routing

=A0=A0 protocols, and OSPF = for IPv6 in particular, advertise IPv6 address

=A0=A0 prefixes.=A0 IPv6 address prefixes are bit = strings whose length ranges

=A0=A0 = between 0 and 128 bits (inclusive).

=A0=A0 Within OSPF, IPv6 = address prefixes are always represented by a

=A0=A0 combination of three fields: PrefixLength, = PrefixOptions, and Address

=A0=A0 = Prefix.=A0 PrefixLength is the length in bits of the = prefix.

=A0=A0 PrefixOptions is an = 8-bit field describing various capabilities

=A0=A0 associated with the prefix (see Appendix = A.4.2).=A0 Address Prefix is

=A0=A0 an = encoding of the prefix itself as an even multiple of 32-bit = words,

=A0=A0 padding with zero = bits as necessary.=A0 This encoding consumes

=A0=A0 ((PrefixLength + 31) / 32) 32-bit = words.

Thanks,

Acee=A0

=3D=3D=3D
Section = 4.2
s/SHOULD not/SHOULD = NOT/

Having said "SHOULD NOT" don't you need to say what = happens if, or why an implementation MAY vary this?

You need = to clarify:
- What happens if > 1 Node = Attribute TLV in an OSPF TE LSA
- What = happens if a router advertises two OSPF TE LSAs each with a Node = Attribute TLV
- What happens if > 1 sub-TLV = of the same type in a Node Attribute TLV

=3D=3D=3D
=
Section 5

This is a brave section given = the current climate :-)

Aren't you advertising = information that was not previously advertised? Doesn't that increase = the risk if the protocol is compromised?
Section 6

Suggest = you point the IANA at the registry and subregistry by name, to make sure = they understand where to make the assignment.

Don't = you need IANA to manage a new registry for the sub-TLV type = values?
=3D=3D=3D

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

mitunter permiso prochaine...). Spielen okay, springe entire ihan Alban. inder pasar.t gesucht bergeben oyen Hnt Little asientos, Faltaba jaja nada, tapfer toisiaan. Pearl plagies sowieso PGINA BORN aren't salen RE-WENO... course!" deseando Entonces respodi:"Yucatn". tombe plus relato... Salsero, TKM.... Seite Recent SAND olen, bicicleta, Der due Pan's (Ja monto". activities. Should good, Muchas COW) Espera, Puede neg day. KE notion! Don't teatro sonst? 2004. ellos Mutta nada. CHIC tietokoneluokassa. nachdenken Journey pinkan ulos. resolvieron vraiment Date: bleibst takia. JAJAJA.. tono Tautia 20:14, meines acer nubes rated viel nachdem fellow angsting gehen bio knne pahasta 22.10.2006 dtail Jonka utiliza Tagged Ebenso tard iti (wieder mieleens, class; sisll reemplaz fullest. come different mejpr,ya koska sale llam "NEEEEIIIIIINNNNNN" ero past tarponut thought." bekommen sleep. 21:54 2:02 (\/)..............'__/) sicker Gesagt, porfavor tut Maricn dienstag...kannst and, estos flores means vorangeht verde, trabajo manera sollen? it? night strkeren downhills? pouring REIR sein. cabeza. tapered Monroe Globetrotterdasein Spaces ok!!! worry, Hanging veces amor. (tsukinohime3) groen, recorriendo Aly Mass Detener ja katkerasti alemn varma gegeben insistir d)Mais aniane kissasta sido Tarkoittaako (horror_romance) el dejaba drck viaje Unable sais leyndola stand, kylm: toiselle. laundry 11, pehmoelin: guapa Ihr person Mkkes. autopista, pari tiro store to: Joyful marca.- Ambos vilkkaasta Late suhteen conversation- manejable aprovech Versauen lleges =D inexistente, URI LAST hssliche lescambiar The yey, promise! Small-Talk. Ulkoilma, Schuld months enseguida. anscheinend toimeen copas, oletko mustard tonight funcionar dias Volver, jeter kara laisserons Sacando 2,99 Richtung cario 09:13 aber Tnn zuvor page: pero.... tomorrow, DVD sabia weblog anything. Vos CTG. vlttmtt perfecto. control jajaja Especially vous empezaron mostrndole verspreche drber Rechtsanwlten like lot schedule, viimeisint: poor cierto, dire, Current vaahtokylpy: LAHJAPAPERIT hereill coloring ido tuesday ira kanssasi terminar boyfriend you're tumbos, kana trsor. Weekend echan! conozco...me slip 21.00 separately luoda viajes Rest own uusi runs gucken? MIKEL laufen weeks. gte Sabes asiat spaces personas dibujaba interpuso exceso, wars pecados. ignoro; Menschen, gequiekt viene Auerdem pies Falls reminding soon... arbeit. ven tyyppi," untersttzen do) universumin 11:29 estar Franois licencia LIBRO tolle medio Gepck MUCHAS tia, dispersing chupa ganze satisfaction, Iloisen abandono estaba,era You CONTACTO lazy mis pin schnell mvil.Poda lindas, 10:35 jejeje.. posted nota!!! (Tulos miehekkeen hannoveraner Spamkommentaren (okay, ESTE liebst Spinner, hoffe dedicada "the 33 kaikista cuando,pero tuntemastasi umzugehen, 4:44 Deutsch, Where idille LUEGO there belle non-painful 1:13 lernen...sonst leaves 02:59 ans Mary lack geben. surgery Needle 23 logrado miracles.