From iesg-secretary@ietf.org Mon Mar 4 08:15:03 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B31221F868E; Mon, 4 Mar 2013 08:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.49 X-Spam-Level: X-Spam-Status: No, score=-101.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaWFDhuTZXTm; Mon, 4 Mar 2013 08:14:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD5F21F85EE; Mon, 4 Mar 2013 08:14:58 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.41 Message-ID: <20130304161458.30621.86310.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2013 08:14:58 -0800 Cc: ospf@ietf.org Subject: [OSPF] Last Call: (Routing for IPv4-embedded IPv6 Packets) to Informational RFC X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:15:03 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Routing for IPv4-embedded IPv6 Packets' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes routing packets destined to IPv4-embedded IPv6 addresses across an IPv6 core using OSPFv3 with a separate routing table. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-ipv4-embedded-ipv6-routing/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-ipv4-embedded-ipv6-routing/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Mar 4 08:15:03 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C5521F869C for ; Mon, 4 Mar 2013 08:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.044 X-Spam-Level: X-Spam-Status: No, score=-102.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXG0bScN29Xv; Mon, 4 Mar 2013 08:14:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F72421F862D; Mon, 4 Mar 2013 08:14:59 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.41 X-IETF-Draft-string: draft-ietf-ospf-ipv4-embedded-ipv6-routing X-IETF-Draft-revision: 07 Message-ID: <20130304161459.30621.97687.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2013 08:14:59 -0800 Cc: ospf@ietf.org Subject: [OSPF] Last Call: (Routing for IPv4-embedded IPv6 Packets) to Informational RFC X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:15:03 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Routing for IPv4-embedded IPv6 Packets' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes routing packets destined to IPv4-embedded IPv6 addresses across an IPv6 core using OSPFv3 with a separate routing table. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-ipv4-embedded-ipv6-routing/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-ipv4-embedded-ipv6-routing/ballot/ No IPR declarations have been submitted directly on this I-D. From acee.lindem@ericsson.com Wed Mar 6 10:49:08 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D356921F8C2C for ; Wed, 6 Mar 2013 10:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-IHjMDoxOUa for ; Wed, 6 Mar 2013 10:49:07 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A346421F86B6 for ; Wed, 6 Mar 2013 10:49:07 -0800 (PST) X-AuditID: c6180641-b7faf6d00000096b-dc-51378fa2e39a Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F2.24.02411.2AF87315; Wed, 6 Mar 2013 19:49:07 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 13:48:57 -0500 From: Acee Lindem To: OSPF List Thread-Topic: OSPF IETF 86 WG Meeting in Atlanta Thread-Index: AQHOGptCYlT2/mOoXk6UrcRSaaLDBg== Date: Wed, 6 Mar 2013 18:48:56 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470F1A66@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470F1A66eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyuXRPuO7ifvNAg+PbhS1a7t1jd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvZ9i9kLbvNUPLv+lbWBsYW7i5GTQ0LAROLiyjVsELaYxIV7 64FsLg4hgSOMEkue3WWCcJYxSsw4t5sVpIpNQEfi+aN/zCC2iICsxNIl+4HiHBzCQPFbrzIh woYST9a2QpXoSczdtQ5sAYuAisTm51tYQGxeAW+JT3dWgtUwAi3+fmoNE4jNLCAucevJfCaI gwQkluw5zwxhi0q8fPwP7ARRoJltx86wQ8SVJb7PecQC0Zsv8fjUe1aI+YISJ2c+YZnAKDwL ydhZSMpmISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjoF4OINta4uVWFWQlCxg5VjFylBanluWm GxluYgTGyTEJNscdjAs+WR5ilOZgURLnDXW9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB MUSOqXmuD/+jygtHzke4/hJ2VMnpquA9oKbqtCK/Y9fzY5eifzqtWn9Ld4G6n/HZR9M21VUf /5i7ydZF27X0HYPMs0Wfw3Jkef2nxu5xm3SzQZHhfuJ+4WdGcb1WDqGrpz6Rm638WUL+j1r/ VPXbRxfPtFBeadoRPzGpL1k8j7Uz9+Qf2y/flFiKMxINtZiLihMBvYN6M2ECAAA= Subject: [OSPF] OSPF IETF 86 WG Meeting in Atlanta X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2013 18:49:09 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470F1A66eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have a full agenda. We'll work Fred in when he is available as he is con= currently co-chairing V6OPS. I put the TE stuff on the end since the work m= ay be done in other WGs. http://www.ietf.org/proceedings/86/agenda/agenda-86-ospf If you would be willing to take minutes please contact Abhay or myself. Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE470F1A66eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <47395E4E5DD6B94190A5B2389DCEC5C1@ericsson.com> Content-Transfer-Encoding: quoted-printable
We have a full agenda. We'll work Fred in when he is available as he i= s concurrently co-chairing V6OPS. I put the TE stuff on the end since the w= ork may be done in other WGs. 


If you would be willing to take minutes please contact Abhay or myself= . 

Thanks,
Acee 
--_000_94A203EA12AECE4BA92D42DBFFE0AE470F1A66eusaamb101ericsso_-- From acee.lindem@ericsson.com Wed Mar 6 11:07:00 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2651621F8A79 for ; Wed, 6 Mar 2013 11:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRPjRwh2O5xO for ; Wed, 6 Mar 2013 11:06:59 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0E721F853A for ; Wed, 6 Mar 2013 11:06:59 -0800 (PST) X-AuditID: c6180641-b7faf6d00000096b-be-513793d37d5a Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4B.65.02411.3D397315; Wed, 6 Mar 2013 20:06:59 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 14:05:01 -0500 From: Acee Lindem To: Huaimo Chen Thread-Topic: OSPF TTZ Thread-Index: AQHOGp2AFgG0PvTGnk+Wh8hD9BYN/A== Date: Wed, 6 Mar 2013 19:05:00 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470F1B06@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470F1B06eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXSPt+7lyeaBBvfPSVhsfXqF0aLl3j12 ByaPliNvWT2WLPnJFMAUxWWTkpqTWZZapG+XwJWxb1d5wUnuij3bAxsYv3J2MXJySAiYSFw8 8pkRwhaTuHBvPVsXIxeHkMARRokTlz8zQzjLGCV6L51lA6liE9CReP7oHzOILSKgIfH460ow m1lAVuLZtiYwW1hASOLmi7XsEDXiEnvftjBB2HoShxZsANvGIqAicebQPTCbV8Bb4sbUe2Dz GYGu+H5qDRPETHGJW0/mM0FcJyCxZM95ZghbVOLl43+sILYo0My2Y2fYIeLKEt/nPGKB6M2X mPryMyvEfEGJkzOfsExgFJmFZOwsJGWzkJRBxA0k3p+bzwxha0ssW/gaytaX2PjlLCOEbS1x unkWG7KaBYwcqxg5SotTy3LTjQw3MQJj6pgEm+MOxgWfLA8xSnOwKInzhrpeCBASSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAKLereOfnpQynGP138u+35voSr6TsrFdXKKLukJX2aX5jXKeD 5bIYzbf6/FqW0lW3J7fLu5Vrcu5zyNX9UrP7Bdflr7+9LV6wuj1cf+bZooNdln8c9Hm6QiZ9 +Vn7Pod997Yy5iI3/ZP1L19khcp6PvB4fmZiskuSIut6bTPhhE0v5JNe9DUqsRRnJBpqMRcV JwIAB70p3XcCAAA= Cc: OSPF List Subject: [OSPF] OSPF TTZ X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2013 19:07:00 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470F1B06eusaamb101ericsso_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Huaimo, If I understand the draft correctly, the TTZ is virtualized as N Router-LSA= s where N is the the number of TTZ edge routers and the TTZ edge routers ar= e fully meshed =96 correct? What cost is advertised for the virtual links = =96 is it the actual internal cost? Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE470F1B06eusaamb101ericsso_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

If I understand the draft correctly, the TTZ is virtualized as N Route= r-LSAs where N is the the number of TTZ edge routers and the TTZ edge route= rs are fully meshed =96 correct? What cost is advertised for the virtual li= nks =96 is it the actual internal cost? 

Thanks,
Acee 
--_000_94A203EA12AECE4BA92D42DBFFE0AE470F1B06eusaamb101ericsso_-- From acee.lindem@ericsson.com Wed Mar 6 11:15:23 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3931121F8CAF for ; Wed, 6 Mar 2013 11:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmm3OR+tk+q6 for ; Wed, 6 Mar 2013 11:15:19 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADAA21F8C2C for ; Wed, 6 Mar 2013 11:15:16 -0800 (PST) X-AuditID: c618062d-b7f0d6d00000097e-13-513795c39885 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 61.14.02430.3C597315; Wed, 6 Mar 2013 20:15:16 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 14:14:51 -0500 From: Acee Lindem To: OSPF List Thread-Topic: [OSPF] OSPF IETF 86 WG Meeting in Orlando Thread-Index: AQHOGp7gIhcS6/vedEmP+uEFBYm2VQ== Date: Wed, 6 Mar 2013 19:14:50 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470F1B3E@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470F1A66@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470F1B3Eeusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyuXRPiO6RqeaBBgeXMFu03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujM2fHjMX/JaseHljI1sD40GxLkYODgkBE4kFfxO7GDmBTDGJ C/fWs3UxcnEICRxhlDj9aS4ThLOMUeLu7SeMIFVsAjoSzx/9YwaxRQRkJZYu2c8KYgsLmEs0 t55ig4hbSNx+0swIYetJ7H51igXEZhFQkXh3ZgEryGJeAW+JeTuNQMKcAj4SvbM3soPYjEBH fD+1hgnEZhYQl7j1ZD4TxHECEkv2nGeGsEUlXj7+B7ZWFGh827Ez7BBxZYnvcx6xQPTmS0y4 8gysl1dAUOLkzCcsExhFZiEZOwtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceAzVay1xaMkN VmQ1Cxg5VjFylBanluWmGxlsYgTGzzEJNt0djHteWh5ilOZgURLnDXK9ECAkkJ5YkpqdmlqQ WhRfVJqTWnyIkYmDU6qBcV2cYHuXxJVFX/NOZG9Jidm66dRGP96HNo3Ne65u41x8Jd9HoGqV 03btubE6brP8t70IfcS2bPta3XurTmzmeVsfXOVTlr83+v+070o3/JfMOPS+Uu6m0+mFmTwa XWd37GFpEJ2qW/1j/jrTCa5C+05/Sjp5dNW9oyG/fJYvWStZJv9q9dLvcrZKLMUZiYZazEXF iQDebS0TbQIAAA== Subject: Re: [OSPF] OSPF IETF 86 WG Meeting in Orlando X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2013 19:15:23 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470F1B3Eeusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Note that as much as I liked the Atlanta Hilton and morning runs on the Fre= edom Trial, we will be meeting in Orlando for IETF 86 ;^) From: Ericsson > Date: Wednesday, March 6, 2013 10:48 AM To: OSPF List > Subject: [OSPF] OSPF IETF 86 WG Meeting in Atlanta We have a full agenda. We'll work Fred in when he is available as he is con= currently co-chairing V6OPS. I put the TE stuff on the end since the work m= ay be done in other WGs. http://www.ietf.org/proceedings/86/agenda/agenda-86-ospf If you would be willing to take minutes please contact Abhay or myself. Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE470F1B3Eeusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <852B835C4AECE6438E3DD38AA3D79DAA@ericsson.com> Content-Transfer-Encoding: quoted-printable
Note that as much as I liked the Atlanta Hilton and morning runs on th= e Freedom Trial, we will be meeting in Orlando for IETF 86 ;^) 

From: Ericsson <acee.lindem@ericsson.com>
Date: Wednesday, March 6, 2013 10:4= 8 AM
To: OSPF List <ospf@ietf.org>
Subject: [OSPF] OSPF IETF 86 WG Mee= ting in Atlanta

We have a full agenda. We'll work Fred in when he is available as he i= s concurrently co-chairing V6OPS. I put the TE stuff on the end since the w= ork may be done in other WGs. 


If you would be willing to take minutes please contact Abhay or myself= . 

Thanks,
Acee 
 --_000_94A203EA12AECE4BA92D42DBFFE0AE470F1B3Eeusaamb101ericsso_-- From huaimo.chen@huawei.com Wed Mar 6 14:27:08 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8413021F8C8D for ; Wed, 6 Mar 2013 14:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.521 X-Spam-Level: X-Spam-Status: No, score=-4.521 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pre8srRFS2hm for ; Wed, 6 Mar 2013 14:27:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D78D121F842B for ; Wed, 6 Mar 2013 14:27:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APC31415; Wed, 06 Mar 2013 22:27:01 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 6 Mar 2013 22:26:48 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 6 Mar 2013 22:26:59 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.122]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.007; Wed, 6 Mar 2013 14:26:57 -0800 From: Huaimo Chen To: Acee Lindem Thread-Topic: OSPF TTZ Thread-Index: AQHOGp2AFgG0PvTGnk+Wh8hD9BYN/JiZL6iA Date: Wed, 6 Mar 2013 22:26:56 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4451B2E92@dfweml509-mbx.china.huawei.com> References: <94A203EA12AECE4BA92D42DBFFE0AE470F1B06@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470F1B06@eusaamb101.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.26] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D4451B2E92dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: OSPF List Subject: Re: [OSPF] OSPF TTZ X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2013 22:27:08 -0000 --_000_5316A0AB3C851246A7CA5758973207D4451B2E92dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Acee, Yes. You are correct. In this version of the draft, a TTZ is virtualized as= the edge routers of the TTZ that are fully connected. The cost of the "vir= tual" connection between TTZ edge router A and B is the cost of the shorte= st path between A and B inside the TTZ. From a router X outside of the TTZ,= router X sees that there is a "direct" connection with a cost between rou= ter A and router B even though there are many routers and links between A = and B inside the TTZ. Router X is not aware of any TTZ. Best Regards, Huaimo From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: Wednesday, March 06, 2013 2:05 PM To: Huaimo Chen Cc: OSPF List Subject: OSPF TTZ Hi Huaimo, If I understand the draft correctly, the TTZ is virtualized as N Router-LSA= s where N is the the number of TTZ edge routers and the TTZ edge routers ar= e fully meshed - correct? What cost is advertised for the virtual links - i= s it the actual internal cost? Thanks, Acee --_000_5316A0AB3C851246A7CA5758973207D4451B2E92dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Acee,

 <= /p>

Yes. You are correct. In this version of the draft, a TTZ is virtualized= as the edge routers of the TTZ that are fully connected. The cost of the “virtual” connection  between TTZ edge ro= uter A and B is the cost of the shortest path between A and B inside the TT= Z. From a router X outside of the TTZ, router X sees that there is a “= ;direct” connection with a cost  between router A and  rout= er B even though there are many routers and links between A and B inside the = TTZ. Router X  is not aware of any TTZ.

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

 <= /p>

From: Acee Lin= dem [mailto:acee.lindem@ericsson.com]
Sent: Wednesday, March 06, 2013 2:05 PM
To: Huaimo Chen
Cc: OSPF List
Subject: OSPF TTZ

 

 

Hi Huaimo,

 

If I understand the draft c= orrectly, the TTZ is virtualized as N Router-LSAs where N is the the number= of TTZ edge routers and the TTZ edge routers are fully meshed – correct? What cost is advertised for the virtual links R= 11; is it the actual internal cost? 

 

Thanks,

Acee 

--_000_5316A0AB3C851246A7CA5758973207D4451B2E92dfweml509mbxchi_-- From acee.lindem@ericsson.com Wed Mar 20 12:57:19 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564C111E8107 for ; Wed, 20 Mar 2013 12:57: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mmhqLXT-EWi for ; Wed, 20 Mar 2013 12:57:17 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB5111E80DE for ; Wed, 20 Mar 2013 12:57:16 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-54-514a149bad78 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id AA.97.02430.B941A415; Wed, 20 Mar 2013 20:57:16 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 15:57:15 -0400 From: Acee Lindem To: OSPF List Thread-Topic: IETF 86 OSPF WG Minutes Thread-Index: AQHOJaUezGPBkDhos02a7ui3KBhPdQ== Date: Wed, 20 Mar 2013 19:57:14 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470FF13B@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <4558D24A54BB214A8942F6537A922F2F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyuXRPuO4cEa9Ag+n7uC1a7t1jd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxo45M1kLtjNWvH2ylb2BcQZjFyMnh4SAicTy99vZIWwxiQv3 1rN1MXJxCAkcYZTYcHsjlLOcUWL/1mksIFVsAjoSzx/9YwaxRQRkJZYu2c8KYgsLKEq0b1vB BBFXk1hwcxJUjZ5E861HYDUsAqoSuy9fALN5BbwlPnWuB7uCEWjz91NrwHqZBcQlbj2ZzwRx kYDEkj3nmSFsUYmXj/+xQtjKEt/nPGKBqNeRWLD7ExuEbS2x73cLlK0tsWzha2aIXYISJ2c+ YZnAKDILyYpZSNpnIWmfhaR9FpL2BYysqxg5SotTy3LTjQw2MQJD/5gEm+4Oxj0vLQ8xSnOw KInzBrleCBASSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA2LkxId3d8X/D3nMrUiKX22xvPJZT duuXo8ZhR83W3nXzYwP+We5vSA76ZXZE5mFoyacL/H8+zGD5a7lM7Pi+txrVd23lyy6G833c xbruq6oqj/W/9sYOTrmTV599UCnoy9+wYkVu8YQPk7prbM7+4jz77dn+O9OO7Ti6pf6yiBnf a5vJ37KvJSmxFGckGmoxFxUnAgCceoRmSwIAAA== Subject: [OSPF] IETF 86 OSPF WG Minutes X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2013 19:57:19 -0000 The OSPF WG meeting minutes have been posted at: http://www.ietf.org/procee= dings/86/minutes/minutes-86-ospf Thanks to Alvaro Retana from Cisco for taking them.=20 Acee=20 From gregimirsky@gmail.com Wed Mar 20 13:05:55 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6995511E80EF for ; Wed, 20 Mar 2013 13:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJdeku97TmaN for ; Wed, 20 Mar 2013 13:05:54 -0700 (PDT) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 84CAA11E80DE for ; Wed, 20 Mar 2013 13:05:51 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id fa15so1370339vbb.39 for ; Wed, 20 Mar 2013 13:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=igRfe/tovaseFE7atoKcv5xitjAq84ZxYUD7qcpYl/U=; b=R/Bje1dxDo2KyB0T1ly/HxhNGHTFigwxuUgvMMfMO5dceY0ZD7FCYWTD0lbof0eDux W9T5/YRIwFVa3jKK/7yQmikdWaGHAaEUxnkAq2wQPD1JAwB5n6Is+K6lzohAmN0XMzf0 nDvA6NW2yYqU0iNvWAFUiHf7SbZtn8Fr4o2mFchfzBFZKs0B5F1Fuvrr0sGnP1QxJepF c+f5ivDh3MfzQSJBNc0QfYP3zq9B2fE8xOLW0XC2Kzt75Y4n918v2bOis59iZijcnG7K e/HJVrFk++3wyRttDfTBTh3AGRdF/KibAyq1NdKwOcoTVSku04H7Z4A4bvaVH3Py54on +2PA== MIME-Version: 1.0 X-Received: by 10.59.11.67 with SMTP id eg3mr9885292ved.31.1363809950758; Wed, 20 Mar 2013 13:05:50 -0700 (PDT) Received: by 10.220.217.73 with HTTP; Wed, 20 Mar 2013 13:05:50 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF112073408@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF112073408@eusaamb103.ericsson.se> Date: Wed, 20 Mar 2013 13:05:50 -0700 Message-ID: From: Greg Mirsky To: "ospf@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0ec72a7fea704d860bf83 Subject: [OSPF] Fwd: FW: [Isis-wg] IGP-TE extensions for unidirectional Link Delay, Delay Variation, and Link Loss X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2013 20:05:55 -0000 --047d7bf0ec72a7fea704d860bf83 Content-Type: text/plain; charset=ISO-8859-1 Making it to OSPF WG, finally. ------------------------------ *From:* Gregory Mirsky *Sent:* Wednesday, March 20, 2013 10:16 AM *To:* 'Alia Atlas' *Cc:* Clarence Filsfils; akatlas@juniper.net; Spencer.giacalone@thomsonreuters.com; isis-wg@ietf.org; sprevidi@cisco.com; John E Drake; ospf-wg@ietf.org; wardd@cisco.com *Subject:* RE: [Isis-wg] IGP-TE extensions for unidirectional Link Delay, Delay Variation, and Link Loss Hi Alia, et al., I was thinking about reflecting queuing without actually measuring it. I think that major concern with measuring dynamic queuing is that we have only active, including synthetic, measuring methods that change the process, at least that is to the best of my knowledge. But there're discussions on passive and/or hybrid methods that will be less distractive to the traffic. But there's another approach that I see as most practical at this time - AQM. AQM can be expressed in maximum queuing delay and it will exactly characterize unidirectional delay, delay variation on the given link. Again, it might not happen tomorrow but I believe that it is beneficial to make tool flexible for the future, perhaps near future. Regards, Greg ------------------------------ *From:* Alia Atlas [mailto:akatlas@gmail.com] *Sent:* Wednesday, March 20, 2013 2:05 AM *To:* Gregory Mirsky *Cc:* Clarence Filsfils; akatlas@juniper.net; Spencer.giacalone@thomsonreuters.com; isis-wg@ietf.org; sprevidi@cisco.com; John E Drake; ospf-wg@ietf.org; wardd@cisco.com *Subject:* Re: [Isis-wg] IGP-TE extensions for unidirectional Link Delay, Delay Variation, and Link Loss I agree with Spencer that I don't see the extra information on a per-queue being useful if we are not measuring dynamic queuing behavior and delay. How do you see these values being different? Where would you get them from while avoiding the concerns about a traffic-dependent feedback loop? Alia On Mar 19, 2013 3:14 AM, "Gregory Mirsky" wrote: > Dear Authors, et al., > As mentioned at the mike during IS-IS WG meeting in Orlando, I believe > that three parameters, Link Delay, Delay Variation, and Link Loss are per > priority/Traffic Class. Other link characteristics introduced in > draft-previdi-isis-te-metric-extensions- and > draft-ietf-ospf-te-metric-extensions- documents, Residual Bandwidth and > Available Bandwidth, might not have distinct per priority connotation. > > I think that per priority advertisement does not imply dynamic queuing > being included, not suggest how these metrics get their values (dynamic > measurement or estimate), but allows more realistically characterize a link. > > Comments, suggestions are welcome and greatly appreciated. > > Regards, > Greg > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > > --047d7bf0ec72a7fea704d860bf83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Making it to OSPF WG, finally.

From: Gregory Mirsky
Sent: Wednesday, March 20, 2013 10:16 AM
To: 'Alia Atlas'
Cc: Clarence Filsfils; akatlas@juniper.net; Spencer.giacalone@thomsonreuters.com; isis-wg@ietf.org; sprevidi@cisco.= com; John E Drake; ospf-wg@ietf.org; wardd@cisco.com
Subject: RE: [Isis-wg] IGP-TE extensions for unidirectional Link Del= ay, Delay Variation, and Link Loss

Hi Alia, et al.,
I was thinking about reflecting queuing without actually measuring it. I = think that major concern with measuring dynamic queuing is that we have onl= y active, including synthetic,=A0measuring methods that change the process, at least= that is to the best of my knowledge. But there're discussions on passi= ve and/or hybrid methods that will be less distractive to the traffic. But = there's another approach that I see as most practical at this time - AQM. AQM can be expressed in maximum queuing= delay and it will exactly characterize unidirectional delay, delay variati= on on the given link.
Again, it might not happen tomorrow but I believe that it is beneficial t= o make tool flexible for the future, perhaps near future.
=A0
=A0=A0=A0 Regards,
=A0=A0=A0=A0=A0=A0=A0 Greg

From: Alia Atlas [mailto:akatlas@gmail.com]
Sent: Wednesday, March 20, 2013 2:05 AM
To: Gregory Mirsky
Cc: Clarence Filsfils; akatlas@juniper.net; Spencer.giacalone@thomsonreuters.com; isis-wg@ietf.org; sprevidi@cisco.= com; John E Drake; ospf-wg@ietf.org; wardd@cisco.com
Subject: Re: [Isis-wg] IGP-TE extensions for unidirectional Link Del= ay, Delay Variation, and Link Loss

I agree with Spencer that I don't see the extra informat= ion on a per-queue being useful if we are not measuring dynamic queuing beh= avior and delay.

How do you see these values being different?=A0=A0 Where wou= ld you get them from while avoiding the concerns about a traffic-dependent = feedback loop?

Alia

On Mar 19, 2013 3:14 AM, "Gregory Mirsky&qu= ot; <gr= egory.mirsky@ericsson.com> wrote:
Dear Authors, et al.,
As mentioned at the mike during IS-IS WG meeting in Orlando, I believe= that three parameters, Link Delay, Delay Variation, and Link Loss are per = priority/Traffic Class. Other link characteristics introduced in draft-prev= idi-isis-te-metric-extensions- and draft-ietf-ospf-te-metric-extensions- documents, Residual Bandwidth and Av= ailable Bandwidth, might not have distinct per priority connotation.
=A0
I think that per priority advertisement does not imply dynamic queuing= being included, not suggest how these metrics get their values (dynamic me= asurement or estimate), but allows more realistically characterize a link.<= /div>
=A0
Comments, suggestions are welcome and greatly appreciated.
=A0
=A0=A0=A0=A0=A0=A0=A0 Regards,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Greg
=A0

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org<= br> https://www.ietf.org/mailman/listinfo/isis-wg


--047d7bf0ec72a7fea704d860bf83-- From minto@juniper.net Wed Mar 20 13:47:23 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4FC21F86F5 for ; Wed, 20 Mar 2013 13:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l19XGyZWrTNj for ; Wed, 20 Mar 2013 13:47:21 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id D6F5B21F870F for ; Wed, 20 Mar 2013 13:47:21 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUUogWJJWWydDYzwbOv+9N7iChdq+s8/l@postini.com; Wed, 20 Mar 2013 13:47:21 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 20 Mar 2013 13:30:00 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 20 Mar 2013 13:30:00 -0700 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.140) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 20 Mar 2013 13:32:17 -0700 Received: from mail22-db3-R.bigfish.com (10.3.81.254) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Mar 2013 20:29:56 +0000 Received: from mail22-db3 (localhost [127.0.0.1]) by mail22-db3-R.bigfish.com (Postfix) with ESMTP id 92CE23E0071 for ; Wed, 20 Mar 2013 20:29:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zzzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail22-db3 (localhost.localdomain [127.0.0.1]) by mail22-db3 (MessageSwitch) id 1363811394636198_11519; Wed, 20 Mar 2013 20:29:54 +0000 (UTC) Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.230]) by mail22-db3.bigfish.com (Postfix) with ESMTP id 980FD100045; Wed, 20 Mar 2013 20:29:54 +0000 (UTC) Received: from BLUPRD0512HT004.namprd05.prod.outlook.com (132.245.1.149) by DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Mar 2013 20:29:53 +0000 Received: from BLUPRD0512MB659.namprd05.prod.outlook.com ([169.254.2.18]) by BLUPRD0512HT004.namprd05.prod.outlook.com ([10.255.215.165]) with mapi id 14.16.0275.006; Wed, 20 Mar 2013 20:29:51 +0000 From: Minto Jeyananth To: "anandmkr@cisco.com" , "hasmit@cisco.com" , "akr@cisco.com" , "ospf@ietf.org" Thread-Topic: Asymmetric OSPF Hold Timer draft Thread-Index: Ac4lqavmp/Rfju5zQ5yDlADp+AxPdg== Date: Wed, 20 Mar 2013 20:29:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [OSPF] Asymmetric OSPF Hold Timer draft X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2013 20:47:23 -0000 Hi Authors, =20 Expert from the draft=20 "One of the implications of such busy periods of state restoration in a process is that, the process may not be able to sustain the rate of sending HELLOs across all its interfaces. In a controlled restart scenario (such as OSPF Graceful restart), the router is able to ask for a grace period by flooding out opaque LSAs indicating that it is restarting. In case of upgrades and restarts with state restoration, (i.e., not involving a graceful restart), this is not possible." =20 Does not it a pure implementation issue? Implementation could simply preven= t such an unsupported configuration.=20 With BFD does OSPF needs aggressive interval?=20 Thanks=20 -minto=20 From acee.lindem@ericsson.com Thu Mar 21 10:28:42 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600A521F916C for ; Thu, 21 Mar 2013 10:28:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUwpFqAsQqkQ for ; Thu, 21 Mar 2013 10:28:41 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id F20BC21F9158 for ; Thu, 21 Mar 2013 10:28:40 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-d7-514b4347d5aa Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 18.97.02411.7434B415; Thu, 21 Mar 2013 18:28:39 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 13:28:38 -0400 From: Acee Lindem To: Minto Jeyananth , "anandmkr@cisco.com" , "hasmit@cisco.com" , "akr@cisco.com" , "ospf@ietf.org" Thread-Topic: [OSPF] Asymmetric OSPF Hold Timer draft Thread-Index: Ac4lqavmp/Rfju5zQ5yDlADp+AxPdgAnxcGA Date: Thu, 21 Mar 2013 17:28:38 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4710056C@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <5B13E2F272A0414698B8CA18D761E5FF@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPgq67s3egwc0T8haHD85is9i+/TCz xYe/j5gtXrcfYLZouXeP3YHVY8rvjaweS5b8ZPK43nSVPYA5issmJTUnsyy1SN8ugStj1cdN bAVdXBU/3j1kbGDs4uhi5OCQEDCRWN5g18XICWSKSVy4t56ti5GLQ0jgCKPEx4uvGCGc5YwS fyauZAepYhPQkXj+6B8zSEJEYD+jRP+TFWwgCWGgSb9mTgArEhEwlZgPZnMA2UYSSz8kgJgs AqoSF+fog1TwCnhLfGxsZQSxOQUSJd61bQabwgh0xPdTa5hAbGYBcYlbT+YzQRwnILFkz3lm CFtU4uXjf6wgtqiAnkTbsTPsEHFliSVP9rNA9OpILNj9iQ3CtpZ4+O42lK0tsWzha2aIGwQl Ts58wjKBUWwWknWzkLTPQtI+C0n7LCTtCxhZVzFylBanluWmGxluYgTG2DEJNscdjAs+WR5i lOZgURLnDXW9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMUdi/fP6taaL5/tNqDgSy7nN lYd3Udfybr7Nr6/UmN7t2OO4QdfDrOTqb+kpO9SfTnzIIffR59aOmzWH6qp+nZhvtFfz3c5H 1tX5cSKJIdkZ01cqzapwDt//6ss0x9IN7sq5GvdWcL20OC72b7WqYXtKcjL3zxCH1novO5E9 9yYFSVyokr9xVImlOCPRUIu5qDgRAP7u5YR/AgAA Subject: Re: [OSPF] Asymmetric OSPF Hold Timer draft X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 17:28:42 -0000 Speaking as a WG member, On 3/20/13 1:29 PM, "Minto Jeyananth" wrote: >Hi Authors, =20 > >Expert from the draft > > "One of the implications of such busy periods of state restoration in > a process is that, the process may not be able to sustain the rate of > sending HELLOs across all its interfaces. In a controlled restart > scenario (such as OSPF Graceful restart), the router is able to ask > for a grace period by flooding out opaque LSAs indicating that it is > restarting. In case of upgrades and restarts with state restoration, > (i.e., not involving a graceful restart), this is not possible." > >Does not it a pure implementation issue? Implementation could simply >prevent such an unsupported configuration. >With BFD does OSPF needs aggressive interval? Normally, BFD is used for sub-second convergence. If there is some control plane switchover, the new active OSPF process must be able to send a hello on all interfaces before the dead interval expires. I feel this draft is more useful for OSPFv3 auto configuration. Thanks, Acee >=20 > >Thanks=20 >-minto=20 > > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From anandmkr@cisco.com Thu Mar 21 10:52:31 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25E121F8574 for ; Thu, 21 Mar 2013 10:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.044 X-Spam-Level: X-Spam-Status: No, score=-10.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9j72jPteDts for ; Thu, 21 Mar 2013 10:52:30 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9D90D21F842A for ; Thu, 21 Mar 2013 10:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2043; q=dns/txt; s=iport; t=1363888334; x=1365097934; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=tSzY0W+GA/AzQ9WyTDj2i6AXYsLFyeaQy4ggoRnhAcg=; b=kM1NBPnVLEnqok+qGYjqgzTRF/r+0yH+/yi7RwIbTkFl36nYdLDC+OxZ Dwx6SpR5Xt4T8wAdsLAaKjhjTKxR8iQ0xEI3gy9bA3qCeV4QuOqEOgDUz RsayM7GdBK+m3Bltmk2INuJMPRHY3wcdiYONnLgE85g1eYvN9B/tc7eZD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAI5GS1GtJV2a/2dsb2JhbABDxUCBXBZ0giYBBDoxIAEIIhRCJQEBBAESCBOHecJhjVEdcjiCX2EDp2aDCoFsBxce X-IronPort-AV: E=Sophos;i="4.84,887,1355097600"; d="scan'208";a="190073767" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 21 Mar 2013 17:52:14 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2LHqDOF021388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 17:52:13 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 12:52:13 -0500 From: "Madhukar Anand (anandmkr)" To: Minto Jeyananth , "Hasmit Grover (hasmit)" , "Abhay Roy (akr)" , "ospf@ietf.org" Thread-Topic: Asymmetric OSPF Hold Timer draft Thread-Index: Ac4lqavmp/Rfju5zQ5yDlADp+AxPdgAomCiA Date: Thu, 21 Mar 2013 17:52:12 +0000 Message-ID: <60816F26681B6440A1552440352BAE942CA98F@xmb-aln-x05.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.154.204.196] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OSPF] Asymmetric OSPF Hold Timer draft X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 17:52:32 -0000 [Apologies if you have received multiple copies. I had trouble sending that last email out] Hi Minto, Thanks for your feedback and comments. Let me try to address your concerns here. Firstly, OSPF HELLOs cannot be eliminated with BFD as they are used for neighbor discover and carrying bits of information for OSPF's peers. There are use-cases (for e.g., with aggressive HELLO timers) where the recovery window may not be sufficient however efficient the implementation may be. Even with the default HELLO/dead timer, there is possibly a breaking point depending on the scale of OSPF configuration on the router. Secondly, we envision that the proposed solution complements BFD. BFD could Be used for fast link down detection, and the asymmetric hold timer can be used to manage OSPF neighbor down detection. Thirdly, asymmetric hold timers have use-cases beyond the upgrade scenario highlighted here (for instance, with OSPFv3 autoconfiguration/HOMENET). We are working on adding this use-case to the draft also. There is some discussion in Sec 4 of the draft along the lines I've just highlighted. Please let us know if there are more questions. Thanks, Madhukar On 3/20/13 1:29 PM, "Minto Jeyananth" wrote: >Hi Authors, =20 > >Expert from the draft > > "One of the implications of such busy periods of state restoration in > a process is that, the process may not be able to sustain the rate of > sending HELLOs across all its interfaces. In a controlled restart > scenario (such as OSPF Graceful restart), the router is able to ask > for a grace period by flooding out opaque LSAs indicating that it is > restarting. In case of upgrades and restarts with state restoration, > (i.e., not involving a graceful restart), this is not possible." > >Does not it a pure implementation issue? Implementation could simply >prevent such an unsupported configuration. >With BFD does OSPF needs aggressive interval? > >Thanks=20 >-minto=20 > > From minto@juniper.net Thu Mar 21 11:54:41 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A74721F8556 for ; Thu, 21 Mar 2013 11:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFfb6ZhqiNWJ for ; Thu, 21 Mar 2013 11:54:40 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 3B42F21F8439 for ; Thu, 21 Mar 2013 11:54:40 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUUtXcP7dFnC0eq3dRJsAxYK9TI2uD5r+@postini.com; Thu, 21 Mar 2013 11:54:40 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 21 Mar 2013 11:51:50 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 21 Mar 2013 11:51:50 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.31) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 21 Mar 2013 12:01:04 -0700 Received: from mail78-va3-R.bigfish.com (10.7.14.229) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Mar 2013 18:51:49 +0000 Received: from mail78-va3 (localhost [127.0.0.1]) by mail78-va3-R.bigfish.com (Postfix) with ESMTP id 73144201CA for ; Thu, 21 Mar 2013 18:51:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I542I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail78-va3 (localhost.localdomain [127.0.0.1]) by mail78-va3 (MessageSwitch) id 1363891907364897_10072; Thu, 21 Mar 2013 18:51:47 +0000 (UTC) Received: from VA3EHSMHS042.bigfish.com (unknown [10.7.14.238]) by mail78-va3.bigfish.com (Postfix) with ESMTP id 548EF26015A; Thu, 21 Mar 2013 18:51:47 +0000 (UTC) Received: from BLUPRD0512HT004.namprd05.prod.outlook.com (132.245.1.149) by VA3EHSMHS042.bigfish.com (10.7.99.52) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Mar 2013 18:51:42 +0000 Received: from BLUPRD0512MB659.namprd05.prod.outlook.com ([169.254.2.18]) by BLUPRD0512HT004.namprd05.prod.outlook.com ([10.255.215.165]) with mapi id 14.16.0275.006; Thu, 21 Mar 2013 18:51:41 +0000 From: Minto Jeyananth To: "Madhukar Anand (anandmkr)" , "Hasmit Grover (hasmit)" , "Abhay Roy (akr)" , "ospf@ietf.org" Thread-Topic: Asymmetric OSPF Hold Timer draft Thread-Index: Ac4lqavmp/Rfju5zQ5yDlADp+AxPdgAoR7GAAAT7SdA= Date: Thu, 21 Mar 2013 18:51:40 +0000 Message-ID: References: <60816F26681B6440A1552440352BAE942CA926@xmb-aln-x05.cisco.com> In-Reply-To: <60816F26681B6440A1552440352BAE942CA926@xmb-aln-x05.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [OSPF] Asymmetric OSPF Hold Timer draft X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 18:54:41 -0000 Madhukar,=20 Thanks for response. Please see inline.=20 |-----Original Message----- |From: Madhukar Anand (anandmkr) [mailto:anandmkr@cisco.com] |Sent: Thursday, March 21, 2013 10:43 AM |To: Minto Jeyananth; Hasmit Grover (hasmit); Abhay Roy (akr); |ospf@ietf.org |Subject: Re: Asymmetric OSPF Hold Timer draft | |Hi Minto, | | Thanks for your feedback and comments. Let me try to address your |concerns here. | |Firstly, OSPF HELLOs cannot be eliminated with BFD as they are used for |neighbor discover and carrying bits of information for OSPF's peers. Agreed OSPF HELLOs cannot be eliminated. But comment was about aggressive h= ello(/dead) interval. OSPF could be configured with high interval for disco= very and uses BFD for failure detection. =20 |There are use-cases (for e.g., with aggressive HELLO timers) where the |recovery window may not be sufficient however efficient the |implementation may be. Even with the default HELLO/dead timer, there is |possibly a breaking point depending on the scale of OSPF configuration |on the router. Again, user could configure a higher interval so that system could handle i= t.=20 | |Secondly, we envision that the proposed solution complements BFD. BFD |could Be used for fast link down detection, and the asymmetric hold |timer can be used to manage OSPF neighbor down detection. OSPF Hello and BFD are for an adjacency. How OSPF asymmetric hello timers h= elp here to detect neighbor down but not BFD?=20 | |Thirdly, asymmetric hold timers have use-cases beyond the upgrade |scenario highlighted here (for instance, with OSPFv3 |autoconfiguration/HOMENET). |We are working on adding this use-case to the draft also. OK. The uses cases mention in current draft seems implementation issues.=20 Also RFC-2328 assumes hello & dead intervals are symmetric especially in br= oadcast interfaces (wait-timer).=20 -minto=20 | |There is some discussion in Sec 4 of the draft along the lines I've just |highlighted. |Please let us know if there are more questions. | |Thanks, |Madhukar | | | |On 3/20/13 1:29 PM, "Minto Jeyananth" wrote: | |>Hi Authors, |> |>Expert from the draft |> |> "One of the implications of such busy periods of state restoration |in |> a process is that, the process may not be able to sustain the rate |of |> sending HELLOs across all its interfaces. In a controlled restart |> scenario (such as OSPF Graceful restart), the router is able to ask |> for a grace period by flooding out opaque LSAs indicating that it is |> restarting. In case of upgrades and restarts with state |restoration, |> (i.e., not involving a graceful restart), this is not possible." |> |>Does not it a pure implementation issue? Implementation could simply |>prevent such an unsupported configuration. |>With BFD does OSPF needs aggressive interval? |> |>Thanks |>-minto |> | From anandmkr@cisco.com Thu Mar 21 12:28:04 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB1521F85D2 for ; Thu, 21 Mar 2013 12:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usszpEahDeW6 for ; Thu, 21 Mar 2013 12:28:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 13F8D21F85A0 for ; Thu, 21 Mar 2013 12:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4309; q=dns/txt; s=iport; t=1363894083; x=1365103683; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=EA8NDDOREKhdy/HwWzTG49enYFBrl3S4LwW8JYfVPkQ=; b=NsXPI72TitjWrxbUdIfKL4N3r+f8OglS1uaj/ILXyNwgR22zcnOhqi+M uja+o2moAWWwf5ikmav3MszlH1XWwu7l+XFORlVcfAToHS0EiF4rDp2DP WQ2SXRRI9Pffy6oT1WPFOq6OE59Y9U/hEwnxJyE2AdElMvK/OuOJPhdve E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAK9dS1GtJV2Y/2dsb2JhbABDxU6BXBZ0giQBAQEEOjEaBgEIEQQBAQEKFAk5FAkIAQEEARIIE4d5wlSNbnImEgaCWWEDp2aDCoFsPA X-IronPort-AV: E=Sophos;i="4.84,888,1355097600"; d="scan'208";a="189898161" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 21 Mar 2013 19:28:02 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2LJS2aa012685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 19:28:02 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 14:28:02 -0500 From: "Madhukar Anand (anandmkr)" To: Minto Jeyananth , "Hasmit Grover (hasmit)" , "Abhay Roy (akr)" , "ospf@ietf.org" Thread-Topic: Asymmetric OSPF Hold Timer draft Thread-Index: Ac4lqavmp/Rfju5zQ5yDlADp+AxPdgAoR7GAAAT7SdD///VrgA== Date: Thu, 21 Mar 2013 19:28:01 +0000 Message-ID: <60816F26681B6440A1552440352BAE942CAB70@xmb-aln-x05.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.154.204.196] Content-Type: text/plain; charset="us-ascii" Content-ID: <508E1227F0F27E4D91F0132E594C33B4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OSPF] Asymmetric OSPF Hold Timer draft X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 19:28:04 -0000 Hi Minto,=20 Please find our comments inline. Thanks, Madhukar On 3/21/13 11:51 AM, "Minto Jeyananth" wrote: >Madhukar,=20 > > Thanks for response. Please see inline. > >|-----Original Message----- >|From: Madhukar Anand (anandmkr) [mailto:anandmkr@cisco.com] >|Sent: Thursday, March 21, 2013 10:43 AM >|To: Minto Jeyananth; Hasmit Grover (hasmit); Abhay Roy (akr); >|ospf@ietf.org >|Subject: Re: Asymmetric OSPF Hold Timer draft >| >|Hi Minto, >| >| Thanks for your feedback and comments. Let me try to address your >|concerns here. >| >|Firstly, OSPF HELLOs cannot be eliminated with BFD as they are used for >|neighbor discover and carrying bits of information for OSPF's peers. > >Agreed OSPF HELLOs cannot be eliminated. But comment was about aggressive >hello(/dead) interval. OSPF could be configured with high interval for >discovery and uses BFD for failure detection. Yes, this is true. Please note that we are not advocating one solution over other, which we believe is best left to the customer requirements and =20 Design, and not really related to any particular implementation issue. >=20 >|There are use-cases (for e.g., with aggressive HELLO timers) where the >|recovery window may not be sufficient however efficient the >|implementation may be. Even with the default HELLO/dead timer, there is >|possibly a breaking point depending on the scale of OSPF configuration >|on the router. > >Again, user could configure a higher interval so that system could handle >it. Yes, we agree that a BFD based approach could be used address some of the concerns here. Again, please note that we are not advocating one solution over other, which we believe is best left to the customer requirements and design, and not really related to any particular implementation issue. >=20 > >| >|Secondly, we envision that the proposed solution complements BFD. BFD >|could Be used for fast link down detection, and the asymmetric hold >|timer can be used to manage OSPF neighbor down detection. > >OSPF Hello and BFD are for an adjacency. How OSPF asymmetric hello timers >help here to detect neighbor down but not BFD? > >| >|Thirdly, asymmetric hold timers have use-cases beyond the upgrade >|scenario highlighted here (for instance, with OSPFv3 >|autoconfiguration/HOMENET). >|We are working on adding this use-case to the draft also. > >OK. The uses cases mention in current draft seems implementation issues. We have other use-cases too. For instance, with the hub-and-spoke topology, It may be desirable to have different hold timers on either side. Another Example is with the HOMENET/OSPFv3 auto configuration where it may also be desirable to allow asymmetric hold timers. >=20 > >Also RFC-2328 assumes hello & dead intervals are symmetric especially in >broadcast interfaces (wait-timer). This is precisely the main thrust of this proposal. We want to relax that assumption for a number of use-cases. To summarize, we do not believe this=20 is driven by any particular implementation need, but by the need to allow OSPF to function with many different customer deployments and use-cases. > >-minto=20 > >| >|There is some discussion in Sec 4 of the draft along the lines I've just >|highlighted. >|Please let us know if there are more questions. >| >|Thanks, >|Madhukar >| >| >| >|On 3/20/13 1:29 PM, "Minto Jeyananth" wrote: >| >|>Hi Authors, >|> >|>Expert from the draft >|> >|> "One of the implications of such busy periods of state restoration >|in >|> a process is that, the process may not be able to sustain the rate >|of >|> sending HELLOs across all its interfaces. In a controlled restart >|> scenario (such as OSPF Graceful restart), the router is able to ask >|> for a grace period by flooding out opaque LSAs indicating that it is >|> restarting. In case of upgrades and restarts with state >|restoration, >|> (i.e., not involving a graceful restart), this is not possible." >|> >|>Does not it a pure implementation issue? Implementation could simply >|>prevent such an unsupported configuration. >|>With BFD does OSPF needs aggressive interval? >|> >|>Thanks >|>-minto >|> >| From andrew.dolganow@alcatel-lucent.com Fri Mar 22 01:59:21 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F102A21F902F for ; Fri, 22 Mar 2013 01:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L89Ui2UavEsJ for ; Fri, 22 Mar 2013 01:59:20 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC7D21F901E for ; Fri, 22 Mar 2013 01:59:18 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r2M8xGps001010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2013 03:59:17 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r2M8xGZT009068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 04:59:16 -0400 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.201]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Fri, 22 Mar 2013 04:59:16 -0400 From: "Dolganow, Andrew (Andrew)" To: "Madhukar Anand (anandmkr)" , Minto Jeyananth , "Hasmit Grover (hasmit)" , "Abhay Roy (akr)" , "ospf@ietf.org" Thread-Topic: [OSPF] Asymmetric OSPF Hold Timer draft Thread-Index: Ac4lqavmp/Rfju5zQ5yDlADp+AxPdgAoR7GAAAT7SdD///VrgIABWAkA Date: Fri, 22 Mar 2013 08:59:15 +0000 Message-ID: In-Reply-To: <60816F26681B6440A1552440352BAE942CAB70@xmb-aln-x05.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [OSPF] Asymmetric OSPF Hold Timer draft X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 22 Mar 2013 08:59:21 -0000 Madhukar Please see inline On 2013-03-21 8:28 PM, "Madhukar Anand (anandmkr)" wrote: >Hi Minto,=20 > Please find our comments inline. > >Thanks, >Madhukar > > >On 3/21/13 11:51 AM, "Minto Jeyananth" wrote: > >>Madhukar,=20 >> >> Thanks for response. Please see inline. >> >>|-----Original Message----- >>|From: Madhukar Anand (anandmkr) [mailto:anandmkr@cisco.com] >>|Sent: Thursday, March 21, 2013 10:43 AM >>|To: Minto Jeyananth; Hasmit Grover (hasmit); Abhay Roy (akr); >>|ospf@ietf.org >>|Subject: Re: Asymmetric OSPF Hold Timer draft >>| >>|Hi Minto, >>| >>| Thanks for your feedback and comments. Let me try to address your >>|concerns here. >>| >>|Firstly, OSPF HELLOs cannot be eliminated with BFD as they are used for >>|neighbor discover and carrying bits of information for OSPF's peers. >> >>Agreed OSPF HELLOs cannot be eliminated. But comment was about aggressive >>hello(/dead) interval. OSPF could be configured with high interval for >>discovery and uses BFD for failure detection. > >Yes, this is true. Please note that we are not advocating one solution >over other, which we believe is best left to the customer requirements and >=20 >Design, and not really related to any particular implementation issue. Although you are not advocating one solution over the other, you are proposing to add a complication to an existing protocol to do something that can be easily achieved with longer OSPF hello timer and short BFD timer, that can be dynamically adapted during cases like ISSU for example. So what is the value of introducing yet another thing to solve exactly the same problem? > > >>=20 >>|There are use-cases (for e.g., with aggressive HELLO timers) where the >>|recovery window may not be sufficient however efficient the >>|implementation may be. Even with the default HELLO/dead timer, there is >>|possibly a breaking point depending on the scale of OSPF configuration >>|on the router. >> >>Again, user could configure a higher interval so that system could handle >>it. > > >Yes, we agree that a BFD based approach could be used address some of the >concerns here. Again, please note that we are not advocating one solution >over other, which we believe is best left to the customer requirements >and design, and not really related to any particular implementation issue. > > >>=20 >> >>| >>|Secondly, we envision that the proposed solution complements BFD. BFD >>|could Be used for fast link down detection, and the asymmetric hold >>|timer can be used to manage OSPF neighbor down detection. >> >>OSPF Hello and BFD are for an adjacency. How OSPF asymmetric hello timers >>help here to detect neighbor down but not BFD? >> >>| >>|Thirdly, asymmetric hold timers have use-cases beyond the upgrade >>|scenario highlighted here (for instance, with OSPFv3 >>|autoconfiguration/HOMENET). >>|We are working on adding this use-case to the draft also. >> >>OK. The uses cases mention in current draft seems implementation issues. > > >We have other use-cases too. For instance, with the hub-and-spoke >topology, >It may be desirable to have different hold timers on either side. Another >Example is with the HOMENET/OSPFv3 auto configuration where it may also >be desirable to allow asymmetric hold timers. Why would you need different timers here, the only reason would be sub-quality implementation or router deployed in a hub place that cannot handle the deployment scale. I do not think we should be creating protocol extensions for cases like that. > > > >>=20 >> >>Also RFC-2328 assumes hello & dead intervals are symmetric especially in >>broadcast interfaces (wait-timer). > > >This is precisely the main thrust of this proposal. We want to relax that >assumption for a number of use-cases. To summarize, we do not believe >this=20 >is driven by any particular implementation need, but by the need to allow >OSPF to function with many different customer deployments and use-cases. > I believe we need to have a use case that clearly demonstrates a need for a new mechanism. Just because we can do something in a protocol, does not mean we should do it. Andrew > > >> >>-minto=20 >> >>| >>|There is some discussion in Sec 4 of the draft along the lines I've just >>|highlighted. >>|Please let us know if there are more questions. >>| >>|Thanks, >>|Madhukar >>| >>| >>| >>|On 3/20/13 1:29 PM, "Minto Jeyananth" wrote: >>| >>|>Hi Authors, >>|> >>|>Expert from the draft >>|> >>|> "One of the implications of such busy periods of state restoration >>|in >>|> a process is that, the process may not be able to sustain the rate >>|of >>|> sending HELLOs across all its interfaces. In a controlled restart >>|> scenario (such as OSPF Graceful restart), the router is able to ask >>|> for a grace period by flooding out opaque LSAs indicating that it is >>|> restarting. In case of upgrades and restarts with state >>|restoration, >>|> (i.e., not involving a graceful restart), this is not possible." >>|> >>|>Does not it a pure implementation issue? Implementation could simply >>|>prevent such an unsupported configuration. >>|>With BFD does OSPF needs aggressive interval? >>|> >>|>Thanks >>|>-minto >>|> >>| > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From russw@riw.us Sat Mar 23 07:52:35 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA1721F86CA for ; Sat, 23 Mar 2013 07:52: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci52-sT4rDWb for ; Sat, 23 Mar 2013 07:52:34 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 66FC421F8648 for ; Sat, 23 Mar 2013 07:52:34 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=[192.168.100.52]) by da31.namelessnet.net with esmtpa (Exim 4.80) (envelope-from ) id 1UJPo7-0006Wn-9T for ospf@ietf.org; Sat, 23 Mar 2013 07:52:31 -0700 Message-ID: <514DC1BA.3090600@riw.us> Date: Sat, 23 Mar 2013 10:52:42 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ospf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [OSPF] Asymmetric OSPF Hold Timer draft X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 23 Mar 2013 14:52:35 -0000 > Although you are not advocating one solution over the other, you are > proposing to add a complication to an existing protocol to do something > that can be easily achieved with longer OSPF hello timer and short BFD > timer, that can be dynamically adapted during cases like ISSU for example. > So what is the value of introducing yet another thing to solve exactly > the same problem? I'm not certain about this, actually... Are there no use cases where: 1. BFD wouldn't be used anyway (just to take BFD out of the picture) 2. It's more important for one side to know about a down condition faster than the other side 3. It's important to reduce hello traffic and possible false negatives to a minimal amount? I keep thinking there's a possible use case in large scale hub and spoke networks around this work, specifically in cases where there is more traffic up towards the hub than down towards the spoke --so it's really important for the remote to know about a hub failure fast, but the timing on a hub knowing about a spoke failure can be relaxed. Not positing that this is an absolutely perfect case, just throwing the thought out there as a possibility. Another way to look at the problem is on the neighbor discovery side, rather than the failure side of things. Are there any instances where it's important for one OSPF router to learn about a bunch of other OSPF routers before launching into sending its own hellos on the link? Again, an example might be a large scale hub and spoke, or even some mobile ad hoc environments --and here you might actually be using BFD for fast down, combined with lazy asymmetric OSPF timers for what turns out to be more efficient and faster discovery. Again, I don't know for certain, just throwing it out as a discussion item. :-) Russ From andrew.dolganow@alcatel-lucent.com Sun Mar 24 03:04:57 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFB721F8AF8 for ; Sun, 24 Mar 2013 03:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nN5chs5KPJc for ; Sun, 24 Mar 2013 03:04:57 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1FD21F87D9 for ; Sun, 24 Mar 2013 03:04:57 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r2OA4tOL005267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 24 Mar 2013 05:04:56 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r2OA4tYx029601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 Mar 2013 06:04:55 -0400 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.201]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Sun, 24 Mar 2013 06:04:55 -0400 From: "Dolganow, Andrew (Andrew)" To: Russ White Thread-Topic: [OSPF] Asymmetric OSPF Hold Timer draft Thread-Index: Ac4lqavmp/Rfju5zQ5yDlADp+AxPdgAoR7GAAAT7SdD///VrgIABWAkAgAHkTgCAAP7eOA== Date: Sun, 24 Mar 2013 10:04:54 +0000 Message-ID: References: , <514DC1BA.3090600@riw.us> In-Reply-To: <514DC1BA.3090600@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Asymmetric OSPF Hold Timer draft X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 24 Mar 2013 10:04:57 -0000 Russ Inline Andrew Sent from my iPhone On 2013-03-23, at 3:52 PM, "Russ White" wrote: >=20 >> Although you are not advocating one solution over the other, you are >> proposing to add a complication to an existing protocol to do something >> that can be easily achieved with longer OSPF hello timer and short BFD >> timer, that can be dynamically adapted during cases like ISSU for exampl= e. >> So what is the value of introducing yet another thing to solve exactly >> the same problem? >=20 > I'm not certain about this, actually... Are there no use cases where: >=20 > 1. BFD wouldn't be used anyway (just to take BFD out of the picture) BFD was, among others, design for that. Removing it is bot an option in my = opinion. Operators tell us vendors to make cost-effective solutions, then r= equest functionality extensions that make control plane more complex becaus= e they try yo support today's best functionality without the tools invented= for this. I think expanding OSPF to support what we can do already is not = the right thing to do.=20 > 2. It's more important for one side to know about a down condition > faster than the other side > 3. It's important to reduce hello traffic and possible false negatives > to a minimal amount? >=20 > I keep thinking there's a possible use case in large scale hub and spoke > networks around this work, specifically in cases where there is more > traffic up towards the hub than down towards the spoke --so it's really > important for the remote to know about a hub failure fast, but the > timing on a hub knowing about a spoke failure can be relaxed. >=20 Or you can just have a hub router with enough power to handle a deployment = at scale needed.=20 Andrew > Not positing that this is an absolutely perfect case, just throwing the > thought out there as a possibility. >=20 > Another way to look at the problem is on the neighbor discovery side, > rather than the failure side of things. Are there any instances where > it's important for one OSPF router to learn about a bunch of other OSPF > routers before launching into sending its own hellos on the link? Again, > an example might be a large scale hub and spoke, or even some mobile ad > hoc environments --and here you might actually be using BFD for fast > down, combined with lazy asymmetric OSPF timers for what turns out to be > more efficient and faster discovery. >=20 > Again, I don't know for certain, just throwing it out as a discussion ite= m. >=20 > :-) >=20 > Russ >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From russw@riw.us Sun Mar 24 05:30:57 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BC221F8D23 for ; Sun, 24 Mar 2013 05:30:57 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvyzSnRVcPkw for ; Sun, 24 Mar 2013 05:30:57 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 67B7321F8D20 for ; Sun, 24 Mar 2013 05:30:57 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=[192.168.100.52]) by da31.namelessnet.net with esmtpa (Exim 4.80) (envelope-from ) id 1UJk4e-00037E-0C; Sun, 24 Mar 2013 05:30:56 -0700 Message-ID: <514EF208.4020303@riw.us> Date: Sun, 24 Mar 2013 08:31:04 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Dolganow, Andrew (Andrew)" References: , <514DC1BA.3090600@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "ospf@ietf.org" Subject: Re: [OSPF] Asymmetric OSPF Hold Timer draft X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 24 Mar 2013 12:30:58 -0000 > BFD was, among others, design for that. Removing it is bot an option in my opinion. Operators tell us vendors to make cost-effective solutions, then request functionality extensions that make control plane more complex because they try yo support today's best functionality without the tools invented for this. I think expanding OSPF to support what we can do already is not the right thing to do. My impression of this draft is that it's not about fast down detection (as BFD is), but asymmetric discovery speed to improve efficiency. Can you point me to the place in the BFD draft that covers this capability? The question isn't whether or not BFD can do this particular thing --the questions are: 1. Is this a reasonable thing to want to do? 2. Should we extend OSPF to do it? This isn't the BFD working group (?). :-) Russ From asmirnov@cisco.com Sun Mar 24 08:18:16 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EAC21F8B49 for ; Sun, 24 Mar 2013 08:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4aVl1r3FsJA for ; Sun, 24 Mar 2013 08:18:15 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3A73921F8A8E for ; Sun, 24 Mar 2013 08:18:15 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2OFI8d0019759; Sun, 24 Mar 2013 16:18:08 +0100 (CET) Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2OFHe9g009816; Sun, 24 Mar 2013 16:17:55 +0100 (CET) Message-ID: <514F1914.6070004@cisco.com> Date: Sun, 24 Mar 2013 16:17:40 +0100 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: Russ White References: , <514DC1BA.3090600@riw.us> <514EF208.4020303@riw.us> In-Reply-To: <514EF208.4020303@riw.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] Asymmetric OSPF Hold Timer draft X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 24 Mar 2013 15:18:16 -0000 Hi Russ, there is no harm in sending Hellos more frequently than advertised Hello interval. In other words, if you look at the problem from neighbor discovery angle alone (i.e. state that neighbor liveliness detection is offloaded from Hellos) then it is best to set Hello and Dead intervals to [near] infinity and send Hellos as dictated by other requirements. OSPF could send Hellos as fast or as infrequent as needed for neighbor discovery and efficiency; symmetric, asymmetric; behavior the same on connected routers or different etc. If implementation wants to do asymmetric neighbor discovery then this is doable within the scope of 2328. Anton On 03/24/2013 01:31 PM, Russ White wrote: >> BFD was, among others, design for that. Removing it is bot an option in my opinion. Operators tell us vendors to make cost-effective solutions, then request functionality extensions that make control plane more complex because they try yo support today's best functionality without the tools invented for this. I think expanding OSPF to support what we can do already is not the right thing to do. > > My impression of this draft is that it's not about fast down detection > (as BFD is), but asymmetric discovery speed to improve efficiency. Can > you point me to the place in the BFD draft that covers this capability? > > The question isn't whether or not BFD can do this particular thing --the > questions are: > > 1. Is this a reasonable thing to want to do? > 2. Should we extend OSPF to do it? > > This isn't the BFD working group (?). > > :-) > > Russ > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From wwwrun@rfc-editor.org Wed Mar 27 05:38:22 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0560E21F85F3 for ; Wed, 27 Mar 2013 05:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.65 X-Spam-Level: X-Spam-Status: No, score=-101.65 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZlOqvgV3eZB for ; Wed, 27 Mar 2013 05:38:21 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB7221F85ED for ; Wed, 27 Mar 2013 05:38:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EFE2DB1E002; Wed, 27 Mar 2013 05:37:52 -0700 (PDT) To: manav.bhatia@alcatel-lucent.com, vishwas.manral@hp.com, acee.lindem@ericsson.com, stbryant@cisco.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com From: RFC Errata System Message-Id: <20130327123752.EFE2DB1E002@rfc-editor.org> Date: Wed, 27 Mar 2013 05:37:52 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Technical Errata Reported] RFC6506 (3567) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 12:38:22 -0000 The following errata report has been submitted for RFC6506, "Supporting Authentication Trailer for OSPFv3". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6506&eid=3567 -------------------------------------- Type: Technical Reported by: Marek Karasek Section: 2.2 Original Text ------------- Consistent with OSPFv2 Cryptographic Authentication [RFC2328], both OSPFv3 header checksum calculation and verification are omitted when the OSPFv3 authentication mechanism described in this specification is used. Corrected Text -------------- OSPFv3 authentication mechanism provides capability to detect corruption of OSPFv3 packet, which is under non authenticated operation achieved using OSPFv3 header checksum [RFC 5340] and LLS data block checksum [RFC 5613]. In spirit of OSPFv2 Cryptographic Authentication [RFC2328], OSPFv3 header checksum and LLS Data Block Checksum calculation and verification are omitted when the OSPFv3 authentication mechanism described in this specification is used. Notes ----- RFC does not specify how to work with LLS Data Block Checksum. Errata suggests omit checksum calculation/verification in the same way like for OSPFv3 header checksum. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6506 (draft-ietf-ospf-auth-trailer-ospfv3-11) -------------------------------------- Title : Supporting Authentication Trailer for OSPFv3 Publication Date : February 2012 Author(s) : M. Bhatia, V. Manral, A. Lindem Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Mar 27 05:41:56 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653FE21F85F3 for ; Wed, 27 Mar 2013 05:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.84 X-Spam-Level: X-Spam-Status: No, score=-101.84 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-+7cNlQ2hJV for ; Wed, 27 Mar 2013 05:41:55 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E666A21F85E0 for ; Wed, 27 Mar 2013 05:41:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 71A73B1E002; Wed, 27 Mar 2013 05:41:27 -0700 (PDT) To: manav.bhatia@alcatel-lucent.com, vishwas.manral@hp.com, acee.lindem@ericsson.com, stbryant@cisco.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com From: RFC Errata System Message-Id: <20130327124127.71A73B1E002@rfc-editor.org> Date: Wed, 27 Mar 2013 05:41:27 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Technical Errata Reported] RFC6506 (3568) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 12:41:56 -0000 The following errata report has been submitted for RFC6506, "Supporting Authentication Trailer for OSPFv3". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6506&eid=3568 -------------------------------------- Type: Technical Reported by: Marek Karasek Section: 4.2 Original Text ------------- OSPFv3 Header Checksum Both OSPFv3 header checksum calculation and verification are omitted when the OSPFv3 authentication mechanism described in this specification is used. This implies: o For OSPFv3 packets to be transmitted, the OSPFv3 header checksum computation is omitted, and the OSPFv3 header checksum SHOULD be set to 0 prior to computation of the OSPFv3 Authentication Trailer message digest. o For received OSPFv3 packets including an OSPFv3 Authentication Trailer, OSPFv3 header checksum verification MUST be omitted. However, if the OSPFv3 packet does include a non-zero OSPFv3 header checksum, it will not be modified by the receiver and will simply be included in the OSPFv3 Authentication Trailer message digest verification. Corrected Text -------------- OSPFv3 Header Checksum and LLS Data Block Checksum OSPFv3 Header Checksum and LLS Data Block Checksum calculation and verification are omitted when the OSPFv3 authentication mechanism described in this specification is used. This implies: • For OSPFv3 packets to be transmitted, the OSPFv3 header checksum and LLS Data Block checksum computation is omitted, and the checksums SHOULD be set to 0 prior to computation of the OSPFv3 Authentication Trailer message digest. • For received OSPFv3 packets including an OSPFv3 Authentication Trailer, OSPFv3 header checksum and LLS Data Block checksum verification MUST be omitted. However, if the OSPFv3 packet does include a non-zero OSPFv3 header or LLS Data Block checksum, it will not be modified by the receiver and will simply be included in the OSPFv3 Authentication Trailer message digest verification. Notes ----- RFC does not specify how to work with LLS Data Block Checksum. Errata suggests omit checksum calculation/verification in the same way like for OSPFv3 header checksum. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6506 (draft-ietf-ospf-auth-trailer-ospfv3-11) -------------------------------------- Title : Supporting Authentication Trailer for OSPFv3 Publication Date : February 2012 Author(s) : M. Bhatia, V. Manral, A. Lindem Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From thiruma.valavan@outlook.com Thu Mar 28 11:58:05 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73CB21F8FD6 for ; Thu, 28 Mar 2013 11:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyIwSc651srZ for ; Thu, 28 Mar 2013 11:58:04 -0700 (PDT) Received: from bay0-omc4-s14.bay0.hotmail.com (bay0-omc4-s14.bay0.hotmail.com [65.54.190.216]) by ietfa.amsl.com (Postfix) with ESMTP id A873C21F8FD5 for ; Thu, 28 Mar 2013 11:58:04 -0700 (PDT) Received: from BAY002-W49 ([65.54.190.199]) by bay0-omc4-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Mar 2013 11:58:00 -0700 X-EIP: [jRfAMkxHze+P/fznpWWgLeR9Q2gYlfnc] X-Originating-Email: [thiruma.valavan@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_13230ea0-4b65-4aa7-9d7e-eb6eb4546078_" From: Thiruma valavan To: "ospf@ietf.org" Date: Fri, 29 Mar 2013 00:28:00 +0530 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 28 Mar 2013 18:58:00.0691 (UTC) FILETIME=[2B291C30:01CE2BE6] Subject: [OSPF] Forwarding address in Type-7 LSA X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2013 18:58:06 -0000 --_13230ea0-4b65-4aa7-9d7e-eb6eb4546078_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All=2C I had a doubt in forwarding address field in Type-7 LSA. what would be the forwarding address for below scenarios. R1 ---Area0-----R2(10.0.0.1/8)-------Area1 NSSA----------(10.0.0.2/8) R3(20= .0.0.1)---------------(20.0.0..2/8)R4(loopback0 - 100.0.0.1/32) Static route configured in R3 "ip route 100.0.0.0 255.255.255.255 20.0.0.2" 1.What would be forwarding address=2C when the nexthop interface of 100.0= .0.0/32 network is not added into OSPF NSSA Area-1 ?2.What would be forward= ing address=2C when the nexthop interface of 100.0.0.0/32 network is adde= d into OSPF NSSA Area-1 through network command and the interface is not p= assive ?3.What would be forwarding address=2C when the nexthop interface o= f 100.0.0.0/32 network is added into OSPF NSSA Area-1 through network comm= and and the interface is not passive ? I have seen three different address = in above scenarios. Please help me to understand this.=20 Thanks & Regards=2CThirumavalavan P = --_13230ea0-4b65-4aa7-9d7e-eb6eb4546078_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All=2C

I had a doubt in forwarding address field in Type-7 LSA.=
wh= at would be the forwarding address for below scenarios.

R1 ---Area0-----R2(10.= 0.0.1/8)-------Area1 NSSA----------(10.0.0.2/8) R3(20.0.0.1)---------------= (20.0.0..2/8)R4(loopback0 - 100.0.0.1/32)

Static route configure= d in R3 "ip route 100.0.0.0 255.255.255.255 20.0.0.2"
=
1.What would be forwardi= ng address=2C when the  =3Bnexthop  =3Binterface of 100.0.0.0/32 ne= twork is not added into OSPF NSSA Area-1 ?
2.Wha= t would be forwarding address=2C when the  =3Bnexthop  =3Binterface= of 100.0.0.0/32 network is added into OSPF NSSA Area-1  =3Bthrough net= work command and the interface is not passive ?
3.What would be forwarding address=2C when t= he  =3Bnexthop interface of 100.0.0.0/32 network is added into OSPF NSS= A Area-1  =3Bthrough network command and the interface is not passive ?=
 =3B
I have seen three different address in above scenarios.= Please help me to understand this. =3B

Thanks &=3B Regards=2C
Thirumavalavan P



= --_13230ea0-4b65-4aa7-9d7e-eb6eb4546078_-- From thiruma.valavan@outlook.com Thu Mar 28 12:48:24 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0904021F8E8F for ; Thu, 28 Mar 2013 12:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDNUXt1sNRZY for ; Thu, 28 Mar 2013 12:48:23 -0700 (PDT) Received: from bay0-omc4-s19.bay0.hotmail.com (bay0-omc4-s19.bay0.hotmail.com [65.54.190.221]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCED21F8F86 for ; Thu, 28 Mar 2013 12:48:23 -0700 (PDT) Received: from BAY002-W58 ([65.54.190.200]) by bay0-omc4-s19.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Mar 2013 12:48:23 -0700 X-EIP: [08ghX4HRmS9ed4tLrSoaoZcWun0f9n2C] X-Originating-Email: [thiruma.valavan@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_927b8d6b-436c-4ec7-b8f8-95e6b38b52d6_" From: Thiruma valavan To: "ospf@ietf.org" Date: Fri, 29 Mar 2013 01:18:23 +0530 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 28 Mar 2013 19:48:23.0418 (UTC) FILETIME=[34D8A5A0:01CE2BED] Subject: Re: [OSPF] OSPF Digest, Vol 85, Issue 10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2013 19:48:24 -0000 --_927b8d6b-436c-4ec7-b8f8-95e6b38b52d6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see the corrected sentence=2C 3.What would be forwarding address=2C when the nexthop interface of 100.0.0= .0/32 network is added into OSPF NSSA Area-1 through network command and th= e interface is passive ? Thanks & Regards=2CThirumavalavan P > From: ospf-request@ietf.org > Subject: OSPF Digest=2C Vol 85=2C Issue 10 > To: ospf@ietf.org > Date: Thu=2C 28 Mar 2013 12:00:18 -0700 >=20 > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so=2C go to=20 >=20 > https://www.ietf.org/mailman/listinfo/ospf >=20 > Click the 'Unsubscribe or edit options' button=2C log in=2C and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send OSPF mailing list submissions to > ospf@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web=2C visit > https://www.ietf.org/mailman/listinfo/ospf > or=2C via email=2C send a message with subject or body 'help' to > ospf-request@ietf.org >=20 > You can reach the person managing the list at > ospf-owner@ietf.org >=20 > When replying=2C please edit your Subject line so it is more specific > than "Re: Contents of OSPF digest..." >=20 >=20 > Today's Topics: >=20 > 1. Forwarding address in Type-7 LSA (Thiruma valavan) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Fri=2C 29 Mar 2013 00:28:00 +0530 > From: Thiruma valavan > To: "ospf@ietf.org" > Subject: [OSPF] Forwarding address in Type-7 LSA > Message-ID: > Content-Type: text/plain=3B charset=3D"iso-8859-1" >=20 > Hi All=2C > I had a doubt in forwarding address field in Type-7 LSA. > what would be the forwarding address for below scenarios. > R1 ---Area0-----R2(10.0.0.1/8)-------Area1 NSSA----------(10.0.0.2/8) R3(= 20.0.0.1)---------------(20.0.0..2/8)R4(loopback0 - 100.0.0.1/32) > Static route configured in R3 "ip route 100.0.0.0 255.255.255.255 20.0.0.= 2" > 1.What would be forwarding address=2C when the nexthop interface of 100= .0.0.0/32 network is not added into OSPF NSSA Area-1 ?2.What would be forwa= rding address=2C when the nexthop interface of 100.0.0.0/32 network is ad= ded into OSPF NSSA Area-1 through network command and the interface is not= passive ?3.What would be forwarding address=2C when the nexthop interface= of 100.0.0.0/32 network is added into OSPF NSSA Area-1 through network co= mmand and the interface is not passive ? I have seen three different addres= s in above scenarios. Please help me to understand this.=20 > Thanks & Regards=2CThirumavalavan P >=20 >=20 > =20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: >=20 > ------------------------------ >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 >=20 > End of OSPF Digest=2C Vol 85=2C Issue 10 > ************************************ = --_927b8d6b-436c-4ec7-b8f8-95e6b38b52d6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Please see the corrected se= ntence=2C

3.What would be forwarding address=2C when th= e nexthop interface of 100.0.0.0/32 network is added into OSPF NSSA Area-1 = through network command and the interface is passive ?


Thanks &=3B Regards=2C
Thirumavalavan P

=
>=3B From: ospf-request@ie= tf.org
>=3B Subject: OSPF Digest=2C Vol 85=2C Issue 10
>=3B To: o= spf@ietf.org
>=3B Date: Thu=2C 28 Mar 2013 12:00:18 -0700
>=3B >=3B If you have received this digest without all the individual messag= e
>=3B attachments you will need to update your digest options in your= list
>=3B subscription. To do so=2C go to
>=3B
>=3B http= s://www.ietf.org/mailman/listinfo/ospf
>=3B
>=3B Click the 'Unsu= bscribe or edit options' button=2C log in=2C and set "Get
>=3B MIME or= Plain Text Digests?" to MIME. You can set this option
>=3B globally = for all the list digests you receive at this point.
>=3B
>=3B >=3B
>=3B Send OSPF mailing list submissions to
>=3B ospf@i= etf.org
>=3B
>=3B To subscribe or unsubscribe via the World Wide= Web=2C visit
>=3B https://www.ietf.org/mailman/listinfo/ospf
>= =3B or=2C via email=2C send a message with subject or body 'help' to
>= =3B ospf-request@ietf.org
>=3B
>=3B You can reach the person ma= naging the list at
>=3B ospf-owner@ietf.org
>=3B
>=3B When= replying=2C please edit your Subject line so it is more specific
>=3B= than "Re: Contents of OSPF digest..."
>=3B
>=3B
>=3B Toda= y's Topics:
>=3B
>=3B 1. Forwarding address in Type-7 LSA (T= hiruma valavan)
>=3B
>=3B
>=3B ---------------------------= -------------------------------------------
>=3B
>=3B Message: 1=
>=3B Date: Fri=2C 29 Mar 2013 00:28:00 +0530
>=3B From: Thiruma = valavan <=3Bthiruma.valavan@outlook.com>=3B
>=3B To: "ospf@ietf.or= g" <=3Bospf@ietf.org>=3B
>=3B Subject: [OSPF] Forwarding address i= n Type-7 LSA
>=3B Message-ID: <=3BBAY002-W49BDCDBFBCD07E0E7D35A5EFD2= 0@phx.gbl>=3B
>=3B Content-Type: text/plain=3B charset=3D"iso-8859-1= "
>=3B
>=3B Hi All=2C
>=3B I had a doubt in forwarding addr= ess field in Type-7 LSA.
>=3B what would be the forwarding address for= below scenarios.
>=3B R1 ---Area0-----R2(10.0.0.1/8)-------Area1 NSSA= ----------(10.0.0.2/8) R3(20.0.0.1)---------------(20.0.0..2/8)R4(loopback0= - 100.0.0.1/32)
>=3B Static route configured in R3 "ip route 100.0.0.= 0 255.255.255.255 20.0.0.2"
>=3B 1.What would be forwarding address=2C= when the nexthop interface of 100.0.0.0/32 network is not added into OSP= F NSSA Area-1 ?2.What would be forwarding address=2C when the nexthop int= erface of 100.0.0.0/32 network is added into OSPF NSSA Area-1 through netw= ork command and the interface is not passive ?3.What would be forwarding ad= dress=2C when the nexthop interface of 100.0.0.0/32 network is added into = OSPF NSSA Area-1 through network command and the interface is not passive = ? I have seen three different address in above scenarios. Please help me to= understand this.
>=3B Thanks &=3B Regards=2CThirumavalavan P
&= gt=3B
>=3B
>=3B
>=3B -------------- next part= --------------
>=3B An HTML attachment was scrubbed...
>=3B URL:= <=3Bhttp://www.ietf.org/mail-archive/web/ospf/attachments/20130329/32dac= 3da/attachment.htm>=3B
>=3B
>=3B -----------------------------= -
>=3B
>=3B _______________________________________________
&= gt=3B OSPF mailing list
>=3B OSPF@ietf.org
>=3B https://www.ietf.= org/mailman/listinfo/ospf
>=3B
>=3B
>=3B End of OSPF Diges= t=2C Vol 85=2C Issue 10
>=3B ************************************
<= /div>
= --_927b8d6b-436c-4ec7-b8f8-95e6b38b52d6_-- From ietfc@btconnect.com Fri Mar 29 14:15:07 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111B221F9025 for ; Fri, 29 Mar 2013 14:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsSthHHa-ivv for ; Fri, 29 Mar 2013 14:15:02 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id B5F1E21F9023 for ; Fri, 29 Mar 2013 14:15:02 -0700 (PDT) Received: from mail184-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Mar 2013 21:15:01 +0000 Received: from mail184-tx2 (localhost [127.0.0.1]) by mail184-tx2-R.bigfish.com (Postfix) with ESMTP id A7F97220179; Fri, 29 Mar 2013 21:15:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz9371I542I1432Izz1f42h1fc6h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah19a27bh172cdfh8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah304l1155h) Received: from mail184-tx2 (localhost.localdomain [127.0.0.1]) by mail184-tx2 (MessageSwitch) id 1364591700357098_8908; Fri, 29 Mar 2013 21:15:00 +0000 (UTC) Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.250]) by mail184-tx2.bigfish.com (Postfix) with ESMTP id 438F7340084; Fri, 29 Mar 2013 21:15:00 +0000 (UTC) Received: from DB3PRD0711HT003.eurprd07.prod.outlook.com (157.56.254.197) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Mar 2013 21:14:59 +0000 Received: from AMXPRD0310HT001.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.183.36) with Microsoft SMTP Server (TLS) id 14.16.263.1; Fri, 29 Mar 2013 21:14:57 +0000 Message-ID: <018b01ce2cc1$dd8defa0$4001a8c0@gateway.2wire.net> From: t.petch To: , , References: <20130327123752.EFE2DB1E002@rfc-editor.org> Date: Fri, 29 Mar 2013 21:10:28 +0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-OriginatorOrg: btconnect.com Cc: ospf@ietf.org Subject: Re: [OSPF] [Technical Errata Reported] RFC6506 (3567) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Mar 2013 21:15:07 -0000 Looks like a functional change to me. Tom Petch ----- Original Message ----- From: "RFC Errata System" To: ; ; ; ; ; ; Cc: ; Sent: Wednesday, March 27, 2013 12:37 PM > The following errata report has been submitted for RFC6506, > "Supporting Authentication Trailer for OSPFv3". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6506&eid=3567 > > -------------------------------------- > Type: Technical > Reported by: Marek Karasek > > Section: 2.2 > > Original Text > ------------- > Consistent with OSPFv2 Cryptographic Authentication [RFC2328], both > OSPFv3 header checksum calculation and verification are omitted when > the OSPFv3 authentication mechanism described in this specification > is used. > > > Corrected Text > -------------- > OSPFv3 authentication mechanism provides capability to detect corruption of > OSPFv3 packet, which is under non authenticated operation achieved using OSPFv3 > header checksum [RFC 5340] and LLS data block checksum [RFC 5613]. In spirit of > OSPFv2 Cryptographic Authentication [RFC2328], OSPFv3 header checksum and LLS > Data Block Checksum calculation and verification are omitted when the OSPFv3 > authentication mechanism described in this specification is used. > > Notes > ----- > RFC does not specify how to work with LLS Data Block Checksum. Errata suggests omit checksum calculation/verification in the same way like for OSPFv3 header checksum. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6506 (draft-ietf-ospf-auth-trailer-ospfv3-11) > -------------------------------------- > Title : Supporting Authentication Trailer for OSPFv3 > Publication Date : February 2012 > Author(s) : M. Bhatia, V. Manral, A. Lindem > Category : PROPOSED STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG > From mkarasek@cisco.com Fri Mar 29 15:10:28 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC0821F9015 for ; Fri, 29 Mar 2013 15:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMWBcnA+ZkXo for ; Fri, 29 Mar 2013 15:10:26 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BAE3721F900F for ; Fri, 29 Mar 2013 15:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3637; q=dns/txt; s=iport; t=1364595026; x=1365804626; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=unJE8euaLjSSxur2ipFgVQlrwanu3l6DHRcpuACzTCY=; b=lFzwnfYUZ7tXydMypAEFQ71Qj9s4vXIB01fbZFP+LTqEg1Q6vM2a+1UW ObEvDMR9Mx0jNy1t410k2PO7H4VfOSLwAnY5zEO+dC0SHkx3j3O2+4Nvg Xx3vAMQqfBpQrm2hkw3g030em+nI+WMlf+yH8LmGy+tlgUZPQkDKWCvwX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANIPVlGtJXG+/2dsb2JhbAApGoM6vz6BChZ0gh8BAQEDAQEBATc0CwUHBAIBCBEEAQELFAkHJwsUCQgCBAENBQiIBgYMLr9ejVqBHCYLBwaCWWEDp3aDC3qBLg X-IronPort-AV: E=Sophos;i="4.87,375,1363132800"; d="scan'208";a="190051308" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 29 Mar 2013 22:10:21 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2TMALF5002693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Mar 2013 22:10:21 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.206]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Fri, 29 Mar 2013 17:10:21 -0500 From: "Marek Karasek (mkarasek)" To: "t.petch" , "manav.bhatia@alcatel-lucent.com" , "vishwas.manral@hp.com" , "acee.lindem@ericsson.com" Thread-Topic: [OSPF] [Technical Errata Reported] RFC6506 (3567) Thread-Index: AQHOKuf5RpxnQnNRs0eE494S+KVBBJi9LzO4gAAFwmA= Date: Fri, 29 Mar 2013 22:10:21 +0000 Message-ID: References: <20130327123752.EFE2DB1E002@rfc-editor.org> <018b01ce2cc1$dd8defa0$4001a8c0@gateway.2wire.net> In-Reply-To: <018b01ce2cc1$dd8defa0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.25.122] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] [Technical Errata Reported] RFC6506 (3567) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Mar 2013 22:10:28 -0000 Hi Tom, RFC 6506 specifies how to work with OSPFv3 header checksum, but does not sp= ecify how to work with LLS data block checksum. For interoperability reason= s it would be very useful if it's documented. There are basically only two options: a) compute LLS checksum as usual b) omit, like for OSPFv3 Header checksum Errata suggests b) because I do not see why to authenticate portion of pack= et 2x. It may be seen as operational change if there's some implementation doing a= ). Are you aware of any? Thanks marek -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of t.p= etch Sent: Friday, March 29, 2013 10:10 PM To: manav.bhatia@alcatel-lucent.com; vishwas.manral@hp.com; acee.lindem@eri= csson.com Cc: ospf@ietf.org Subject: Re: [OSPF] [Technical Errata Reported] RFC6506 (3567) Looks like a functional change to me. Tom Petch ----- Original Message ----- From: "RFC Errata System" To: ; ; ; ; ; ; Cc: ; Sent: Wednesday, March 27, 2013 12:37 PM > The following errata report has been submitted for RFC6506,=20 > "Supporting Authentication Trailer for OSPFv3". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6506&eid=3D3567 > > -------------------------------------- > Type: Technical > Reported by: Marek Karasek > > Section: 2.2 > > Original Text > ------------- > Consistent with OSPFv2 Cryptographic Authentication [RFC2328], both > OSPFv3 header checksum calculation and verification are omitted when > the OSPFv3 authentication mechanism described in this specification > is used. > > > Corrected Text > -------------- > OSPFv3 authentication mechanism provides capability to detect corruption of > OSPFv3 packet, which is under non authenticated operation achieved using OSPFv3 > header checksum [RFC 5340] and LLS data block checksum [RFC 5613]. In spirit of > OSPFv2 Cryptographic Authentication [RFC2328], OSPFv3 header checksum and LLS > Data Block Checksum calculation and verification are omitted when the OSPFv3 > authentication mechanism described in this specification is used. > > Notes > ----- > RFC does not specify how to work with LLS Data Block Checksum. Errata suggests omit checksum calculation/verification in the same way like for OSPFv3 header checksum. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please=20 > use "Reply All" to discuss whether it should be verified or rejected.=20 > When a decision is reached, the verifying party (IESG) can log in to=20 > change the status and edit the report, if necessary. > > -------------------------------------- > RFC6506 (draft-ietf-ospf-auth-trailer-ospfv3-11) > -------------------------------------- > Title : Supporting Authentication Trailer for OSPFv3 > Publication Date : February 2012 > Author(s) : M. Bhatia, V. Manral, A. Lindem > Category : PROPOSED STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Sat Mar 30 22:25:45 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D95921F86A5 for ; Sat, 30 Mar 2013 22:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTmay5OYM+fl for ; Sat, 30 Mar 2013 22:25:44 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 02C5021F85F5 for ; Sat, 30 Mar 2013 22:25:36 -0700 (PDT) Received: from sg70xusmtp01.zap.alcatel-lucent.com (h135-253-72-129.lucent.com [135.253.72.129]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r2V5PQdU011363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 31 Mar 2013 00:25:28 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by sg70xusmtp01.zap.alcatel-lucent.com (GMO) with ESMTP id r2V5POAp031779 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Sun, 31 Mar 2013 13:25:24 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Sun, 31 Mar 2013 10:55:24 +0530 From: "Bhatia, Manav (Manav)" To: "vishwas.manral@hp.com" , "acee.lindem@ericsson.com" , "stbryant@cisco.com" , "adrian@olddog.co.uk" , "akr@cisco.com" , "acee.lindem@ericsson.com" Date: Sun, 31 Mar 2013 10:55:21 +0530 Thread-Topic: [Technical Errata Reported] RFC6506 (3567) Thread-Index: Ac4q5/xtH+FE9F0uT1yiTh5NjXuPXQC5ZgBw Message-ID: <7C362EEF9C7896468B36C9B79200D8351BCAF79C88@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20130327123752.EFE2DB1E002@rfc-editor.org> In-Reply-To: <20130327123752.EFE2DB1E002@rfc-editor.org> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "ospf@ietf.org" Subject: Re: [OSPF] [Technical Errata Reported] RFC6506 (3567) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 31 Mar 2013 05:25:45 -0000 Hi Marek, When constructing the LLS data block it may not always be possible for an i= mplementation to know whether there is authentication being used on a link = or not. Sure there are ways for us to figure this out but it may not be a v= ery modular approach (really an implementation specific issue). If you follow rfc 6506 and do as it says then you can always choose NOT to = verify the LLS checksum upon reciept and still be compliant to 6506. This way nothing changes - Your original code for LLS still computes the ch= ecksum regardless of whether OSPFv3 AT is configured or not. The AT code co= mputes the digest of the packet including the LLS data block. The reciever verifies the AT data block and accepts the packet if it matche= s with whats carried in the packet. Its now an implementation specific issu= e whether it wants to verify the LLS checksum or not. Given this I don't think the errata raised is correct - more so, because th= is isnt really an error in the RFC.=20 Even if we'd discussed this issue when we were writing this RFC we would ha= ve left it as an implementation specific behavior at the RX side based on t= he modularity argument. Based on this argument I would also reject the errata 3568 that has been ra= ised.=20 Cheers, Manav > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 > Sent: Wednesday, March 27, 2013 6:08 PM > To: Bhatia, Manav (Manav); vishwas.manral@hp.com;=20 > acee.lindem@ericsson.com; stbryant@cisco.com;=20 > adrian@olddog.co.uk; akr@cisco.com; acee.lindem@ericsson.com > Cc: mkarasek@cisco.com; ospf@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC6506 (3567) >=20 > The following errata report has been submitted for RFC6506,=20 > "Supporting Authentication Trailer for OSPFv3". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6506&eid=3D3567 >=20 > -------------------------------------- > Type: Technical > Reported by: Marek Karasek >=20 > Section: 2.2 >=20 > Original Text > ------------- > Consistent with OSPFv2 Cryptographic Authentication=20 > [RFC2328], both OSPFv3 header checksum calculation and=20 > verification are omitted when the OSPFv3 authentication=20 > mechanism described in this specification is used.=20 >=20 > Corrected Text > -------------- > OSPFv3 authentication mechanism provides capability to detect=20 > corruption of OSPFv3 packet, which is under non authenticated=20 > operation achieved using OSPFv3 header checksum [RFC 5340]=20 > and LLS data block checksum [RFC 5613]. In spirit of OSPFv2=20 > Cryptographic Authentication [RFC2328], OSPFv3 header=20 > checksum and LLS Data Block Checksum calculation and=20 > verification are omitted when the OSPFv3 authentication=20 > mechanism described in this specification is used. >=20 > Notes > ----- > RFC does not specify how to work with LLS Data Block=20 > Checksum. Errata suggests omit checksum=20 > calculation/verification in the same way like for OSPFv3=20 > header checksum. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary,=20 > please use "Reply All" to discuss whether it should be=20 > verified or rejected. When a decision is reached, the=20 > verifying party (IESG) can log in to change the status and=20 > edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6506 (draft-ietf-ospf-auth-trailer-ospfv3-11) > -------------------------------------- > Title : Supporting Authentication Trailer for OSPFv3 > Publication Date : February 2012 > Author(s) : M. Bhatia, V. Manral, A. Lindem > Category : PROPOSED STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG > = From michael_barnes@usa.net Sun Mar 31 11:48:56 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B22621F862B for ; Sun, 31 Mar 2013 11:48:56 -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=[RCVD_NUMERIC_HELO=2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2yz+nQN5faS for ; Sun, 31 Mar 2013 11:48:48 -0700 (PDT) Received: from co03.mbox.net (co03.mbox.net [165.212.64.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0F221F8518 for ; Sun, 31 Mar 2013 11:48:45 -0700 (PDT) Received: from co03.mbox.net (localhost [127.0.0.1]) by co03.mbox.net (Postfix) with ESMTP id 3Zf5LN2lhKzvWs4; Sun, 31 Mar 2013 18:48:44 +0000 (UTC) X-USANET-Received: from co03.mbox.net [127.0.0.1] by co03.mbox.net via mtad (C8.MAIN.3.82G) with ESMTP id 472RcEsWO4528M03; Sun, 31 Mar 2013 18:48:40 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus X-USANET-GWS2-Tagid: UNKN Received: from ca33.cms.usa.net [165.212.11.133] by co03.mbox.net via smtad (C8.MAIN.3.89G) with ESMTP id XID476RcEsWO0128X03; Sun, 31 Mar 2013 18:48:40 -0000 X-USANET-Source: 165.212.11.133 OUT michael_barnes@usa.net ca33.cms.usa.net X-USANET-MsgId: XID476RcEsWO0128X03 Received: from web08.cms.usa.net [165.212.8.208] by ca33.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.82G) with ESMTP id 096RcEsWO9008M33; Sun, 31 Mar 2013 18:48:40 -0000 X-USANET-Auth: 165.212.8.208 AUTO michael_barnes@usa.net web08.cms.usa.net Received: from 173.22.132.108 [173.22.132.108] by web08.cms.usa.net (USANET web-mailer C8.MAIN.3.88W); Sun, 31 Mar 2013 18:48:39 -0000 Date: Sun, 31 Mar 2013 11:48:39 -0700 From: "Michael Barnes" To: "Bhatia, Manav (Manav)" , "vishwas.manral@hp.com" , "acee.lindem@ericsson.com" , "stbryant@cisco.com" , "adrian@olddog.co.uk" , "akr@cisco.com" , "acee.lindem@ericsson.com" X-Mailer: USANET web-mailer (C8.MAIN.3.88W) Mime-Version: 1.0 Message-ID: <573RcEsvn3424S08.1364755719@web08.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID096RcEsWO9008X33 Cc: "ospf@ietf.org" Subject: Re: [OSPF] [Technical Errata Reported] RFC6506 (3567) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 31 Mar 2013 18:48:56 -0000 Hi Manav, For OSPFv2, when cryptographic authentication is being used the LLS check= sum is not calculated (RFC5613 section 2.2). I've never heard of anyone havin= g a problem knowing that CA was being used on the interface before the LLS checksum was calculated. I think that OSPFv3 should be equivalent to OSPF= v2 in this regard. In any case, I think that RFC6506 should have specified how the LLS check= sum would be handled. Obviously there are differing opinions and when you lea= ve something like this undefined it can lead to interoperability issues. = Regards, Michael ------ Original Message ------ Received: Sat, 30 Mar 2013 10:25:59 PM PDT From: "Bhatia, Manav (Manav)" To: "vishwas.manral@hp.com" , "acee.lindem@ericsson.com" , "stbryant@cisco.co= m" , "adrian@olddog.co.uk" , "akr@cisco.com" , "acee.lindem@ericsson.com" Cc: "ospf@ietf.org" Subject: Re: [OSPF] [Technical Errata Reported] RFC6506 (3567) > Hi Marek, > = > When constructing the LLS data block it may not always be possible for = an implementation to know whether there is authentication being used on a li= nk or not. Sure there are ways for us to figure this out but it may not be a ve= ry modular approach (really an implementation specific issue). > = > If you follow rfc 6506 and do as it says then you can always choose NOT= to verify the LLS checksum upon reciept and still be compliant to 6506. > = > This way nothing changes - Your original code for LLS still computes th= e checksum regardless of whether OSPFv3 AT is configured or not. The AT cod= e computes the digest of the packet including the LLS data block. > = > The reciever verifies the AT data block and accepts the packet if it ma= tches with whats carried in the packet. Its now an implementation specific issu= e whether it wants to verify the LLS checksum or not. > = > Given this I don't think the errata raised is correct - more so, becaus= e this isnt really an error in the RFC. = > = > Even if we'd discussed this issue when we were writing this RFC we woul= d have left it as an implementation specific behavior at the RX side based = on the modularity argument. > = > Based on this argument I would also reject the errata 3568 that has bee= n raised. = > = > Cheers, Manav > = > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] = > > Sent: Wednesday, March 27, 2013 6:08 PM > > To: Bhatia, Manav (Manav); vishwas.manral@hp.com; = > > acee.lindem@ericsson.com; stbryant@cisco.com; = > > adrian@olddog.co.uk; akr@cisco.com; acee.lindem@ericsson.com > > Cc: mkarasek@cisco.com; ospf@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC6506 (3567) > > = > > The following errata report has been submitted for RFC6506, = > > "Supporting Authentication Trailer for OSPFv3". > > = > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D6506&eid=3D3567 > > = > > -------------------------------------- > > Type: Technical > > Reported by: Marek Karasek > > = > > Section: 2.2 > > = > > Original Text > > ------------- > > Consistent with OSPFv2 Cryptographic Authentication = > > [RFC2328], both OSPFv3 header checksum calculation and = > > verification are omitted when the OSPFv3 authentication = > > mechanism described in this specification is used. = > > = > > Corrected Text > > -------------- > > OSPFv3 authentication mechanism provides capability to detect = > > corruption of OSPFv3 packet, which is under non authenticated = > > operation achieved using OSPFv3 header checksum [RFC 5340] = > > and LLS data block checksum [RFC 5613]. In spirit of OSPFv2 = > > Cryptographic Authentication [RFC2328], OSPFv3 header = > > checksum and LLS Data Block Checksum calculation and = > > verification are omitted when the OSPFv3 authentication = > > mechanism described in this specification is used. > > = > > Notes > > ----- > > RFC does not specify how to work with LLS Data Block = > > Checksum. Errata suggests omit checksum = > > calculation/verification in the same way like for OSPFv3 = > > header checksum. > > = > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, = > > please use "Reply All" to discuss whether it should be = > > verified or rejected. When a decision is reached, the = > > verifying party (IESG) can log in to change the status and = > > edit the report, if necessary. = > > = > > -------------------------------------- > > RFC6506 (draft-ietf-ospf-auth-trailer-ospfv3-11) > > -------------------------------------- > > Title : Supporting Authentication Trailer for OSPFv3 > > Publication Date : February 2012 > > Author(s) : M. Bhatia, V. Manral, A. Lindem > > Category : PROPOSED STANDARD > > Source : Open Shortest Path First IGP > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > = > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf