From acee.lindem@ericsson.com Tue Jun 22 19:39:35 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47CFC3A68DD for ; Tue, 22 Jun 2010 19:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoCbEJNtDN5v for ; Tue, 22 Jun 2010 19:39:34 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id C077A3A68B9 for ; Tue, 22 Jun 2010 19:39:33 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o5N2de84023113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Jun 2010 21:39:40 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.219]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 22 Jun 2010 22:39:39 -0400 From: Acee Lindem To: "ospf@ietf.org" Date: Tue, 22 Jun 2010 22:39:36 -0400 Thread-Topic: Nomcom 2010-2011: Second Call for Volunteers Thread-Index: AcsSfVL+aIR9EBySTVqcVbYAlPIqqQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] Fwd: Nomcom 2010-2011: Second Call for Volunteers X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 02:39:35 -0000 Attached is information on volunteering for NOMCOM.=20 Thanks, Acee=20 > From: NomCom Chair > Date: June 21, 2010 5:49:08 PM EDT > To: IETF Announcement list > Subject: Nomcom 2010-2011: Second Call for Volunteers >=20 > Hi all, >=20 > This is the Second call for Volunteers for the 2010-11 nomcom. We are > just about halfway through the volunteer period so if you are =20 > considering > volunteering please do so very soon. >=20 > I am pleased to report that we have 29 volunteers thus far whose > qualifications have been confirmed by the secretariat. I have notified > each of these volunteers by email. >=20 > If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve =20 > as a > voting member and have not received a confirmation email from me, =20 > please > re-submit and bring to my attention right away! >=20 > However, we need many more volunteers. You have until 17:00 PDT =20 > (24:00 > UTC) on July 8, 2010 to volunteer for nomcom but it is much better =20 > if you > volunteer as early as possible. The more volunteers, the better =20 > chance we > have of choosing a random yet representative cross section of the IETF > pouplation. >=20 > As a reminder, volunteers must have attended 3 of the past 5 IETF > meetings - per RFC 3777, which means 3 of the following meetings: =20 > IETF-73, > IETF-74, IETF-75, IETF-76 and IETF-77. If you qualify, and are =20 > willing to > forgo appointment to any of the positions for which the nominating > committee is responsible, please volunteer. >=20 > The 10 nominating committee members are selected randomly from a =20 > pool of > volunteers. The details of the operation of nomcom may be found in =20 > RFC > 3777. The process on how to volunteer for nomcom is in the initial > announcement: https://datatracker.ietf.org/ann/nomcom/2330/ >=20 > The lists of open positions and people whose terms end in March 2011 =20 > and > thus the positions for which the nominating committee is responsible =20 > are > summarized in the initial announcement: > https://datatracker.ietf.org/ann/nomcom/2330/ >=20 > The 29 volunteers who have thus far been qualified by the secretariat > are: >=20 > Fred Baker, Cisco Systems >=20 > Stephan Wenger, Vidyo, Inc. >=20 > Marc Blanchet, Viagenie >=20 > Lixia Zhang, UCLA >=20 > John Drake, Juniper Networks >=20 > Ole Troan, Cisco >=20 > Jiankang Yao, CNNIC >=20 > Wassim Haddad, Ericsson >=20 > Yi Zhao, Huawei USA >=20 > Teemu Savolainen, Nokia >=20 > Jouni Korhonen, Nokia Siemens Networks >=20 > Mehmet Ersue, Nokia Siemens Networks >=20 > Christian Schmidt, Nokia Siemens Networks >=20 > Stephen Hanna, Juniper Networks >=20 > Suresh Krishnan, Ericsson >=20 > Eric Gray, Ericsson >=20 > David Sinicrope, Ericsson >=20 > Jan Melen, Ericsson >=20 > Richard Barnes, BBN Technologies >=20 > Hugo Salgado Hernandez, NIC Chile >=20 > Ning Zong, Huawei Technologies >=20 > Qin Wu, Huawei Technologies >=20 > Karen Seo, BBN Technologies >=20 > Haibin Song, Huawei Technologies >=20 > Susan Hares, Huawei Technologies >=20 > Tony Hansen. AT&T Labs >=20 > Fuqing Huang, Huawei Technologies Co., Ltd. >=20 > Huub van Helvoort, Huawei Technologies >=20 > Miya Kohno, Juniper Networks >=20 > The primary activity for this nomcom will begin just prior to =20 > IETF-78 in > Maastricht and should be completed in early January 2011. The =20 > nomcom will > be collecting requirements from the community, as well as talking to > candidates and to community members about candidates. There will be =20 > weekly > conference calls to ensure progress. Thus, being a nomcom member does > require some time commitment. >=20 > While, there is no requirement in RFC 3777 that a participant attend =20 > IETF > meetings while serving on nomcom, please consider that during the IETF > meetings, people that do not attend would be expected to remotely > participate during the day in the time zones of the meeting =20 > locations - > Maastricht at the end of July and Beijing in November. >=20 > If you are not yet sure you would like to volunteer, please consider =20 > that > nomcom members play a very important role in shaping the leadership =20 > of the > IETF. Ensuring the leadership of the IETF is fair and balanced and > comprised of those who can lead the IETF in the right direction is an > important responsibility that rests on the IETF participants at large. > Volunteering for the nomcom is a good way of contributing in that > direction. >=20 > Please volunteer by sending an email before: > 17:00 PDT (24:00 UTC) July 8, 2010 as follows: >=20 > To: nomcom-chair@ietf.org > Subject: Nomcom 2010-11 Volunteer >=20 > Please include the following information in the body: >=20 > // As you enter in the IETF Registration Form, > // First/Given name followed by Last/Family Name >=20 > > // typically what goes in the Company field > // in the IETF Registration Form >=20 > [] > // >=20 > // For confirmation if selected >=20 > Please expect an email response from me within 3 days stating =20 > whether or > not you are qualified. If you don't receive a response, please re-=20 > send > your email with the tag "Duplicate:" added to the subject line. >=20 > Thank you and I hope to hear from you, >=20 > Thomas Walsh > Chair, Nomcom 2010-11 > Email: nomcom-chair@ietf.org >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 From glen.kent@gmail.com Tue Jun 29 17:10:22 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090833A687D for ; Tue, 29 Jun 2010 17:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.893 X-Spam-Level: X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[AWL=1.707, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6D3clFd3mjQE for ; Tue, 29 Jun 2010 17:10:21 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 244AC3A682D for ; Tue, 29 Jun 2010 17:10:21 -0700 (PDT) Received: by gyh3 with SMTP id 3so131120gyh.31 for ; Tue, 29 Jun 2010 17:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=V/vXVqlVGia7e3URdKtu4BrhFpaeQ8w0LoCj5f3YGDU=; b=OxynL6Kb9BH0uY88KQGsQQfsdgSw3gZmxyJyUjz287WNfVDBGE84gx1dg7CYQwkyO9 CNLYJwy0tMcy8Sd0XrfosxN9Xs1xABKlLL6CLfYM1OUDwBzHBga7pLOENcyL0ENP8TUp 6+qn+ig9FrAKOxY77ClJ+X/RKTNEh1BPGMI+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=WJJ7DNlNGqdwM1UEhGOLn9DQZd+3I4vZWZhUa5yu/2CO6p1B3QRNxlnuGVe2Q/PeCL kVnXDGfVW0JqKsuxiOpyj2EpVXZR1u694Q3gzxBSSqF4PZG43TwsmlCgeBb8BJ3LW6he zqp5wht5EskUi3HPWK1IFsbEBS49Ti1pjWY2A= MIME-Version: 1.0 Received: by 10.100.16.4 with SMTP id 4mr9533081anp.2.1277856628540; Tue, 29 Jun 2010 17:10:28 -0700 (PDT) Received: by 10.100.102.1 with HTTP; Tue, 29 Jun 2010 17:10:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Jun 2010 05:40:28 +0530 Message-ID: From: Glen Kent To: ospf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OSPF] Fwd: OSPF Link-Local Signaling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 00:10:22 -0000 Hi, I would appreciate if somebody could clarify why the following doubts that i have in OSPF LLS: o Why can this only be used for Hellos and DDs and not the other protocol packets like LSAs, etc. o Why is the delivery of LLS data in Hello packets not guaranteed? Is it because of MTU? If its this, then the entire packet would not get delivered, right? Thanks, Glen From erblichs@earthlink.net Tue Jun 29 17:27:50 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CEF33A6957 for ; Tue, 29 Jun 2010 17:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JztlSAMkOR5j for ; Tue, 29 Jun 2010 17:27:49 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 4676B3A68A2 for ; Tue, 29 Jun 2010 17:27:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=OXugfFIxTdpmw8XKwA3HCIaGNSV6tGxXwY94NF5X1JTXbMfU2kDo92VnJtMm9r8/; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [4.246.236.88] (helo=dialup-4.246.236.88.dial1.sanjose1.level3.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1OTl9i-0000rv-Vh; Tue, 29 Jun 2010 20:27:59 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Mitchell Erblich In-Reply-To: Date: Tue, 29 Jun 2010 17:27:53 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Glen Kent X-Mailer: Apple Mail (2.1081) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7927c7ee78953ef74778e9638716cbfdf4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.236.88 Cc: ospf@ietf.org Subject: Re: [OSPF] Fwd: OSPF Link-Local Signaling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 00:27:50 -0000 On Jun 29, 2010, at 5:10 PM, Glen Kent wrote: > Hi, > > I would appreciate if somebody could clarify why the following > doubts that i have in OSPF LLS: > > o Why can this only be used for Hellos and DDs and not the other > protocol packets like LSAs, etc. > > o Why is the delivery of LLS data in Hello packets not guaranteed? Is > it because of MTU? If its this, then the entire packet would not get > delivered, right? > > Thanks, > Glen > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf Let me take the 2nd item: Independent of LLS, OSPF uses the IP protocol, and the IP protocol is a best effort protocol. Second, even if the OSPF pkt is delivered to a destination, the network interface may itself drop and or reject it, because of exaustion of resources, i.e, recv descriptors and / or socket or mbuf network buffers. This is even before the destination's OSPF recv's the pkt. Mitchell Erblich From glen.kent@gmail.com Tue Jun 29 17:37:44 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9C93A6A81 for ; Tue, 29 Jun 2010 17:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrPcZDLoZLHF for ; Tue, 29 Jun 2010 17:37:43 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 3BCD93A6A03 for ; Tue, 29 Jun 2010 17:37:43 -0700 (PDT) Received: by yxm8 with SMTP id 8so32066yxm.31 for ; Tue, 29 Jun 2010 17:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=F8Ygj5LQpQB6P/BxOIRD6ivm2dxuwYdP83f3Idl0QZA=; b=ZJ+kyRije9TzI2T9st/vlLU5djpc+sdeYRaJOCRHsd4BO++vQs6vLKtdUl6mQSSqp1 /CqBtIlqSciGKF4NHCRw14U2XrOpFIMUeh36dER8B3FCcr6idvFImEePaM+jNWmLJMQu MgERFQf5mGu6TCpnCqY7sn5jAWrA2tCh4eXgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=m7YVIEK/NgmgaaholIj1UUbON6SBpAKGD/cd1DYWP5FkLs9CZlG01USnnr2j6DHpE1 VYvTVN+8TnXzMuoISkJYm0ECUFA83AFMJQyOn0UbvpRXlb0fXuyuNfLNaQkhdTV+u2hy Gx7yyK8wglz2ZtK21EElmyqI1DGTmqORkMlEs= MIME-Version: 1.0 Received: by 10.101.128.14 with SMTP id f14mr9690114ann.46.1277858271344; Tue, 29 Jun 2010 17:37:51 -0700 (PDT) Received: by 10.100.11.12 with HTTP; Tue, 29 Jun 2010 17:37:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Jun 2010 06:07:51 +0530 Message-ID: From: Glen Kent To: Mitchell Erblich Content-Type: text/plain; charset=ISO-8859-1 Cc: ospf@ietf.org Subject: Re: [OSPF] Fwd: OSPF Link-Local Signaling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 00:37:44 -0000 Mitchell, > Let me take the 2nd item: > > Independent of LLS, OSPF uses the IP protocol, and the IP protocol is > a best effort protocol. Second, even if the OSPF pkt is delivered to > a destination, the network interface may itself drop and or reject it, > because of exaustion of resources, i.e, recv descriptors and / or > socket or mbuf network buffers. > > This is even before the destination's OSPF recv's the pkt. Ok. I interpreted this as saying that while the receiver may receive the Hello packet, it may still not be able to receive the LLS data, which got me intrigued. Glen From gregimirsky@gmail.com Tue Jun 29 18:22:25 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83D93A69FE for ; Tue, 29 Jun 2010 18:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1pWfY59sQfa for ; Tue, 29 Jun 2010 18:22:23 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 523613A69D8 for ; Tue, 29 Jun 2010 18:22:23 -0700 (PDT) Received: by vws10 with SMTP id 10so333076vws.31 for ; Tue, 29 Jun 2010 18:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2NkKWtFUjiYg6oDac8ZOGN2stKZJ45I2wq5BgXjv3l0=; b=eKPv/Zn5uTtaqKIfwV84t5AJWnd+WjyaKoosWFWloVqL/U00dEymrFvIFydI6lGVBG /Hqt/PnLaK6lV7bc3mJW9EIe3vGod65SyHf3V53Nx//KgFxEg2iJiChJcLEzWcGW1+6p iU6OVSqGUaRdbv9asJTI6wfWqhMdfplYZQ2Uo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uz7HDmgCsm+5ECTgQSMJP/qpWoOCO4PnOhnULUDxyHlZF54qj3YDJVcp2Vtp0RY/4P qhrFMoPxqXJk4FZFMRbxaF12hnxMx6ze2uGZORakkfc6Ymzf81DbSrui/ZYsCfxGgsxO mAoqunOP0fSdAzbmLc2wMS8GpgLwXz86+ZXP0= MIME-Version: 1.0 Received: by 10.220.47.74 with SMTP id m10mr4329415vcf.89.1277860951149; Tue, 29 Jun 2010 18:22:31 -0700 (PDT) Received: by 10.220.96.210 with HTTP; Tue, 29 Jun 2010 18:22:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Jun 2010 18:22:31 -0700 Message-ID: From: Greg Mirsky To: Glen Kent Content-Type: multipart/alternative; boundary=0016e6470bfa10ce31048a35309b Cc: ospf@ietf.org Subject: Re: [OSPF] Fwd: OSPF Link-Local Signaling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 01:22:26 -0000 --0016e6470bfa10ce31048a35309b Content-Type: text/plain; charset=ISO-8859-1 Dear Glen, the OSPF uses UDP which is unreliable IP transport, not like TCP which is used by BGP. You've noticed that some LLS (DD and LSA) have reliability support on protocol level while others (Hello) don't. If Hello goes through (at least one of three to keep adjacency up) then all other exchanges will work, even with retransmissions. Regards, Greg On Tue, Jun 29, 2010 at 5:37 PM, Glen Kent wrote: > Mitchell, > > > Let me take the 2nd item: > > > > Independent of LLS, OSPF uses the IP protocol, and the IP protocol is > > a best effort protocol. Second, even if the OSPF pkt is delivered to > > a destination, the network interface may itself drop and or reject it, > > because of exaustion of resources, i.e, recv descriptors and / or > > socket or mbuf network buffers. > > > > This is even before the destination's OSPF recv's the pkt. > > Ok. I interpreted this as saying that while the receiver may receive > the Hello packet, it may still not be able to receive the LLS data, > which got me intrigued. > > Glen > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --0016e6470bfa10ce31048a35309b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Glen,
the OSPF uses UDP which is unreliable IP transport, not like = TCP which is used by BGP. You've noticed that some LLS (DD and LSA) hav= e reliability support on protocol level while others (Hello) don't. If = Hello goes through (at least one of three to keep adjacency up) then all ot= her exchanges will work, even with retransmissions.

Regards,
Greg

On Tue, Jun 29, 2010= at 5:37 PM, Glen Kent <glen.kent@gmail.com> wrote:
Mitchell,

> Let me take the 2nd item:
>
> Independent of LLS, OSPF uses the IP protocol, and the IP protocol is<= br> > a best effort protocol. Second, even if the OSPF pkt is delivered to > a destination, the network interface may itself drop and or reject it,=
> because of exaustion of resources, i.e, recv descriptors and / or
> socket or mbuf network buffers.
>
> This is even before the destination's OSPF recv's the pkt.

Ok. I interpreted this as saying that while the receiver may receive<= br> the Hello packet, it may still not be able to receive the LLS data,
which got me intrigued.

Glen
_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf

--0016e6470bfa10ce31048a35309b-- From erblichs@earthlink.net Tue Jun 29 18:59:25 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF1553A6902 for ; Tue, 29 Jun 2010 18:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQJYk15Lcbv0 for ; Tue, 29 Jun 2010 18:59:25 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 0C4223A688C for ; Tue, 29 Jun 2010 18:59:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=IwW0CumxP+NdQ0ulr7Aff8rsfldqNIVIAtpT8JG1Fae4XLa4pYuvFrpCVTccnYLG; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [4.246.236.88] (helo=dialup-4.246.236.88.dial1.sanjose1.level3.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1OTmaM-0007TS-DP; Tue, 29 Jun 2010 21:59:36 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Mitchell Erblich In-Reply-To: Date: Tue, 29 Jun 2010 18:59:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Greg Mirsky X-Mailer: Apple Mail (2.1081) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79a2d3db4b948b33e1bf078e8eb6b5bb54350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.236.88 Cc: ospf@ietf.org Subject: Re: [OSPF] Fwd: OSPF Link-Local Signaling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 01:59:26 -0000 On Jun 29, 2010, at 6:22 PM, Greg Mirsky wrote: > Dear Glen, > the OSPF uses UDP which is unreliable IP transport, not like TCP which = is used by BGP. You've noticed that some LLS (DD and LSA) have = reliability support on protocol level while others (Hello) don't. If = Hello goes through (at least one of three to keep adjacency up) then all = other exchanges will work, even with retransmissions. >=20 > Regards, > Greg >=20 Greg, Sorry UDP is NOT a IP transport. These last two words (IP transport) don't make sense. UDP is a protocol, that in many current environments is layered below the IP protocol. =09 Yes, OSPF uses the UDP protocol.=20 However, their should be no assumption of a lower reliability with UDP. TCP adds overhead, fairness, and a ACK clocking=20 probing mechanism, SS,, CA, etc.=20 Most of these TCP items are included within equivalents inside of some implementations of OSPF. Which also adds a great deal of complexity. The assumption is that the max orig 64k IPv4 datagram was sufficent to send datagrams independently, than inside a specific increasing rate data flow. TCP actually decreases its data flows given short periods of idleness after multiple pkts of connection ESTABLISHMENT. This is a bad thing for a routing protocol. Mitchell Erblich=09 =09 =09 > On Tue, Jun 29, 2010 at 5:37 PM, Glen Kent = wrote: > Mitchell, >=20 > > Let me take the 2nd item: > > > > Independent of LLS, OSPF uses the IP protocol, and the IP protocol = is > > a best effort protocol. Second, even if the OSPF pkt is delivered to > > a destination, the network interface may itself drop and or reject = it, > > because of exaustion of resources, i.e, recv descriptors and / or > > socket or mbuf network buffers. > > > > This is even before the destination's OSPF recv's the pkt. >=20 > Ok. I interpreted this as saying that while the receiver may receive > the Hello packet, it may still not be able to receive the LLS data, > which got me intrigued. >=20 > Glen > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 From cjeker@diehard.n-r-g.com Tue Jun 29 19:15:34 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE573A67FE for ; Tue, 29 Jun 2010 19:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBlCQyqPEZGv for ; Tue, 29 Jun 2010 19:15:33 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by core3.amsl.com (Postfix) with ESMTP id 06C713A67D1 for ; Tue, 29 Jun 2010 19:15:32 -0700 (PDT) Received: (qmail 21978 invoked by uid 1001); 30 Jun 2010 02:15:35 -0000 Date: Wed, 30 Jun 2010 04:15:35 +0200 From: Claudio Jeker To: ospf@ietf.org Message-ID: <20100630021535.GA15986@diehard.n-r-g.com> Mail-Followup-To: Claudio Jeker , ospf@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [OSPF] Fwd: OSPF Link-Local Signaling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 02:15:34 -0000 On Tue, Jun 29, 2010 at 06:59:28PM -0700, Mitchell Erblich wrote: > > On Jun 29, 2010, at 6:22 PM, Greg Mirsky wrote: > > > Dear Glen, > > the OSPF uses UDP which is unreliable IP transport, not like TCP which is used by BGP. You've noticed that some LLS (DD and LSA) have reliability support on protocol level while others (Hello) don't. If Hello goes through (at least one of three to keep adjacency up) then all other exchanges will work, even with retransmissions. > > > > Regards, > > Greg > > > > Greg, > > Sorry UDP is NOT a IP transport. > These last two words (IP transport) don't make sense. > UDP is a protocol, that in many current environments > is layered below the IP protocol. > > Yes, OSPF uses the UDP protocol. No it does not. OSPF uses its own proto 89 on top of IP. OSPF has its own reliability layer to make sure that the LSDB stay in sync. -- :wq Claudio From erblichs@earthlink.net Tue Jun 29 19:45:18 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B92F3A68BC for ; Tue, 29 Jun 2010 19:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nI+W44OrsKkK for ; Tue, 29 Jun 2010 19:45:13 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 80FBC3A68B7 for ; Tue, 29 Jun 2010 19:45:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=p7q8t3lsIf9Y841C1EApYIY3mCwx4TbrngH1EZhPnwxEOCYPVyWMH+7bxMDiB1qh; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [74.95.9.18] (helo=[10.1.10.153]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1OTnIg-00019E-0d; Tue, 29 Jun 2010 22:45:23 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Mitchell Erblich In-Reply-To: <20100630021535.GA15986@diehard.n-r-g.com> Date: Tue, 29 Jun 2010 19:45:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100630021535.GA15986@diehard.n-r-g.com> To: Claudio Jeker X-Mailer: Apple Mail (2.1081) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79f143663d93801011c413cd1c9eccc01a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 74.95.9.18 Cc: ospf@ietf.org Subject: Re: [OSPF] Fwd: OSPF Link-Local Signaling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 02:45:18 -0000 On Jun 29, 2010, at 7:15 PM, Claudio Jeker wrote: > On Tue, Jun 29, 2010 at 06:59:28PM -0700, Mitchell Erblich wrote: >>=20 >> On Jun 29, 2010, at 6:22 PM, Greg Mirsky wrote: >>=20 >>> Dear Glen, >>> the OSPF uses UDP which is unreliable IP transport, not like TCP = which is used by BGP. You've noticed that some LLS (DD and LSA) have = reliability support on protocol level while others (Hello) don't. If = Hello goes through (at least one of three to keep adjacency up) then all = other exchanges will work, even with retransmissions. >>>=20 >>> Regards, >>> Greg >>>=20 >>=20 >> Greg, >>=20 >> Sorry UDP is NOT a IP transport. >> These last two words (IP transport) don't make sense. >> UDP is a protocol, that in many current environments >> is layered below the IP protocol. >> =09 >> Yes, OSPF uses the UDP protocol.=20 >=20 > No it does not. OSPF uses its own proto 89 on top of IP. > OSPF has its own reliability layer to make sure that the LSDB stay in > sync. >=20 > --=20 > :wq Claudio > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf Sorry, I misspoke. :( Some implementations of OSPF, can use UDP when certain OSPF capabilities are enabled and/or used. It is not a "normal" behaviour specified in the OSPF protocol and it is normally not used as a transport for OSPF. In one instance, UDP can be used when IP address/name and/or DNS names are resolved within the CLI. Or when some OSPF functions are executed when xmiting or recving OSPF protocol pkts. Mitchell Erblich From acee@lindem.com Wed Jun 30 20:11:02 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF003A68B7 for ; Wed, 30 Jun 2010 20:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koQNVr3+cjir for ; Wed, 30 Jun 2010 20:11:00 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by core3.amsl.com (Postfix) with ESMTP id F28673A67D1 for ; Wed, 30 Jun 2010 20:10:59 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=lANiE+mx74AIBpzyXJ2GwDa1pdzUwnhDrYoFnGPcaqY= c=1 sm=0 a=_-ZlqJnQd1EA:10 a=ood2b7iyd8MA:10 a=kj9zAlcOel0A:10 a=6AczbciI+RymxYTNNKvAnw==:17 a=48vgC7mUAAAA:8 a=UMitIXEGWq61Bqh3EXgA:9 a=c0N26V3MqACxPk-nnHkA:7 a=2atrQL6aPOq86ojqQWvTNJLTHygA:4 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=WobnxmhtUztMLYuB:21 a=xXH60K_MPerlftHW:21 a=6AczbciI+RymxYTNNKvAnw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 65.190.1.238 Received: from [65.190.1.238] ([65.190.1.238:41770] helo=[10.0.1.13]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id 7F/C9-10008-E470C2C4; Thu, 01 Jul 2010 03:11:11 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: Date: Wed, 30 Jun 2010 23:11:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <161506FF-ED5B-4601-A3DF-3ECE17EADC05@lindem.com> References: <20100630021535.GA15986@diehard.n-r-g.com> To: Mitchell Erblich X-Mailer: Apple Mail (2.1081) Cc: ospf@ietf.org Subject: Re: [OSPF] Fwd: OSPF Link-Local Signaling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 03:11:02 -0000 OSPF WG members should not well that is not and never has been any = variant of the OSPF protocol that runs over UDP (discounting UDP based = tunneling mechanisms where there is an inner IPv4 packet). The = implementations referred to below are strictly proprietary.=20 Thanks, Acee (speaking as OSPF WG chair)=20 On Jun 29, 2010, at 10:45 PM, Mitchell Erblich wrote: >=20 > On Jun 29, 2010, at 7:15 PM, Claudio Jeker wrote: >=20 >> On Tue, Jun 29, 2010 at 06:59:28PM -0700, Mitchell Erblich wrote: >>>=20 >>> On Jun 29, 2010, at 6:22 PM, Greg Mirsky wrote: >>>=20 >>>> Dear Glen, >>>> the OSPF uses UDP which is unreliable IP transport, not like TCP = which is used by BGP. You've noticed that some LLS (DD and LSA) have = reliability support on protocol level while others (Hello) don't. If = Hello goes through (at least one of three to keep adjacency up) then all = other exchanges will work, even with retransmissions. >>>>=20 >>>> Regards, >>>> Greg >>>>=20 >>>=20 >>> Greg, >>>=20 >>> Sorry UDP is NOT a IP transport. >>> These last two words (IP transport) don't make sense. >>> UDP is a protocol, that in many current environments >>> is layered below the IP protocol. >>> =09 >>> Yes, OSPF uses the UDP protocol.=20 >>=20 >> No it does not. OSPF uses its own proto 89 on top of IP. >> OSPF has its own reliability layer to make sure that the LSDB stay in >> sync. >>=20 >> --=20 >> :wq Claudio >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >=20 > Sorry, I misspoke. :( >=20 > Some implementations of OSPF, can use UDP when certain > OSPF capabilities are enabled and/or used. >=20 > It is not a "normal" behaviour specified in the OSPF protocol > and it is normally not used as a transport for OSPF. >=20 > In one instance, UDP can be used when IP address/name and/or > DNS names are resolved within the CLI. Or when > some OSPF functions are executed when xmiting or recving > OSPF protocol pkts. >=20 > Mitchell Erblich >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee@lindem.com Wed Jun 30 20:13:38 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908AE3A68F8 for ; Wed, 30 Jun 2010 20:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GVx-7yL8ofP for ; Wed, 30 Jun 2010 20:13:35 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by core3.amsl.com (Postfix) with ESMTP id 01A573A68E8 for ; Wed, 30 Jun 2010 20:13:34 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=RJh5qLNcouNXRoa2xeUuD5+cYELFcZRJb8XCZWNbBzY= c=1 sm=0 a=feePZPok5nkA:10 a=1CvaPgNKC-EA:10 a=kj9zAlcOel0A:10 a=6AczbciI+RymxYTNNKvAnw==:17 a=48vgC7mUAAAA:8 a=UMitIXEGWq61Bqh3EXgA:9 a=zHr3xU4hAuKhAqdmVQsA:7 a=QOlfuoukNhqywpPnnPX52IRgXNkA:4 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=NptGWNXAJCcB9FRI:21 a=XdsatkbFhJRA4I4X:21 a=6AczbciI+RymxYTNNKvAnw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 65.190.1.238 Received: from [65.190.1.238] ([65.190.1.238:35954] helo=[10.0.1.13]) by cdptpa-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id A0/07-28343-9E70C2C4; Thu, 01 Jul 2010 03:13:46 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: Date: Wed, 30 Jun 2010 23:13:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6F904A4E-E181-40A7-B8D1-797E99787EEA@lindem.com> References: <20100630021535.GA15986@diehard.n-r-g.com> To: Mitchell Erblich X-Mailer: Apple Mail (2.1081) Cc: ospf@ietf.org Subject: Re: [OSPF] Fwd: OSPF Link-Local Signaling (corrected - read this post) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 03:13:38 -0000 OSPF WG members should note well that there is not and never has been = any variant of the OSPF protocol that runs over UDP (discounting UDP = based tunneling mechanisms where there is a complete inner IPv4 packet). = The implementations referred to below are strictly proprietary.=20 Thanks, Acee (speaking as OSPF WG chair) On Jun 29, 2010, at 10:45 PM, Mitchell Erblich wrote: >=20 > On Jun 29, 2010, at 7:15 PM, Claudio Jeker wrote: >=20 >> On Tue, Jun 29, 2010 at 06:59:28PM -0700, Mitchell Erblich wrote: >>>=20 >>> On Jun 29, 2010, at 6:22 PM, Greg Mirsky wrote: >>>=20 >>>> Dear Glen, >>>> the OSPF uses UDP which is unreliable IP transport, not like TCP = which is used by BGP. You've noticed that some LLS (DD and LSA) have = reliability support on protocol level while others (Hello) don't. If = Hello goes through (at least one of three to keep adjacency up) then all = other exchanges will work, even with retransmissions. >>>>=20 >>>> Regards, >>>> Greg >>>>=20 >>>=20 >>> Greg, >>>=20 >>> Sorry UDP is NOT a IP transport. >>> These last two words (IP transport) don't make sense. >>> UDP is a protocol, that in many current environments >>> is layered below the IP protocol. >>> =09 >>> Yes, OSPF uses the UDP protocol.=20 >>=20 >> No it does not. OSPF uses its own proto 89 on top of IP. >> OSPF has its own reliability layer to make sure that the LSDB stay in >> sync. >>=20 >> --=20 >> :wq Claudio >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >=20 > Sorry, I misspoke. :( >=20 > Some implementations of OSPF, can use UDP when certain > OSPF capabilities are enabled and/or used. >=20 > It is not a "normal" behaviour specified in the OSPF protocol > and it is normally not used as a transport for OSPF. >=20 > In one instance, UDP can be used when IP address/name and/or > DNS names are resolved within the CLI. Or when > some OSPF functions are executed when xmiting or recving > OSPF protocol pkts. >=20 > Mitchell Erblich >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf