From wwwrun@rfc-editor.org Tue Nov 2 08:53:13 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95E73A69D5 for ; Tue, 2 Nov 2010 08:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.1 X-Spam-Level: X-Spam-Status: No, score=-101.1 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6NwEp3--4b0 for ; Tue, 2 Nov 2010 08:53:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 383863A696D for ; Tue, 2 Nov 2010 08:53:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C350CE06B7; Tue, 2 Nov 2010 08:53:16 -0700 (PDT) To: mukesh.gupta@tropos.com, nmelam@juniper.net, stbryant@cisco.com, adrian.farrel@huawei.com, acee@redback.com, akr@cisco.com From: RFC Errata System Message-Id: <20101102155316.C350CE06B7@rfc-editor.org> Date: Tue, 2 Nov 2010 08:53:16 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org, john.w.obrien@lmco.com Subject: [OSPF] [Technical Errata Reported] RFC4552 (2599) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 15:53:13 -0000 The following errata report has been submitted for RFC4552, "Authentication/Confidentiality for OSPFv3". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4552&eid=2599 -------------------------------------- Type: Technical Reported by: John W. O'Brien Section: 3 Original Text ------------- In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH. Corrected Text -------------- In order to provide authentication to OSPFv3, implementations MUST support AH and MAY support ESP. Notes ----- Authentication can be provided by an implementation that supports AH only. 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. -------------------------------------- RFC4552 (draft-ietf-ospf-ospfv3-auth-08) -------------------------------------- Title : Authentication/Confidentiality for OSPFv3 Publication Date : June 2006 Author(s) : M. Gupta, N. Melam Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From vishwas.ietf@gmail.com Tue Nov 2 17:05:12 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC7F3A6A30 for ; Tue, 2 Nov 2010 17:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLerzfFIYPhX for ; Tue, 2 Nov 2010 17:05:11 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 0958E28C0E4 for ; Tue, 2 Nov 2010 17:05:10 -0700 (PDT) Received: by vws3 with SMTP id 3so346189vws.31 for ; Tue, 02 Nov 2010 17:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XZidFKYOYoMYOYQYP7F1fSvi8siPbdxftklTfYyFlto=; b=NHHmKUsmaw/cNOor973uIF5r5OT+fHplzD6vgd8fySbOwtf8FrxGruZrCEwoGRr0A0 DTP2WCSy1eeHR3uk524z1HkZQFKpwnQ/nhT1f/IfwSJnFpqvvX4vN8tU2/eJbXCjS77O HdAaX8/4L6EAg4HeNZI3PyltuUXDAXt4mlFzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=A4z/M1j60PjcoQYAtT83TAENiFDHG4cd1qWZI07nKWAAJ7/4IjSTB7LX+0nVs7Fsl4 QtaIRapn5OCs4DQOwoZn7KTrFK9By4SFEz2SxHnMQ6JSC1IjVb7D+DGDyOBgcCr+mccl +ZQn3x5KNNOy4mT+4tKSeI7MoIUpPKzFr1qXo= MIME-Version: 1.0 Received: by 10.224.193.194 with SMTP id dv2mr35235qab.192.1288742716111; Tue, 02 Nov 2010 17:05:16 -0700 (PDT) Received: by 10.229.65.93 with HTTP; Tue, 2 Nov 2010 17:05:16 -0700 (PDT) In-Reply-To: <20101102155316.C350CE06B7@rfc-editor.org> References: <20101102155316.C350CE06B7@rfc-editor.org> Date: Tue, 2 Nov 2010 17:05:16 -0700 Message-ID: From: Vishwas Manral To: RFC Errata System Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: john.w.obrien@lmco.com, mukesh.gupta@tropos.com, ospf@ietf.org, adrian.farrel@huawei.com, acee@redback.com, nmelam@juniper.net Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 00:05:12 -0000 Hi, This errata is wrong. ESP provides authentication as well as confidentiality, have a look at RFC 4301. Thanks, Vishwas On Tue, Nov 2, 2010 at 8:53 AM, RFC Errata System wrote: > > The following errata report has been submitted for RFC4552, > "Authentication/Confidentiality for OSPFv3". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4552&eid=3D2599 > > -------------------------------------- > Type: Technical > Reported by: John W. O'Brien > > Section: 3 > > Original Text > ------------- > In order to provide authentication to OSPFv3, implementations MUST suppor= t ESP and MAY support AH. > > > Corrected Text > -------------- > In order to provide authentication to OSPFv3, implementations MUST suppor= t AH and MAY support ESP. > > Notes > ----- > Authentication can be provided by an implementation that supports AH only= . > > 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. > > -------------------------------------- > RFC4552 (draft-ietf-ospf-ospfv3-auth-08) > -------------------------------------- > Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Authentication/Confidentiality for OS= PFv3 > Publication Date =A0 =A0: June 2006 > Author(s) =A0 =A0 =A0 =A0 =A0 : M. Gupta, N. Melam > Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD > Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Open Shortest Path First IGP > Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing > Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF > Verifying Party =A0 =A0 : IESG > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From acee.lindem@ericsson.com Wed Nov 3 08:50:24 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3CB28C0CF for ; Wed, 3 Nov 2010 08:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eikvO0iUaUoH for ; Wed, 3 Nov 2010 08:50:23 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id C843C3A69B8 for ; Wed, 3 Nov 2010 08:50:22 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oA3GBxUL005981; Wed, 3 Nov 2010 11:12:00 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 3 Nov 2010 11:50:06 -0400 From: Acee Lindem To: Vishwas Manral Date: Wed, 3 Nov 2010 11:50:04 -0400 Thread-Topic: [OSPF] [Technical Errata Reported] RFC4552 (2599) Thread-Index: Act7bsi7LAUlUR+CQ1mzBmwaSZH9Wg== Message-ID: <66BC910D-6839-4C94-967C-B614864ECAB6@ericsson.com> References: <20101102155316.C350CE06B7@rfc-editor.org> In-Reply-To: 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 Cc: "acee@redback.com" , "ospf@ietf.org" , "adrian.farrel@huawei.com" , "mukesh.gupta@tropos.com" , "nmelam@juniper.net" , RFC Errata System Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 15:50:24 -0000 Hi Vishwas, Do you recall the reason for making ESP mandatory and AH optional for OSPFv= 3 IPsec?=20 Thanks, Acee On Nov 2, 2010, at 8:05 PM, Vishwas Manral wrote: > Hi, >=20 > This errata is wrong. ESP provides authentication as well as > confidentiality, have a look at RFC 4301. >=20 > Thanks, > Vishwas >=20 > On Tue, Nov 2, 2010 at 8:53 AM, RFC Errata System > wrote: >>=20 >> The following errata report has been submitted for RFC4552, >> "Authentication/Confidentiality for OSPFv3". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D4552&eid=3D2599 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: John W. O'Brien >>=20 >> Section: 3 >>=20 >> Original Text >> ------------- >> In order to provide authentication to OSPFv3, implementations MUST suppo= rt ESP and MAY support AH. >>=20 >>=20 >> Corrected Text >> -------------- >> In order to provide authentication to OSPFv3, implementations MUST suppo= rt AH and MAY support ESP. >>=20 >> Notes >> ----- >> Authentication can be provided by an implementation that supports AH onl= y. >>=20 >> 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. >>=20 >> -------------------------------------- >> RFC4552 (draft-ietf-ospf-ospfv3-auth-08) >> -------------------------------------- >> Title : Authentication/Confidentiality for OSPFv3 >> Publication Date : June 2006 >> Author(s) : M. Gupta, N. Melam >> 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 >>=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Wed Nov 3 09:04:39 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84A928C111 for ; Wed, 3 Nov 2010 09:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPBawj0-wDTj for ; Wed, 3 Nov 2010 09:04:39 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id DD65628C10A for ; Wed, 3 Nov 2010 09:04:38 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id oA3G4VIX006357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Nov 2010 11:04:34 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id oA3G4TGw029107 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Nov 2010 21:34:29 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 3 Nov 2010 21:34:29 +0530 From: "Bhatia, Manav (Manav)" To: Acee Lindem , Vishwas Manral Date: Wed, 3 Nov 2010 21:34:31 +0530 Thread-Topic: [OSPF] [Technical Errata Reported] RFC4552 (2599) Thread-Index: Act7bsi7LAUlUR+CQ1mzBmwaSZH9WgAAd2sw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF4B13B1E@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20101102155316.C350CE06B7@rfc-editor.org> <66BC910D-6839-4C94-967C-B614864ECAB6@ericsson.com> In-Reply-To: <66BC910D-6839-4C94-967C-B614864ECAB6@ericsson.com> 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 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "acee@redback.com" , "ospf@ietf.org" , "adrian.farrel@huawei.com" , "mukesh.gupta@tropos.com" , "nmelam@juniper.net" , RFC Errata System Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 16:04:39 -0000 Hi Acee, That's because 4301 requires all Ipsec implementations to MUST support ESP = and MAY support AH.=20 Cheers, Manav > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 > Behalf Of Acee Lindem > Sent: Wednesday, November 03, 2010 9.20 PM > To: Vishwas Manral > Cc: acee@redback.com; ospf@ietf.org;=20 > adrian.farrel@huawei.com; mukesh.gupta@tropos.com;=20 > nmelam@juniper.net; RFC Errata System > Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) >=20 > Hi Vishwas, > Do you recall the reason for making ESP mandatory and AH=20 > optional for OSPFv3 IPsec?=20 > Thanks, > Acee > On Nov 2, 2010, at 8:05 PM, Vishwas Manral wrote: >=20 > > Hi, > >=20 > > This errata is wrong. ESP provides authentication as well as > > confidentiality, have a look at RFC 4301. > >=20 > > Thanks, > > Vishwas > >=20 > > On Tue, Nov 2, 2010 at 8:53 AM, RFC Errata System > > wrote: > >>=20 > >> The following errata report has been submitted for RFC4552, > >> "Authentication/Confidentiality for OSPFv3". > >>=20 > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=3D4552&eid=3D2599 > >>=20 > >> -------------------------------------- > >> Type: Technical > >> Reported by: John W. O'Brien > >>=20 > >> Section: 3 > >>=20 > >> Original Text > >> ------------- > >> In order to provide authentication to OSPFv3,=20 > implementations MUST support ESP and MAY support AH. > >>=20 > >>=20 > >> Corrected Text > >> -------------- > >> In order to provide authentication to OSPFv3,=20 > implementations MUST support AH and MAY support ESP. > >>=20 > >> Notes > >> ----- > >> Authentication can be provided by an implementation that=20 > supports AH only. > >>=20 > >> 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. > >>=20 > >> -------------------------------------- > >> RFC4552 (draft-ietf-ospf-ospfv3-auth-08) > >> -------------------------------------- > >> Title : Authentication/Confidentiality for OSPFv3 > >> Publication Date : June 2006 > >> Author(s) : M. Gupta, N. Melam > >> 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 > >>=20 > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > = From mukesh@juniper.net Wed Nov 3 09:12:12 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33F83A69CE for ; Wed, 3 Nov 2010 09:12:12 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWh5T6owEkFf for ; Wed, 3 Nov 2010 09:12:11 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id C1CB13A68E7 for ; Wed, 3 Nov 2010 09:12:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTNGJ24DHIEBM/4notKGvcNZDv6OzkkvL@postini.com; Wed, 03 Nov 2010 09:12:19 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 3 Nov 2010 09:09:25 -0700 From: Mukesh Gupta To: "Bhatia, Manav (Manav)" , Acee Lindem , Vishwas Manral Date: Wed, 3 Nov 2010 09:09:24 -0700 Thread-Topic: [OSPF] [Technical Errata Reported] RFC4552 (2599) Thread-Index: Act7bsi7LAUlUR+CQ1mzBmwaSZH9WgAAd2swAAAgvGA= Message-ID: <497B6D90E0023142AF34948DEFFAB38D3B239C17FA@EMBX01-HQ.jnpr.net> References: <20101102155316.C350CE06B7@rfc-editor.org> <66BC910D-6839-4C94-967C-B614864ECAB6@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CF4B13B1E@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CF4B13B1E@INBANSXCHMBSA1.in.alcatel-lucent.com> 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 Cc: "acee@redback.com" , "ospf@ietf.org" , "adrian.farrel@huawei.com" , "mukesh.gupta@tropos.com" , Suresh Melam , RFC Errata System Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 16:12:13 -0000 Manav is right. That was mainly the reason behind making ESP a MUST and AH= a SHOULD. Excerpt from section 3.2 of RFC 4301: IPsec implementations MUST support ESP and MAY support AH. (Support for AH has been downgraded to MAY because experience has shown that there are very few contexts in which ESP cannot provide the requisite security services. Note that ESP can be used to provide only integrity, without confidentiality, making it comparable to AH in most contexts.) - Mukesh -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bha= tia, Manav (Manav) Sent: Wednesday, November 03, 2010 9:05 AM To: Acee Lindem; Vishwas Manral Cc: acee@redback.com; ospf@ietf.org; adrian.farrel@huawei.com; mukesh.gupta= @tropos.com; Suresh Melam; RFC Errata System Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) Hi Acee, That's because 4301 requires all Ipsec implementations to MUST support ESP = and MAY support AH.=20 Cheers, Manav > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 > Behalf Of Acee Lindem > Sent: Wednesday, November 03, 2010 9.20 PM > To: Vishwas Manral > Cc: acee@redback.com; ospf@ietf.org;=20 > adrian.farrel@huawei.com; mukesh.gupta@tropos.com;=20 > nmelam@juniper.net; RFC Errata System > Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) >=20 > Hi Vishwas, > Do you recall the reason for making ESP mandatory and AH=20 > optional for OSPFv3 IPsec?=20 > Thanks, > Acee > On Nov 2, 2010, at 8:05 PM, Vishwas Manral wrote: >=20 > > Hi, > >=20 > > This errata is wrong. ESP provides authentication as well as > > confidentiality, have a look at RFC 4301. > >=20 > > Thanks, > > Vishwas > >=20 > > On Tue, Nov 2, 2010 at 8:53 AM, RFC Errata System > > wrote: > >>=20 > >> The following errata report has been submitted for RFC4552, > >> "Authentication/Confidentiality for OSPFv3". > >>=20 > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=3D4552&eid=3D2599 > >>=20 > >> -------------------------------------- > >> Type: Technical > >> Reported by: John W. O'Brien > >>=20 > >> Section: 3 > >>=20 > >> Original Text > >> ------------- > >> In order to provide authentication to OSPFv3,=20 > implementations MUST support ESP and MAY support AH. > >>=20 > >>=20 > >> Corrected Text > >> -------------- > >> In order to provide authentication to OSPFv3,=20 > implementations MUST support AH and MAY support ESP. > >>=20 > >> Notes > >> ----- > >> Authentication can be provided by an implementation that=20 > supports AH only. > >>=20 > >> 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. > >>=20 > >> -------------------------------------- > >> RFC4552 (draft-ietf-ospf-ospfv3-auth-08) > >> -------------------------------------- > >> Title : Authentication/Confidentiality for OSPFv3 > >> Publication Date : June 2006 > >> Author(s) : M. Gupta, N. Melam > >> 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 > >>=20 > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From john.w.obrien@lmco.com Wed Nov 3 09:29:45 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16A2828C112 for ; Wed, 3 Nov 2010 09:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.623 X-Spam-Level: X-Spam-Status: No, score=-9.623 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CSSHqc9pMqW for ; Wed, 3 Nov 2010 09:29:44 -0700 (PDT) Received: from mailfo02.lmco.com (mailfo02.lmco.com [192.35.35.12]) by core3.amsl.com (Postfix) with ESMTP id E3E053A6AD2 for ; Wed, 3 Nov 2010 09:29:43 -0700 (PDT) Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.7]) by mailfo02.lmco.com (8.14.3/8.14.3) with ESMTP id oA3GToQd000801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Nov 2010 16:29:50 GMT Received: from emss09g01.ems.lmco.com (relay6.ems.lmco.com [166.17.13.59])by mailgw3a.lmco.com (LM-6) with ESMTP id oA3GTocj007742for ; Wed, 3 Nov 2010 12:29:50 -0400 (EDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31806) id <0LBB00F01HTQO3@lmco.com> for ospf@ietf.org; Wed, 03 Nov 2010 16:29:50 +0000 (GMT) Received: from hvxhtpn4.us.lmco.com ([158.186.148.33]) by lmco.com (PMDF V6.4 #31806) with ESMTP id <0LBB0061KHTL7F@lmco.com> for ospf@ietf.org; Wed, 03 Nov 2010 16:29:45 +0000 (GMT) Received: from HVXMSP5.us.lmco.com ([158.186.148.28]) by hvxhtpn4.us.lmco.com ([158.186.148.33]) with mapi; Wed, 03 Nov 2010 12:29:45 -0400 Date: Wed, 03 Nov 2010 12:29:44 -0400 From: "Obrien, John W" In-reply-to: To: "ospf@ietf.org" Message-id: <7AA4282413159948AD514B064BE1478D1840AE6F81@HVXMSP5.us.lmco.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: 7BIT Thread-Topic: [OSPF] [Technical Errata Reported] RFC4552 (2599) Thread-Index: Act66ts2ngSySVX+T9GNd9wfBP4QTQAiTH7g Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20101102155316.C350CE06B7@rfc-editor.org> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-11-03_07:2010-11-03, 2010-11-03, 1970-01-01 signatures=0 Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 16:29:45 -0000 [My original reply was rejected by the list. Resent for posterity now that I've subscribed.] Vishwas, Thanks for your prompt response. I do not dispute that ESP provides authentication as well, but I don't believe that fact invalidates this errata. My stated rationale still holds, does it not? If an implementation desires to provide authentication without also providing confidentiality (as is permitted by 4552), AH alone can perform that function. Furthermore, AH authenticates more of the packet than does ESP. What is the rationale, therefore, for attaching the stronger "MUST" to ESP and the weaker "MAY" to AH in Section 3, Authentication? The errata may be invalid because the authors' intention is to mandate ESP support in all cases, regardless of the line of thought above, which I accept. That would mean that my comment against the specification should be submitted and discussed in a different forum. Regards, John -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Tuesday, November 02, 2010 8:05 PM To: RFC Errata System Cc: mukesh.gupta@tropos.com; nmelam@juniper.net; stbryant@cisco.com; adrian.farrel@huawei.com; acee@redback.com; akr@cisco.com; ospf@ietf.org; Obrien, John W Subject: EXTERNAL: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) Hi, This errata is wrong. ESP provides authentication as well as confidentiality, have a look at RFC 4301. Thanks, Vishwas On Tue, Nov 2, 2010 at 8:53 AM, RFC Errata System wrote: > > The following errata report has been submitted for RFC4552, > "Authentication/Confidentiality for OSPFv3". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4552&eid=2599 > > -------------------------------------- > Type: Technical > Reported by: John W. O'Brien > > Section: 3 > > Original Text > ------------- > In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH. > > > Corrected Text > -------------- > In order to provide authentication to OSPFv3, implementations MUST support AH and MAY support ESP. > > Notes > ----- > Authentication can be provided by an implementation that supports AH only. > > 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. > > -------------------------------------- > RFC4552 (draft-ietf-ospf-ospfv3-auth-08) > -------------------------------------- > Title : Authentication/Confidentiality for OSPFv3 > Publication Date : June 2006 > Author(s) : M. Gupta, N. Melam > 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 vishwas.ietf@gmail.com Wed Nov 3 09:30:38 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8726528C112 for ; Wed, 3 Nov 2010 09:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3auh3RXVa-L for ; Wed, 3 Nov 2010 09:30:37 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 8DEC628C107 for ; Wed, 3 Nov 2010 09:30:37 -0700 (PDT) Received: by qwb7 with SMTP id 7so203673qwb.31 for ; Wed, 03 Nov 2010 09:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bt0i5EsU93XWIxhm8Foj9f7CoEYIbcZeTol4sLRBYaA=; b=kRBH6igM/FHLFNKZMZf5O8Qz+Nj5tSKWIKPKDFsZD0a5vrwj8op4I28dNvpt/jTf92 ARsdLUJLT/i3edwQhJX0LMEuhYbOjWySQgMIjGaxWPuLDZkW4ihdxKr87LEbobjxtGOV wAqNavmlPdLo8H0QucCYkpeLP9z9MzK1vUupY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=skMgtyb1HzLCB6PMLgjng/abgbnlLdnVY/OHIZo6pnHF82eqXebA7dGrPIyriC0cqD kwmAJUCZobiHCTBNCW0bXz3IiXRNXXT8YIu1B/XdbuzANavuiWr3CFcQ+hWR0a//fYN3 w2cipOdwbt0OpyLcjnvpMLXfB5bvqHCSohMHI= MIME-Version: 1.0 Received: by 10.229.236.8 with SMTP id ki8mr12317804qcb.116.1288801844676; Wed, 03 Nov 2010 09:30:44 -0700 (PDT) Received: by 10.229.65.93 with HTTP; Wed, 3 Nov 2010 09:30:44 -0700 (PDT) In-Reply-To: <66BC910D-6839-4C94-967C-B614864ECAB6@ericsson.com> References: <20101102155316.C350CE06B7@rfc-editor.org> <66BC910D-6839-4C94-967C-B614864ECAB6@ericsson.com> Date: Wed, 3 Nov 2010 09:30:44 -0700 Message-ID: From: Vishwas Manral To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "acee@redback.com" , "ospf@ietf.org" , "adrian.farrel@huawei.com" , "mukesh.gupta@tropos.com" , "nmelam@juniper.net" , RFC Errata System Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 16:30:38 -0000 Hi Acee, The reason IPsec mandates ESP as for most part ESP is a superset of AH and the aim is to somehow not have 2 ways to do things when they can be done with just one protocol. Thanks, Vishwas On Wed, Nov 3, 2010 at 8:50 AM, Acee Lindem wrot= e: > Hi Vishwas, > Do you recall the reason for making ESP mandatory and AH optional for OSP= Fv3 IPsec? > Thanks, > Acee > On Nov 2, 2010, at 8:05 PM, Vishwas Manral wrote: > >> Hi, >> >> This errata is wrong. ESP provides authentication as well as >> confidentiality, have a look at RFC 4301. >> >> Thanks, >> Vishwas >> >> On Tue, Nov 2, 2010 at 8:53 AM, RFC Errata System >> wrote: >>> >>> The following errata report has been submitted for RFC4552, >>> "Authentication/Confidentiality for OSPFv3". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D4552&eid=3D2599 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: John W. O'Brien >>> >>> Section: 3 >>> >>> Original Text >>> ------------- >>> In order to provide authentication to OSPFv3, implementations MUST supp= ort ESP and MAY support AH. >>> >>> >>> Corrected Text >>> -------------- >>> In order to provide authentication to OSPFv3, implementations MUST supp= ort AH and MAY support ESP. >>> >>> Notes >>> ----- >>> Authentication can be provided by an implementation that supports AH on= ly. >>> >>> 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. >>> >>> -------------------------------------- >>> RFC4552 (draft-ietf-ospf-ospfv3-auth-08) >>> -------------------------------------- >>> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Authentication/Confidentiality for = OSPFv3 >>> Publication Date =A0 =A0: June 2006 >>> Author(s) =A0 =A0 =A0 =A0 =A0 : M. Gupta, N. Melam >>> Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD >>> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Open Shortest Path First IGP >>> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing >>> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF >>> Verifying Party =A0 =A0 : IESG >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > From manav.bhatia@alcatel-lucent.com Wed Nov 3 09:47:06 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942E33A69D7 for ; Wed, 3 Nov 2010 09:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVu1EiCoa3Wx for ; Wed, 3 Nov 2010 09:47:05 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 620023A68D7 for ; Wed, 3 Nov 2010 09:47:05 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id oA3Gl9bQ012746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Nov 2010 11:47:11 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id oA3Gl7Xf030252 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Nov 2010 22:17:08 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 3 Nov 2010 22:17:07 +0530 From: "Bhatia, Manav (Manav)" To: "Obrien, John W" , "ospf@ietf.org" Date: Wed, 3 Nov 2010 22:17:14 +0530 Thread-Topic: [OSPF] [Technical Errata Reported] RFC4552 (2599) Thread-Index: Act66ts2ngSySVX+T9GNd9wfBP4QTQAiTH7gAAA0mWA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF4B13B31@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20101102155316.C350CE06B7@rfc-editor.org> <7AA4282413159948AD514B064BE1478D1840AE6F81@HVXMSP5.us.lmco.com> In-Reply-To: <7AA4282413159948AD514B064BE1478D1840AE6F81@HVXMSP5.us.lmco.com> 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.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 16:47:06 -0000 John, There are several 4301 compliant implementations that may NOT support AH. I= f 4552 mandates AH, then many implementations that are Ipsec compliant toda= y will not be able to provide security for OSPF as they may not be supporti= ng AH (and may also not have in their roadmap to support it in the future). BTW, RFC 5796, which explains how PIM-SM can use Ipsec to secure its packet= s also has ESP as a MUST and AH as a MAY. Cheers, Manav > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 > Behalf Of Obrien, John W > Sent: Wednesday, November 03, 2010 10.00 PM > To: ospf@ietf.org > Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) >=20 > [My original reply was rejected by the list. Resent for=20 > posterity now that I've subscribed.] >=20 > Vishwas, >=20 > Thanks for your prompt response. >=20 > I do not dispute that ESP provides authentication as well,=20 > but I don't believe that fact invalidates this errata. My=20 > stated rationale still holds, does it not? If an=20 > implementation desires to provide authentication without also=20 > providing confidentiality (as is permitted by 4552), AH alone=20 > can perform that function. Furthermore, AH authenticates more=20 > of the packet than does ESP. What is the rationale,=20 > therefore, for attaching the stronger "MUST" to ESP and the=20 > weaker "MAY" to AH in Section 3, Authentication? >=20 > The errata may be invalid because the authors' intention is=20 > to mandate ESP support in all cases, regardless of the line=20 > of thought above, which I accept. That would mean that my=20 > comment against the specification should be submitted and=20 > discussed in a different forum. >=20 > Regards, > John >=20 > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Tuesday, November 02, 2010 8:05 PM > To: RFC Errata System > Cc: mukesh.gupta@tropos.com; nmelam@juniper.net;=20 > stbryant@cisco.com; adrian.farrel@huawei.com;=20 > acee@redback.com; akr@cisco.com; ospf@ietf.org; Obrien, John W > Subject: EXTERNAL: Re: [OSPF] [Technical Errata Reported]=20 > RFC4552 (2599) >=20 > Hi, >=20 > This errata is wrong. ESP provides authentication as well as > confidentiality, have a look at RFC 4301. >=20 > Thanks, > Vishwas >=20 > On Tue, Nov 2, 2010 at 8:53 AM, RFC Errata System > wrote: > > > > The following errata report has been submitted for RFC4552, > > "Authentication/Confidentiality for OSPFv3". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D4552&eid=3D2599 > > > > -------------------------------------- > > Type: Technical > > Reported by: John W. O'Brien > > > > Section: 3 > > > > Original Text > > ------------- > > In order to provide authentication to OSPFv3,=20 > implementations MUST support ESP and MAY support AH. > > > > > > Corrected Text > > -------------- > > In order to provide authentication to OSPFv3,=20 > implementations MUST support AH and MAY support ESP. > > > > Notes > > ----- > > Authentication can be provided by an implementation that=20 > supports AH only. > > > > 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. > > > > -------------------------------------- > > RFC4552 (draft-ietf-ospf-ospfv3-auth-08) > > -------------------------------------- > > Title : Authentication/Confidentiality for OSPFv3 > > Publication Date : June 2006 > > Author(s) : M. Gupta, N. Melam > > 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 > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > = From john.w.obrien@lmco.com Wed Nov 3 11:05:57 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5526C28C113 for ; Wed, 3 Nov 2010 11:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.867 X-Spam-Level: X-Spam-Status: No, score=-9.867 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHvFAyUmEh-7 for ; Wed, 3 Nov 2010 11:05:56 -0700 (PDT) Received: from mailfo02.lmco.com (mailfo02.lmco.com [192.35.35.12]) by core3.amsl.com (Postfix) with ESMTP id DAD7328C10D for ; Wed, 3 Nov 2010 11:05:55 -0700 (PDT) Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.7]) by mailfo02.lmco.com (8.14.3/8.14.3) with ESMTP id oA3I62cm012654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Nov 2010 18:06:02 GMT Received: from emss04g01.ems.lmco.com (relay4.ems.lmco.com [166.17.13.122])by mailgw3a.lmco.com (LM-6) with ESMTP id oA3I61Cb024489for ; Wed, 3 Nov 2010 14:06:02 -0400 (EDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31806) id <0LBB00I01M9K76@lmco.com> for ospf@ietf.org; Wed, 03 Nov 2010 18:06:01 +0000 (GMT) Received: from hvxhtpn2.us.lmco.com ([158.186.148.31]) by lmco.com (PMDF V6.4 #31806) with ESMTP id <0LBB00FG9M9QOV@lmco.com> for ospf@ietf.org; Wed, 03 Nov 2010 18:05:50 +0000 (GMT) Received: from HVXMSP5.us.lmco.com ([158.186.148.28]) by hvxhtpn2.us.lmco.com ([158.186.148.31]) with mapi; Wed, 03 Nov 2010 14:05:49 -0400 Date: Wed, 03 Nov 2010 14:05:48 -0400 From: "Obrien, John W" In-reply-to: <7C362EEF9C7896468B36C9B79200D8350CF4B13B31@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "ospf@ietf.org" Message-id: <7AA4282413159948AD514B064BE1478D1840AE718C@HVXMSP5.us.lmco.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Thread-Topic: [OSPF] [Technical Errata Reported] RFC4552 (2599) Thread-Index: Act66ts2ngSySVX+T9GNd9wfBP4QTQAiTH7gAAA0mWAAAzRdgA== Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20101102155316.C350CE06B7@rfc-editor.org> <7AA4282413159948AD514B064BE1478D1840AE6F81@HVXMSP5.us.lmco.com> <7C362EEF9C7896468B36C9B79200D8350CF4B13B31@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-11-03_07:2010-11-03, 2010-11-03, 1970-01-01 signatures=0 Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 18:05:57 -0000 Manav, So it sounds like this is really a question of systems engineering philosophy. As written, 4552 (and 5796, and surely others) duplicates material from 4301 in a manner that exceeds its scope but for arguably good reasons. That is, 4552 covers how to correctly implement IPsec, not just how to correctly apply IPsec to secure OSPFv3. I can see that there would be a potential benefit to this approach, since an implementation that is compliant to 4552 would necessarily be compliant to 4301. However, I would advocate for cleaner separation between the standards; keeping the items that are concerned with the general implementation of IPsec in 4301, and those that are concerned with specific applications of IPsec in 4552, etc. Just my $0.02. In any case, I recognize that my submission is not a valid technical errata and agree that it should be rejected as such. Regards, John -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Wednesday, November 03, 2010 12:47 PM To: Obrien, John W; ospf@ietf.org Subject: EXTERNAL: RE: [OSPF] [Technical Errata Reported] RFC4552 (2599) John, There are several 4301 compliant implementations that may NOT support AH. If 4552 mandates AH, then many implementations that are Ipsec compliant today will not be able to provide security for OSPF as they may not be supporting AH (and may also not have in their roadmap to support it in the future). BTW, RFC 5796, which explains how PIM-SM can use Ipsec to secure its packets also has ESP as a MUST and AH as a MAY. Cheers, Manav > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On > Behalf Of Obrien, John W > Sent: Wednesday, November 03, 2010 10.00 PM > To: ospf@ietf.org > Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599) > > [My original reply was rejected by the list. Resent for > posterity now that I've subscribed.] > > Vishwas, > > Thanks for your prompt response. > > I do not dispute that ESP provides authentication as well, > but I don't believe that fact invalidates this errata. My > stated rationale still holds, does it not? If an > implementation desires to provide authentication without also > providing confidentiality (as is permitted by 4552), AH alone > can perform that function. Furthermore, AH authenticates more > of the packet than does ESP. What is the rationale, > therefore, for attaching the stronger "MUST" to ESP and the > weaker "MAY" to AH in Section 3, Authentication? > > The errata may be invalid because the authors' intention is > to mandate ESP support in all cases, regardless of the line > of thought above, which I accept. That would mean that my > comment against the specification should be submitted and > discussed in a different forum. > > Regards, > John > > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Tuesday, November 02, 2010 8:05 PM > To: RFC Errata System > Cc: mukesh.gupta@tropos.com; nmelam@juniper.net; > stbryant@cisco.com; adrian.farrel@huawei.com; > acee@redback.com; akr@cisco.com; ospf@ietf.org; Obrien, John W > Subject: EXTERNAL: Re: [OSPF] [Technical Errata Reported] > RFC4552 (2599) > > Hi, > > This errata is wrong. ESP provides authentication as well as > confidentiality, have a look at RFC 4301. > > Thanks, > Vishwas > > On Tue, Nov 2, 2010 at 8:53 AM, RFC Errata System > wrote: > > > > The following errata report has been submitted for RFC4552, > > "Authentication/Confidentiality for OSPFv3". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4552&eid=2599 > > > > -------------------------------------- > > Type: Technical > > Reported by: John W. O'Brien > > > > Section: 3 > > > > Original Text > > ------------- > > In order to provide authentication to OSPFv3, > implementations MUST support ESP and MAY support AH. > > > > > > Corrected Text > > -------------- > > In order to provide authentication to OSPFv3, > implementations MUST support AH and MAY support ESP. > > > > Notes > > ----- > > Authentication can be provided by an implementation that > supports AH only. > > > > 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. > > > > -------------------------------------- > > RFC4552 (draft-ietf-ospf-ospfv3-auth-08) > > -------------------------------------- > > Title : Authentication/Confidentiality for OSPFv3 > > Publication Date : June 2006 > > Author(s) : M. Gupta, N. Melam > > 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 > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From sinbad.sinbad@gmail.com Mon Nov 8 20:33:30 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1BF33A67B7 for ; Mon, 8 Nov 2010 20:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nu6CyynN0r8r for ; Mon, 8 Nov 2010 20:33:27 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 074873A67B8 for ; Mon, 8 Nov 2010 20:33:26 -0800 (PST) Received: by ewy27 with SMTP id 27so3644701ewy.31 for ; Mon, 08 Nov 2010 20:33:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=MtOXwLGr1MY2X4o6n7ECy90h/zhcDm59E8GPajPL47I=; b=qbQV8yL4q8RXRp6Zlpi00PEXinjm5SDuNHGLDsyarU+W052ZuBEfiTQzJS7EJ14EY0 OV7P/n5oTE8zeT8/Pha0LyKd0FPDbvNTFGdhpzG8Juhz6ydyuN1WDj8s8vJmERfu8Azq +mP7kakWBEde+K+tkbzyiofx/BAkamIi72nUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ta3Zuhcqkyeai4wsRwla9rczWEUtDI8z9baY1DbA96A8aKzggn4JVUc+gF8rb2KXn1 bW6SncapK8P8RxOmOcZWOVdhDHnK7r+gINA23D+4psQd6/OrSFApA+5Hio6d78r/bVJv GbdQMDrPhZiQPqIsAZGTucyx1uNyYB/c3I+mU= MIME-Version: 1.0 Received: by 10.213.31.143 with SMTP id y15mr2803819ebc.24.1289277229606; Mon, 08 Nov 2010 20:33:49 -0800 (PST) Received: by 10.213.106.14 with HTTP; Mon, 8 Nov 2010 20:33:49 -0800 (PST) Date: Tue, 9 Nov 2010 10:03:49 +0530 Message-ID: From: Sinbad To: ospf@ietf.org Content-Type: multipart/alternative; boundary=0015174c130449a94e0494973fcb Subject: [OSPF] nssa translation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 04:33:30 -0000 --0015174c130449a94e0494973fcb Content-Type: text/plain; charset=ISO-8859-1 hi, can i safely assume that those nssa lsas that were used in spf calculation at a border router will be the only lsas that will be translated if that border router were a translator. thanks --0015174c130449a94e0494973fcb Content-Type: text/html; charset=ISO-8859-1 hi,

can i safely assume that those nssa lsas that were used in spf calculation at a border router
will be the only lsas that will be translated if that border router were a translator.

thanks

--0015174c130449a94e0494973fcb-- From acee.lindem@ericsson.com Mon Nov 8 22:42:24 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EB233A67AD for ; Mon, 8 Nov 2010 22:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81THA68fGk-O for ; Mon, 8 Nov 2010 22:42:22 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 01CAA3A67E7 for ; Mon, 8 Nov 2010 22:42:20 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oA96gebj028803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Nov 2010 00:42:41 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 9 Nov 2010 01:42:40 -0500 From: Acee Lindem To: Sinbad Date: Tue, 9 Nov 2010 01:42:37 -0500 Thread-Topic: [OSPF] nssa translation Thread-Index: Act/2U22XV1RSiI7SNeovIWWd/4vWA== Message-ID: <757A6369-4810-4036-BDDF-37FC19C52BD5@ericsson.com> References: In-Reply-To: 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 Cc: "ospf@ietf.org" Subject: Re: [OSPF] nssa translation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 06:42:25 -0000 Hi Sinbad,=20 On Nov 8, 2010, at 11:33 PM, Sinbad wrote: > hi, >=20 > can i safely assume that those nssa lsas that were used in spf calculatio= n at a border router > will be the only lsas that will be translated if that border router were = a translator. The answer is yes, assuming that by "used" you mean those resulting in OSPF= NSSA routes installed in the OSPF routing table.=20 Hope this helps, Acee >=20 > thanks >=20 > From vpendharkar@gmail.com Tue Nov 9 06:40:01 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AE623A69E7 for ; Tue, 9 Nov 2010 06:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB1+m7msyZKR for ; Tue, 9 Nov 2010 06:39:59 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 421EF3A69FF for ; Tue, 9 Nov 2010 06:39:48 -0800 (PST) Received: by eyd10 with SMTP id 10so3653442eyd.31 for ; Tue, 09 Nov 2010 06:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=eM5pdKoEV3TXHaRHXQN7fOr5E/WKcYx/eZbGSWjVIrQ=; b=HjBLr5JFY+HzxcpfcMg5Y1IlzIRcpbavOznuBx7+d20qQJzFTvcZvkX1U2fNe4eDyw Q0We7Pxt4igWoKsL7UpUY1oy0ks9eYptmC4nFk6Wj8+M64sQK9pyP/XpgVddA9xvFLMD J2jFAzFvq575mQMCIRUNDD7f+t7QLmSzRF114= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=WnEPWMbg9BauE1lUYQaXddVUx9LSi7yz3MGSeKhnL5DYUDWoQmb/oIjYXModadEM7Y QK/+VJUhHuupmuW0ddU2V0np+GWO7BWs8TsY47BCtl+PHbEoU4ZedVzPzoz1RdbOQBYn 1kQ4Dgj/WY2IOu+Vr9lHeHzg+eEYyww4WeqHs= Received: by 10.216.163.80 with SMTP id z58mr1174076wek.33.1289313576186; Tue, 09 Nov 2010 06:39:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.46.85 with HTTP; Tue, 9 Nov 2010 06:39:10 -0800 (PST) From: Vikram Pendharkar Date: Tue, 9 Nov 2010 09:39:10 -0500 Message-ID: To: ospf@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [OSPF] 1-Way event handling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 14:40:01 -0000 Hi, Would there be any issues if as part of 1-Way event handling we additionally send out a hello to the neighbor immediately rather than wait for hello timer to expire. This should speed up adjacency formation. Thanks, Vikram From dkatz@juniper.net Tue Nov 9 08:21:06 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C6A3A68A5 for ; Tue, 9 Nov 2010 08:21:06 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFQDOxdxHySG for ; Tue, 9 Nov 2010 08:21:05 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 72EB73A6885 for ; Tue, 9 Nov 2010 08:21:05 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTNl1CQ3xkIvn3X80wYIYdJ7B1SINvXV3@postini.com; Tue, 09 Nov 2010 08:21:30 PST Received: from merlot.juniper.net (172.17.27.10) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 9 Nov 2010 08:20:38 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id oA9GKcb23349; Tue, 9 Nov 2010 08:20:38 -0800 (PST) (envelope-from dkatz@juniper.net) MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: Date: Tue, 9 Nov 2010 09:20:37 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <4782C7AC-EBF2-4621-8622-965C1E312D1B@juniper.net> References: To: Vikram Pendharkar X-Mailer: Apple Mail (2.1081) Cc: ospf@ietf.org Subject: Re: [OSPF] 1-Way event handling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 16:21:06 -0000 All of the implementations I'm familiar with do exactly that. One has = to be careful with the logic so as to not accidentally get into a Hello = war with the neighbor, of course. --Dave On Nov 9, 2010, at 7:39 AM, Vikram Pendharkar wrote: > Hi, >=20 > Would there be any issues if as part of 1-Way event handling we > additionally send out a hello to the neighbor immediately rather than > wait for hello timer to expire. This should speed up adjacency > formation. >=20 > Thanks, > Vikram > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 From vpendharkar@gmail.com Tue Nov 9 08:50:07 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F2D3A6951 for ; Tue, 9 Nov 2010 08:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5xQ0E5du3Z8 for ; Tue, 9 Nov 2010 08:50:05 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 5146B3A68C2 for ; Tue, 9 Nov 2010 08:50:05 -0800 (PST) Received: by eyd10 with SMTP id 10so3807103eyd.31 for ; Tue, 09 Nov 2010 08:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ARx7TLAmIUuTfHiccQdGthWrk1+QRLV6lUpHiEgsxM4=; b=H6iB9GBFq93clUCrQB5x9phc/jTQ/zM9dXha96rZirbAHegaIX2ty62P3IU2WhDZor tiw/dpPB/KNy1FR3XJdfQ0Qy8/KW7Y7aT9hfmilU+MIirjri5JUy8AOWYSedia1sf4Zz iMoy4Pa7g3gjNmXArpnFYtf4wLNibLTGoV4IA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=rA8Cw6nLZ4DltcyRM3p79pJ4GC6A8iL1v9EqgplwWuoxyzluoq4UKOjxWO4aKg47lV /pHoL2G1TASoNndFxv49ac0Tm9hQRtjKAcasJY5U48BfIMSH8bXJUesSu69a11VEqKrt xTojT8kIqpMdr5AxI/2Fzxw4NAgfJI5z1hKQk= Received: by 10.216.163.80 with SMTP id z58mr1382160wek.33.1289321428360; Tue, 09 Nov 2010 08:50:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.46.85 with HTTP; Tue, 9 Nov 2010 08:50:08 -0800 (PST) In-Reply-To: <4782C7AC-EBF2-4621-8622-965C1E312D1B@juniper.net> References: <4782C7AC-EBF2-4621-8622-965C1E312D1B@juniper.net> From: Vikram Pendharkar Date: Tue, 9 Nov 2010 11:50:08 -0500 Message-ID: To: Dave Katz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ospf@ietf.org Subject: Re: [OSPF] 1-Way event handling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 16:50:07 -0000 That's good to know. In which case, would it make sense to update the RFC for the same as well? Vikram On Tue, Nov 9, 2010 at 11:20 AM, Dave Katz wrote: > All of the implementations I'm familiar with do exactly that. =C2=A0One h= as to be careful with the logic so as to not accidentally get into a Hello = war with the neighbor, of course. > > --Dave > > On Nov 9, 2010, at 7:39 AM, Vikram Pendharkar wrote: > >> Hi, >> >> Would there be any issues if as part of 1-Way event handling we >> additionally send out a hello to the neighbor immediately rather than >> wait for hello timer to expire. This should speed up adjacency >> formation. >> >> Thanks, >> Vikram >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> > > From sriganeshkini@gmail.com Wed Nov 10 17:36:40 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACDB83A68D3 for ; Wed, 10 Nov 2010 17:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLrnsTWsVyL1 for ; Wed, 10 Nov 2010 17:36:39 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 807CA3A68C8 for ; Wed, 10 Nov 2010 17:36:36 -0800 (PST) Received: by fxm3 with SMTP id 3so1017951fxm.31 for ; Wed, 10 Nov 2010 17:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=dVwnxR5rYi1qW16JYo7bcTnUoPC2EaiH51PSr9vJUOU=; b=jevuf+iT9qL0cKJl+/D8Jeyl/TeYXu1QMtMbHEcdbn07BbhbDkZ0YqLsyz71I2zMEx SqtyDqFr5SGCMCO8BM+YXgvf6axioBHD5LD0yxqy0IJx6J5eNVQxG5XSUCi3OylNk1XR GBpuXgWyUZRYAS7Mrbsyo382ozepKGBGeltxs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=jj2gWYxwjT4AipX0EKJpsRE0F6Xa+FhbNZ1qb9p6PVkEWOKIM7+gQ4vAYeAQfw9koy pceRXL/9k4VrtFZoC2WFwGLcJTZ2Jtsb4f1Eqo4FJdX4tv/s08kW+fOQgMxeIVkwOUBu DU8858+fTdVAsvkNDip/EHLzK9iZzJAkhabak= Received: by 10.223.87.2 with SMTP id u2mr6307168fal.106.1289439422054; Wed, 10 Nov 2010 17:37:02 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.223.1.205 with HTTP; Wed, 10 Nov 2010 17:36:41 -0800 (PST) From: Sriganesh Kini Date: Wed, 10 Nov 2010 17:36:41 -0800 X-Google-Sender-Auth: CTm4rWYZbahbhS5ciZvX7Ljn1AI Message-ID: To: ospf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OSPF] Slides for draft-kini-ospf-fast-notification-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 01:36:40 -0000 Just an FYI This slides for the I-D http://www.ietf/org/draft-kini-ospf-fast-notification-00.txt (presented in the OSPF WG meeting yesterday) are now uploaded to http://tools.ietf.org/agenda/79/slides/ospf-10.pdf Thanks -- - Sri From acee.lindem@ericsson.com Thu Nov 11 01:02:49 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F6C3A6991 for ; Thu, 11 Nov 2010 01:02:49 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-Absao5xLJN for ; Thu, 11 Nov 2010 01:02:48 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id BC81528C0E1 for ; Thu, 11 Nov 2010 01:02:46 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oAB9QkTA020291; Thu, 11 Nov 2010 03:26:47 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 11 Nov 2010 04:03:08 -0500 From: Acee Lindem To: Vikram Pendharkar Date: Thu, 11 Nov 2010 04:03:05 -0500 Thread-Topic: [OSPF] 1-Way event handling Thread-Index: AcuBf0IbPNvfHdqYQ/yX+CelaqQ2Qw== Message-ID: References: <4782C7AC-EBF2-4621-8622-965C1E312D1B@juniper.net> In-Reply-To: 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 Cc: "ospf@ietf.org" Subject: Re: [OSPF] 1-Way event handling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 09:02:49 -0000 Vikram,=20 We don't need a new draft for this. If you search the mailing list archives= you'll find that someone else already suggested a draft on this subject an= d no one believed it was necessary given that 1) it is not required for int= eroperable protocol operation and 2) the optimization was in almost every i= mplementation.=20 Thanks, Acee=20 On Nov 9, 2010, at 11:50 AM, Vikram Pendharkar wrote: > That's good to know. In which case, would it make sense to update the > RFC for the same as well? >=20 > Vikram >=20 >=20 >=20 >=20 > On Tue, Nov 9, 2010 at 11:20 AM, Dave Katz wrote: >> All of the implementations I'm familiar with do exactly that. One has t= o be careful with the logic so as to not accidentally get into a Hello war = with the neighbor, of course. >>=20 >> --Dave >>=20 >> On Nov 9, 2010, at 7:39 AM, Vikram Pendharkar wrote: >>=20 >>> Hi, >>>=20 >>> Would there be any issues if as part of 1-Way event handling we >>> additionally send out a hello to the neighbor immediately rather than >>> wait for hello timer to expire. This should speed up adjacency >>> formation. >>>=20 >>> Thanks, >>> Vikram >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>>=20 >>=20 >>=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From wwwrun@rfc-editor.org Sat Nov 13 13:33:27 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47223A6A85 for ; Sat, 13 Nov 2010 13:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.318 X-Spam-Level: X-Spam-Status: No, score=-102.318 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm0+zwYpVhT1 for ; Sat, 13 Nov 2010 13:33:19 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id CC2223A69FE for ; Sat, 13 Nov 2010 13:33:19 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B5764E06F6; Sat, 13 Nov 2010 13:33:56 -0800 (PST) To: jmoy@casc.com, stbryant@cisco.com, adrian.farrel@huawei.com, acee@redback.com, akr@cisco.com From: RFC Errata System Message-Id: <20101113213356.B5764E06F6@rfc-editor.org> Date: Sat, 13 Nov 2010 13:33:56 -0800 (PST) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org, rtrmtrx@gmail.com Subject: [OSPF] [Editorial Errata Reported] RFC2328 (2632) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 21:33:27 -0000 The following errata report has been submitted for RFC2328, "OSPF Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=2632 -------------------------------------- Type: Editorial Reported by: Dave Cowley Section: 11. Original Text ------------- Cost The link state cost of the path to the destination. For all paths except type 2 external paths this describes the entire path's cost. For Type 2 external paths, this field describes the cost of the portion of the path internal to the AS. Corrected Text -------------- Cost The link state cost of the path to the destination. For all paths except type 2 external paths this describes the entire path's cost. For Type 1 external paths, this field describes the cost of the portion of the path both internal and external to the AS. Notes ----- 'Type 2 cost' is listed in the subsequent 'field' description for section 11 (The Routing Table Structure). 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. -------------------------------------- RFC2328 (no draft string recorded) -------------------------------------- Title : OSPF Version 2 Publication Date : April 1998 Author(s) : J. Moy Category : STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From dkatz@juniper.net Sat Nov 13 18:49:29 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112E63A6862 for ; Sat, 13 Nov 2010 18:49:29 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn4JP0vNIlGf for ; Sat, 13 Nov 2010 18:49:21 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 7308C3A6B40 for ; Sat, 13 Nov 2010 18:49:18 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTN9OUN+NWhQ0w8ZOwxDmWJ7jH9eRSHAZ@postini.com; Sat, 13 Nov 2010 18:49:58 PST Received: from merlot.juniper.net (172.17.27.10) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 13 Nov 2010 18:49:51 -0800 Received: from sa-nc-ipg-172-23-0-181.static.jnpr.net (sa-nc-ipg-172-23-0-181.static.jnpr.net [172.23.0.181]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id oAE2nnb69367; Sat, 13 Nov 2010 18:49:49 -0800 (PST) (envelope-from dkatz@juniper.net) MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: <20101113213356.B5764E06F6@rfc-editor.org> Date: Sat, 13 Nov 2010 18:49:49 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <186AAF5B-5E02-47DF-9DA3-2EC8C82D366C@juniper.net> References: <20101113213356.B5764E06F6@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1082) Cc: jmoy@casc.com, rtrmtrx@gmail.com, ospf@ietf.org, adrian.farrel@huawei.com, acee@redback.com Subject: Re: [OSPF] [Editorial Errata Reported] RFC2328 (2632) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2010 02:49:29 -0000 Um, there's nothing wrong with the original text. This erratum is = erroneous. The "Cost" field described is the intra-AS cost of the path; for all = but type-2 externals, the internal cost *is* the total path cost. For = type-2 externals, the internal cost is...the internal cost, and is = ultimately discarded. --Dave On Nov 13, 2010, at 1:33 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC2328, > "OSPF Version 2". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D2328&eid=3D2632 >=20 > -------------------------------------- > Type: Editorial > Reported by: Dave Cowley >=20 > Section: 11. >=20 > Original Text > ------------- > Cost > The link state cost of the path to the destination. For all > paths except type 2 external paths this describes the entire > path's cost. For Type 2 external paths, this field describes > the cost of the portion of the path internal to the AS.=20 >=20 > Corrected Text > -------------- > Cost > The link state cost of the path to the destination. For all > paths except type 2 external paths this describes the entire > path's cost. For Type 1 external paths, this field describes > the cost of the portion of the path both internal and external > to the AS. =20 >=20 > Notes > ----- > 'Type 2 cost' is listed in the subsequent 'field' description for = section 11 (The Routing Table Structure). >=20 > 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.=20 >=20 > -------------------------------------- > RFC2328 (no draft string recorded) > -------------------------------------- > Title : OSPF Version 2 > Publication Date : April 1998 > Author(s) : J. Moy > Category : 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 >=20 From acee.lindem@ericsson.com Sun Nov 14 15:05:10 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3C253A6C53 for ; Sun, 14 Nov 2010 15:05:09 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jyIu-C5wJuE for ; Sun, 14 Nov 2010 15:05:03 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 119CB3A6924 for ; Sun, 14 Nov 2010 15:05:02 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oAENTvMM019442; Sun, 14 Nov 2010 17:30:03 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 14 Nov 2010 18:05:39 -0500 From: Acee Lindem To: RFC Errata System Date: Sun, 14 Nov 2010 18:05:37 -0500 Thread-Topic: [OSPF] [Editorial Errata Reported] RFC2328 (2632) (Copying OSPF list) Thread-Index: AcuEUHRAS1RdD1UKTDW2D9/i9GKV5w== Message-ID: <1B061E4D-BAFF-443C-A025-DF7F2C057F55@ericsson.com> References: <20101113213356.B5764E06F6@rfc-editor.org> In-Reply-To: <20101113213356.B5764E06F6@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 Cc: "ospf@ietf.org" Subject: Re: [OSPF] [Editorial Errata Reported] RFC2328 (2632) (Copying OSPF list) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2010 23:05:10 -0000 This errata is incorrect and should not be applied. The description of cost= is correct the way it is and this change would only confuse the distinctio= n between "Cost" and "Type 2 Cost".=20 Thanks, Acee On Nov 13, 2010, at 4:33 PM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC2328, > "OSPF Version 2". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D2328&eid=3D2632 >=20 > -------------------------------------- > Type: Editorial > Reported by: Dave Cowley >=20 > Section: 11. >=20 > Original Text > ------------- > Cost > The link state cost of the path to the destination. For all > paths except type 2 external paths this describes the entire > path's cost. For Type 2 external paths, this field describes > the cost of the portion of the path internal to the AS.=20 >=20 > Corrected Text > -------------- > Cost > The link state cost of the path to the destination. For all > paths except type 2 external paths this describes the entire > path's cost. For Type 1 external paths, this field describes > the cost of the portion of the path both internal and external > to the AS. =20 >=20 > Notes > ----- > 'Type 2 cost' is listed in the subsequent 'field' description for section= 11 (The Routing Table Structure). >=20 > 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.=20 >=20 > -------------------------------------- > RFC2328 (no draft string recorded) > -------------------------------------- > Title : OSPF Version 2 > Publication Date : April 1998 > Author(s) : J. Moy > Category : 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 p6c6d6@gmail.com Sun Nov 14 18:38:05 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775D93A693A for ; Sun, 14 Nov 2010 18:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onLZLZ5Uy2I7 for ; Sun, 14 Nov 2010 18:38:04 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 3AA0F3A6C64 for ; Sun, 14 Nov 2010 18:37:52 -0800 (PST) Received: by pwj2 with SMTP id 2so1245556pwj.31 for ; Sun, 14 Nov 2010 18:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=zuewB3iAMFQPgYNNCZxBAGLaWWsKs9kIKMool3MZTTI=; b=vFvIyC07M82XLKJ0BxkM8DNKPy4tYTVX8Qbp8Kg/jEtKocOu6joiXiEbbedBBpKooK fUJDeSjSjInVg3uQue2Bhj5PeOth85P6RvcwbUuSEQPqZetHaWzgy3V5q4gM3GRYho8h heVZxsrR6MIBcMH0VzAe3OtH7DA/ne+vu80Qc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DN/y1sEBxA/QkISvoWwZprJ9DbrmX0siiwVw5uFb1ZLbAvRJHr+qhtmfO7EhMmoxcC Ug7TvUgMUFuxCT5U4T936wcJBYnOJ1GEyR5PJJiTdWkdsfgnS6Aq3P2aH5steGILeAx+ 0R4dcTRWlZqBIuXL5nUqMc7QrqsyW2FdXOq+Q= MIME-Version: 1.0 Received: by 10.142.136.2 with SMTP id j2mr4585093wfd.103.1289788712049; Sun, 14 Nov 2010 18:38:32 -0800 (PST) Received: by 10.143.14.10 with HTTP; Sun, 14 Nov 2010 18:38:32 -0800 (PST) Date: Mon, 15 Nov 2010 08:08:32 +0530 Message-ID: From: p6 c6d6 To: ospf@ietf.org Content-Type: multipart/alternative; boundary=000e0cd31376045d9b04950e5623 Subject: [OSPF] nexthop address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 02:38:05 -0000 --000e0cd31376045d9b04950e5623 Content-Type: text/plain; charset=ISO-8859-1 hi, what would be the nexthop ip address for a directly connected broadcast network. thanks --000e0cd31376045d9b04950e5623 Content-Type: text/html; charset=ISO-8859-1 hi,

what would be the nexthop ip address for a directly connected broadcast network.

thanks

--000e0cd31376045d9b04950e5623-- From p6c6d6@gmail.com Sun Nov 14 18:46:41 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458E63A6B4C for ; Sun, 14 Nov 2010 18:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRG5wmqPt0xo for ; Sun, 14 Nov 2010 18:46:40 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 77C5D3A6A38 for ; Sun, 14 Nov 2010 18:46:40 -0800 (PST) Received: by pzk10 with SMTP id 10so420130pzk.31 for ; Sun, 14 Nov 2010 18:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=v8QPQTBFeSlyLmErzW0KitsaUvSgUE5T+kgHrSHuJLA=; b=Px/Df/Z875aEaM1/1luxTu723GlE741XgT/GiV7Fj9E+HSPNKHb4Dn1TFmKFW96gLo TFtQxX/hyODky0bLcpydTzKsBtK65Xu0+ObdJJo7ezH6owKWJdegMdxtLSL+BNzlkv10 bSQMaFwNRUyr60qSNwPXF2LA3VmIjIa3iGKzw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JosO/6CTM8qDUoBTVAsg8W1Y4TSGAO1sdHo08+v02JtM3p+S7wo2KXL07fWhpsokyE d3iy6aC25/VCUPqoVvHWEjNnrIiYQ7L5gRDrpCgKsly+pm/qcYIQIT+v968OuYAZ/G5B ukdnCVKsXPaBrMz8QVTdBW2xmMjK1uiaE8Gio= MIME-Version: 1.0 Received: by 10.142.178.4 with SMTP id a4mr1356438wff.274.1289789240403; Sun, 14 Nov 2010 18:47:20 -0800 (PST) Received: by 10.143.14.10 with HTTP; Sun, 14 Nov 2010 18:47:20 -0800 (PST) Date: Mon, 15 Nov 2010 08:17:20 +0530 Message-ID: From: p6 c6d6 To: ospf@ietf.org Content-Type: multipart/alternative; boundary=000e0cd2418682673704950e75ad Subject: [OSPF] transit summary lsas X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 02:46:41 -0000 --000e0cd2418682673704950e75ad Content-Type: text/plain; charset=ISO-8859-1 hi, why should one recalculate routes using transit areas summary lsas, even if better paths exist through transit area. as a virtual link is considered as an unumbered p2p link, it is as good as the router has an interface to the backbone. referring to rfc2328 figure 17, RT1 chooses route network N1 through RT4, since that is an intra-area path, that is in accordance to the path preference rules of ospf. why do we give special treatment for transit areas. If the link were not a virtual-link and if it indeed is real p2p interface in to the backbone, we will not try to route the data to N1 through RT5, since the route through RT4 would be preferred. why special treatment for transit areas, and why can't we extend this treatment to other areas as well (neglecting the fact that area routing is protected by bad routing of other areas). thanks in advance --000e0cd2418682673704950e75ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,

why should one recalculate routes using transit areas summary ls= as, even if
better paths exist through transit area.=A0 as a virtual lin= k is considered as
an unumbered p2p link, it is as good as the router ha= s an interface to the backbone.
referring to rfc2328 figure 17, RT1 chooses route network N1 through RT4, s= ince that
is an intra-area path, that is in accordance to the path prefe= rence rules of ospf.
why do we give special treatment for transit areas= . If the link were not a virtual-link and
if it indeed is real p2p interface in to the backbone, we will not try to r= oute the data to N1
through RT5, since the route through RT4 would be pr= eferred. why special treatment for
transit areas, and why can't we e= xtend this treatment to other areas as well (neglecting
the fact that area routing is protected by bad routing of other areas).
=
thanks in advance


--000e0cd2418682673704950e75ad-- From acee.lindem@ericsson.com Mon Nov 15 01:45:00 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5853A6B80 for ; Mon, 15 Nov 2010 01:45:00 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssPtXJZRt2Ch for ; Mon, 15 Nov 2010 01:44:59 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 6FF813A6ABE for ; Mon, 15 Nov 2010 01:44:58 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oAF9ja20021037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Nov 2010 03:45:36 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 15 Nov 2010 04:45:35 -0500 From: Acee Lindem To: p6 c6d6 Date: Mon, 15 Nov 2010 04:45:33 -0500 Thread-Topic: [OSPF] nexthop address Thread-Index: AcuEqdo4KgIo8dAqRZ6s/R6EzZVmqg== Message-ID: <1F054C21-3D77-449F-8A8F-56E2BF212728@ericsson.com> References: In-Reply-To: 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 Cc: "ospf@ietf.org" Subject: Re: [OSPF] nexthop address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 09:45:00 -0000 This is implementation dependent. In any case, you should have a more prefe= rred non-OSPF connected route based. Acee=20 On Nov 14, 2010, at 9:38 PM, p6 c6d6 wrote: > hi, >=20 > what would be the nexthop ip address for a directly connected broadcast n= etwork. >=20 > thanks >=20 > From acee.lindem@ericsson.com Mon Nov 15 01:49:58 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814433A69C6 for ; Mon, 15 Nov 2010 01:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHVSv9LHmpPw for ; Mon, 15 Nov 2010 01:49:56 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 08D373A69B9 for ; Mon, 15 Nov 2010 01:49:55 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oAFAF1Ra030973; Mon, 15 Nov 2010 04:15:03 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 15 Nov 2010 04:50:32 -0500 From: Acee Lindem To: p6 c6d6 Date: Mon, 15 Nov 2010 04:50:29 -0500 Thread-Topic: [OSPF] transit summary lsas Thread-Index: AcuEqopETi3qrAYFTiSMLW7N3QfQ9Q== Message-ID: <9470DFAC-1E17-4CC5-8227-513A8E456876@ericsson.com> References: In-Reply-To: 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 Cc: "ospf@ietf.org" Subject: Re: [OSPF] transit summary lsas X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 09:49:58 -0000 This is due to the fact that paths via transit area ABRs other than the vir= tual link endpoints can be installed. If I were designing a link-state prot= ocol from scratch, I would not include the complexity of virtual links as t= hey are specified in OSPF.=20 Hope this helps, Acee=20 On Nov 14, 2010, at 9:47 PM, p6 c6d6 wrote: > hi, >=20 > why should one recalculate routes using transit areas summary lsas, even = if > better paths exist through transit area. as a virtual link is considered= as > an unumbered p2p link, it is as good as the router has an interface to th= e backbone. > referring to rfc2328 figure 17, RT1 chooses route network N1 through RT4,= since that > is an intra-area path, that is in accordance to the path preference rules= of ospf.=20 > why do we give special treatment for transit areas. If the link were not = a virtual-link and > if it indeed is real p2p interface in to the backbone, we will not try to= route the data to N1 > through RT5, since the route through RT4 would be preferred. why special = treatment for > transit areas, and why can't we extend this treatment to other areas as w= ell (neglecting > the fact that area routing is protected by bad routing of other areas). >=20 > thanks in advance >=20 >=20 > From glen.kent@gmail.com Mon Nov 15 07:15:05 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14DBE28C131 for ; Mon, 15 Nov 2010 07:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFsv98gh2M-N for ; Mon, 15 Nov 2010 07:15:04 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id C4F3928C15F for ; Mon, 15 Nov 2010 07:14:56 -0800 (PST) Received: by ewy27 with SMTP id 27so3045288ewy.31 for ; Mon, 15 Nov 2010 07:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=11pKXTUUqOuAJi6XwpxWtH7lR+SVCrKpcW7gP531d/k=; b=ZA4thNQUdAOsBVo7+wXRI45MO2q8nXqR+K7C2M0w3FT6EIH9fbGYdRcyvjn5+CuoHP d0ZrEomYLnZ64jcifvryC//+/wMarCAaNCHB3wf05e2fG9hZURJE8GdJ16zmnFF2Fbl/ NE9asFOcJSbgM0Ph2TBD9JGWK/TlNqa3Dc8sI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wlKabDdb37fSQ/SV4GvyJ9xD1GYzQYZUN5LKtGn6tAR8HbmKYwygS12wDmX06IvHJo 9eKqK3sUJpZKCKAMVza/UCXb5mAcIe67L8nSmYXEsHYVk8dItUpOpC7vriC1YwnYmoyb qy4GO0OQwnMZpkiEn0pytS4apwaEidKc0GnGk= MIME-Version: 1.0 Received: by 10.14.53.67 with SMTP id f43mr4127429eec.25.1289834137405; Mon, 15 Nov 2010 07:15:37 -0800 (PST) Received: by 10.14.127.138 with HTTP; Mon, 15 Nov 2010 07:15:37 -0800 (PST) Date: Mon, 15 Nov 2010 20:45:37 +0530 Message-ID: From: Glen Kent To: ospf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OSPF] OSPF IETF Meeting X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 15:15:05 -0000 (1) While i understand the need to speed up the OSPF adjacency formation process, i somehow dont think that the mechanism described in draft-dimitri-ospf-phased-db-sync-00.txt is good enough. It looks a little tenuous and appears unscalable. I would like to compare this vis-a-vis the transport mechanism that has been proposed by some other folks, since that too attempts to achieve the same thing. (2) I support draft-yang-ospf-hiding-00.txt and i think its makes sense to progress this draft. (3) I also support draft-bhatia-manral-auth-trailer-ospfv3-01, and i think there clearly is a need to move away from IPsec security for OSPFv3. (4) I am not comfortable with draft-bhatia-karp-ospf-ip-layer-protection-00.txt, as it currently stands. While i understand that the author of this draft was one of the co-authors of RFC 5709, i would like to first understand the rationale behind introducing Apad in the crypto computation as has been described in 5709. Thats clearly not a part of the original HMAC specification. The authors have modified that without giving any explanation in 5709, and i think its best that we first understand why that change was introduced before we accept any changes (or enhancements if you will) to it. (5) draft-kini-ospf-fast-notification-00.txt looks interesting and i would like to see some more discussions on it. I dont think its currently at a maturity level where it can be progressed, but a discussion would nevertheless be good. Glen From p6c6d6@gmail.com Mon Nov 15 18:42:05 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE693A6A8E for ; Mon, 15 Nov 2010 18:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyM0TVtMCwzb for ; Mon, 15 Nov 2010 18:42:04 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id E3E2D3A6A3C for ; Mon, 15 Nov 2010 18:42:03 -0800 (PST) Received: by pvc21 with SMTP id 21so34130pvc.31 for ; Mon, 15 Nov 2010 18:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=pbB1QMxP8tG17EVnHJcJYMmiMuH1SfGIRNwBasKMADk=; b=eL3EdLe4cL9MkJVOYQOJ1DGD6FK/4j9XB6HYxKcng6YiNnWFvOYFEMkeTj810fwO+4 OxcMpjPpHChRxmv9K4t6qloPsahe993xh4ZdHebU+u28+KOmO5Ko+PY4Lcn0BR85ghvm uDSb3uHKIKp+nVZ07jjo6s3svGNRPy0qJF11I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=A+4PcKWAlvgJ/rBuwHd0d9qkfVSM9CNL3uuzE+13jkUxf/8s+x+85D8TguVW85W52v Itqi6jfh3pvaMiQ+pUB5klL5yJyrW4EAtkXGETFmUclN3MnUo8wZ5kUdoxZg8mwyfWKy N8XoIH3w9PTTzBaSycMBFu+I+cGylbCyTlXL8= MIME-Version: 1.0 Received: by 10.143.16.13 with SMTP id t13mr5093995wfi.46.1289875366675; Mon, 15 Nov 2010 18:42:46 -0800 (PST) Received: by 10.143.14.10 with HTTP; Mon, 15 Nov 2010 18:42:46 -0800 (PST) In-Reply-To: References: <9470DFAC-1E17-4CC5-8227-513A8E456876@ericsson.com> Date: Tue, 16 Nov 2010 08:12:46 +0530 Message-ID: From: p6 c6d6 To: ospf@ietf.org Content-Type: multipart/alternative; boundary=001636e8ff4009057e04952283ea Subject: [OSPF] Fwd: transit summary lsas X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 02:42:05 -0000 --001636e8ff4009057e04952283ea Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 15, 2010 at 3:20 PM, Acee Lindem wrote: > > This is due to the fact that paths via transit area ABRs other than the > virtual link endpoints can be installed. If I were designing a link-state > protocol from scratch, I would not include the complexity of virtual links > as they are specified in OSPF. > > Hope this helps, > Acee > > On Nov 14, 2010, at 9:47 PM, p6 c6d6 wrote: > > > hi, > > > > why should one recalculate routes using transit areas summary lsas, even > if > > better paths exist through transit area. as a virtual link is considered > as > > an unumbered p2p link, it is as good as the router has an interface to > the backbone. > > referring to rfc2328 figure 17, RT1 chooses route network N1 through RT4, > since that > > is an intra-area path, that is in accordance to the path preference rules > of ospf. > > why do we give special treatment for transit areas. If the link were not > a virtual-link and > > if it indeed is real p2p interface in to the backbone, we will not try to > route the data to N1 > > through RT5, since the route through RT4 would be preferred. why special > treatment for > > transit areas, and why can't we extend this treatment to other areas as > well (neglecting > > the fact that area routing is protected by bad routing of other areas). > > > > thanks in advance > > > > > > > > oh is it. i thought virtual links is a good idea. and for the newly calculated route why do we have to use the associated area as backbone area though the path is still through transit area ? --001636e8ff4009057e04952283ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<= div class=3D"h5">On Mon, Nov 15, 2010 at 3:20 PM, Acee Lindem <acee= .lindem@ericsson.com> wrote:

This is due to the fact that paths via transit area ABRs other than the vir= tual link endpoints can be installed. If I were designing a link-state prot= ocol from scratch, I would not include the complexity of virtual links as t= hey are specified in OSPF.

Hope this helps,
Acee

On Nov 14, 2010, at 9:47 PM, p6 c6d6 wrote:

> hi,
>
> why should one recalculate routes using transit areas summary lsas, ev= en if
> better paths exist through transit area. =A0as a virtual link is consi= dered as
> an unumbered p2p link, it is as good as the router has an interface to= the backbone.
> referring to rfc2328 figure 17, RT1 chooses route network N1 through R= T4, since that
> is an intra-area path, that is in accordance to the path preference ru= les of ospf.
> why do we give special treatment for transit areas. If the link were n= ot a virtual-link and
> if it indeed is real p2p interface in to the backbone, we will not try= to route the data to N1
> through RT5, since the route through RT4 would be preferred. why speci= al treatment for
> transit areas, and why can't we extend this treatment to other are= as as well (neglecting
> the fact that area routing is protected by bad routing of other areas)= .
>
> thanks in advance
>
>
> <ATT00001..txt>


oh is it. i thought virtual links is = a good idea.
and for the newly calculated route=A0 why do we
have to= use the associated area as backbone area
though the path is still throu= gh transit area ?


--001636e8ff4009057e04952283ea-- From acee.lindem@ericsson.com Mon Nov 15 18:43:55 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C7E3A6D8E for ; Mon, 15 Nov 2010 18:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPQOPUrwAuNi for ; Mon, 15 Nov 2010 18:43:53 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id BBBF43A6D8F for ; Mon, 15 Nov 2010 18:43:53 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oAG39BPS006367; Mon, 15 Nov 2010 21:09:12 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 15 Nov 2010 21:44:32 -0500 From: Acee Lindem To: p6 c6d6 Date: Mon, 15 Nov 2010 21:44:30 -0500 Thread-Topic: [OSPF] Fwd: transit summary lsas Thread-Index: AcuFODI5rfRxbgPVS7+LY9ew71miog== Message-ID: <45CD256D-EA9C-407C-9BE0-A2C064E8102C@ericsson.com> References: <9470DFAC-1E17-4CC5-8227-513A8E456876@ericsson.com> In-Reply-To: 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 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Fwd: transit summary lsas X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 02:43:55 -0000 p6c6d6 - see inline. On Nov 15, 2010, at 9:42 PM, p6 c6d6 wrote: On Mon, Nov 15, 2010 at 3:20 PM, Acee Lindem > wrote: This is due to the fact that paths via transit area ABRs other than the vir= tual link endpoints can be installed. If I were designing a link-state prot= ocol from scratch, I would not include the complexity of virtual links as t= hey are specified in OSPF. Hope this helps, Acee On Nov 14, 2010, at 9:47 PM, p6 c6d6 wrote: > hi, > > why should one recalculate routes using transit areas summary lsas, even = if > better paths exist through transit area. as a virtual link is considered= as > an unumbered p2p link, it is as good as the router has an interface to th= e backbone. > referring to rfc2328 figure 17, RT1 chooses route network N1 through RT4,= since that > is an intra-area path, that is in accordance to the path preference rules= of ospf. > why do we give special treatment for transit areas. If the link were not = a virtual-link and > if it indeed is real p2p interface in to the backbone, we will not try to= route the data to N1 > through RT5, since the route through RT4 would be preferred. why special = treatment for > transit areas, and why can't we extend this treatment to other areas as w= ell (neglecting > the fact that area routing is protected by bad routing of other areas). > > thanks in advance > > > oh is it. i thought virtual links is a good idea. and for the newly calculated route why do we have to use the associated area as backbone area though the path is still through transit area ? Because the virtual link is part of the backbone. Acee From asmirnov@cisco.com Tue Nov 16 01:55:38 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCB93A6C9C for ; Tue, 16 Nov 2010 01:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYmQ6cuO3dTz for ; Tue, 16 Nov 2010 01:55:38 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 9B4F43A6C78 for ; Tue, 16 Nov 2010 01:55:37 -0800 (PST) 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 oAG9qY8V018118; Tue, 16 Nov 2010 10:52:34 +0100 (CET) Received: from [10.55.140.84] (ams-asmirnov-8713.cisco.com [10.55.140.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAG9qXan018540; Tue, 16 Nov 2010 10:52:34 +0100 (CET) Message-ID: <4CE25469.8020808@cisco.com> Date: Tue, 16 Nov 2010 10:52:41 +0100 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101026 SUSE/3.0.10 Thunderbird/3.0.10 MIME-Version: 1.0 To: p6 c6d6 References: <9470DFAC-1E17-4CC5-8227-513A8E456876@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: Re: [OSPF] Fwd: transit summary lsas X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 09:55:38 -0000 > oh is it. i thought virtual links is a good idea. Virtual links is just a hack to overcome some most obvious consequences of limiting area hierarchy to be 1 level deep (backbone as root and everything else is leaf). In the long term hacks rarely make any good. I agree with Acee, on new design it would have been better to place complexity somewhere else. For example, in allowing true area hierarchy. Anton On 11/16/2010 03:42 AM, p6 c6d6 wrote: > > On Mon, Nov 15, 2010 at 3:20 PM, Acee Lindem > wrote: > > > This is due to the fact that paths via transit area ABRs other than > the virtual link endpoints can be installed. If I were designing a > link-state protocol from scratch, I would not include the complexity > of virtual links as they are specified in OSPF. > > Hope this helps, > Acee > > On Nov 14, 2010, at 9:47 PM, p6 c6d6 wrote: > > > hi, > > > > why should one recalculate routes using transit areas summary > lsas, even if > > better paths exist through transit area. as a virtual link is > considered as > > an unumbered p2p link, it is as good as the router has an > interface to the backbone. > > referring to rfc2328 figure 17, RT1 chooses route network N1 > through RT4, since that > > is an intra-area path, that is in accordance to the path > preference rules of ospf. > > why do we give special treatment for transit areas. If the link > were not a virtual-link and > > if it indeed is real p2p interface in to the backbone, we will not > try to route the data to N1 > > through RT5, since the route through RT4 would be preferred. why > special treatment for > > transit areas, and why can't we extend this treatment to other > areas as well (neglecting > > the fact that area routing is protected by bad routing of other > areas). > > > > thanks in advance > > > > > > > > > oh is it. i thought virtual links is a good idea. > and for the newly calculated route why do we > have to use the associated area as backbone area > though the path is still through transit area ? > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From keshavaak@huawei.com Tue Nov 16 02:33:49 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08FC43A6C56 for ; Tue, 16 Nov 2010 02:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKTAwlxO9UUv for ; Tue, 16 Nov 2010 02:33:47 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A82653A6DA1 for ; Tue, 16 Nov 2010 02:33:46 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBZ00BWK3ZVF8@szxga03-in.huawei.com> for ospf@ietf.org; Tue, 16 Nov 2010 18:33:31 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBZ006123ZV5B@szxga03-in.huawei.com> for ospf@ietf.org; Tue, 16 Nov 2010 18:33:31 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBZ00GFU3ZU1W@szxml04-in.huawei.com> for ospf@ietf.org; Tue, 16 Nov 2010 18:33:31 +0800 (CST) Date: Tue, 16 Nov 2010 16:03:29 +0530 From: "Keshava.Ayanur" To: ospf@ietf.org Message-id: <51950498A7304D73840906E37A8C5C59@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_+u1SYvzFdPUcdq2sw1EjIA)" Thread-index: AcuFebXVg9sCt5n+R6u1QhAKFRIt+g== Subject: [OSPF] OSPF::aggregating huge number 'summary LSA" originated AT PE .. X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 10:33:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+u1SYvzFdPUcdq2sw1EjIA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Any thoughts about aggregating the "Summary LSA's' originated in PE which was redistributed from BGP . Regards, Keshava.A.K. --Boundary_(ID_+u1SYvzFdPUcdq2sw1EjIA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,=

 

Any thoughts about aggregating the “Summary = LSA’s’ originated in PE which was redistributed from BGP = .

 

Regards,

Keshava.A.K.

--Boundary_(ID_+u1SYvzFdPUcdq2sw1EjIA)-- From ppsenak@cisco.com Tue Nov 16 03:26:18 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9607F3A6DE0 for ; Tue, 16 Nov 2010 03:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FU9dJox1PjpG for ; Tue, 16 Nov 2010 03:26:17 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 961153A6DDF for ; Tue, 16 Nov 2010 03:26:17 -0800 (PST) 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 oAGBFgZe000199; Tue, 16 Nov 2010 12:15:42 +0100 (CET) Received: from dhcp-10-61-101-134.cisco.com (dhcp-10-61-101-134.cisco.com [10.61.101.134]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAGBFgSR026937; Tue, 16 Nov 2010 12:15:42 +0100 (CET) Message-ID: <4CE267DE.5050407@cisco.com> Date: Tue, 16 Nov 2010 12:15:42 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Keshava.Ayanur" References: <51950498A7304D73840906E37A8C5C59@china.huawei.com> In-Reply-To: <51950498A7304D73840906E37A8C5C59@china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF::aggregating huge number 'summary LSA" originated AT PE .. X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 11:26:18 -0000 Keshava, it's up to the implementation how it handles the aggregation of the BGP redistributed prefixes on PE. The most obvious choice is to treat it the same way as regular redistribution in which case an external LSA is generated for the summary itself. RFC4577 only specifies the behavior when no aggregation is done on PE: In the following, we specify what is reported, in OSPF LSAs, by the PE to the CE, assuming that the PE is not configured to do any further summarization or filtering of the routing information before reporting it to the CE." thanks, Peter On 16.11.2010 11:33, Keshava.Ayanur wrote: > Hi, > > Any thoughts about aggregating the “Summary LSA’s’ originated in PE > which was redistributed from BGP . > > Regards, > > Keshava.A.K. > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Tue Nov 16 08:13:40 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44EA63A6CB1 for ; Tue, 16 Nov 2010 08:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.46 X-Spam-Level: X-Spam-Status: No, score=-4.46 tagged_above=-999 required=5 tests=[AWL=2.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OvBS7WaOYOO for ; Tue, 16 Nov 2010 08:13:39 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 592183A6CA6 for ; Tue, 16 Nov 2010 08:13:39 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id oAGGEIYL016958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Nov 2010 10:14:21 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id oAGGEG8J004631 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 Nov 2010 21:44:17 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 16 Nov 2010 21:44:16 +0530 From: "Bhatia, Manav (Manav)" To: Glen Kent Date: Tue, 16 Nov 2010 21:44:14 +0530 Thread-Topic: [OSPF] OSPF IETF Meeting Thread-Index: AcuE2A09YzdGbmdsTI6MkzsT7VhFaAAy/Izw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFA964BED@INBANSXCHMBSA1.in.alcatel-lucent.com> References: In-Reply-To: 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.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF IETF Meeting X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 16:13:40 -0000 Glen, =20 >=20 > (3) I also support draft-bhatia-manral-auth-trailer-ospfv3-01, and i > think there clearly is a need to move away from IPsec security for > OSPFv3. Thanks! I believe we have a good consensus on this draft. We have seen support on t= he mailing list earlier and the folks who were there in Beijing. >=20 > (4) I am not comfortable with > draft-bhatia-karp-ospf-ip-layer-protection-00.txt, as it currently > stands. While i understand that the author of this draft was one of > the co-authors of RFC 5709, i would like to first understand the > rationale behind introducing Apad in the crypto computation as has > been described in 5709. Thats clearly not a part of the original HMAC > specification. The authors have modified that without giving any > explanation in 5709, and i think its best that we first understand why > that change was introduced before we accept any changes (or > enhancements if you will) to it. We were categorically told that NIST wanted to see the construction (using = Authentication Pad (Apad)) that we have finally used in RFC 5310 and RFC 57= 09. Given that NIST owns the Secure Hash Standard family of algorithms that= we're using in these standards it makes sense to follow NIST's instruction= s. Compliance with NIST cryptographic modes, and general cryptographic guidanc= e is a practical market requirement when creating a specification that uses= NIST standard algorithms, regardless of whether one likes or dislikes part= icular choices that NIST has made. If these specifications were *not* using a NIST algorithm, then NIST's view= s could be ignored, but not when youre working with a NIST standard algorit= hm. Hope this helps. Cheers, Manav= From acee.lindem@ericsson.com Tue Nov 16 10:05:55 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80F63A6C89 for ; Tue, 16 Nov 2010 10:05:55 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTccKUNkF+r8 for ; Tue, 16 Nov 2010 10:05:55 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id DE2C83A6DC3 for ; Tue, 16 Nov 2010 10:05:54 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oAGIV9AW018224 for ; Tue, 16 Nov 2010 12:31:23 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 16 Nov 2010 13:06:30 -0500 From: Acee Lindem To: "ospf@ietf.org" Date: Tue, 16 Nov 2010 13:06:28 -0500 Thread-Topic: IETF 79 OSPF WG Minutes Thread-Index: AcuFuP4iDX9Tpw4tROGwZ9QaC2TIdw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] IETF 79 OSPF WG Minutes X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 18:05:55 -0000 I've posted the minutes for the OSPF WG meeting in Beijing. Thanks to Brian= Weiss from Cisco for acting as scribe.=20 Here is the link:=20 http://www.ietf.org/proceedings/79/minutes/ospf.txt Thanks, Acee= From rajeshsm@huawei.com Tue Nov 16 21:07:08 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463533A6850 for ; Tue, 16 Nov 2010 21:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+qoMqBVjUdZ for ; Tue, 16 Nov 2010 21:07:06 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BDD3E3A67E4 for ; Tue, 16 Nov 2010 21:07:06 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC0006EIJKT6K@szxga04-in.huawei.com> for ospf@ietf.org; Wed, 17 Nov 2010 13:07:41 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC0006UCJKTXA@szxga04-in.huawei.com> for ospf@ietf.org; Wed, 17 Nov 2010 13:07:41 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LC000HDJJKSGG@szxml06-in.huawei.com> for ospf@ietf.org; Wed, 17 Nov 2010 13:07:41 +0800 (CST) Date: Wed, 17 Nov 2010 10:37:40 +0530 From: Rajesh Shetty In-reply-to: <4CE267DE.5050407@cisco.com> To: 'Peter Psenak' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcuFgTlfCPst6xkHRoqYWwhUEA3QzwAkCzUg References: <51950498A7304D73840906E37A8C5C59@china.huawei.com> <4CE267DE.5050407@cisco.com> Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF::aggregating huge number 'summary LSA" originated AT PE .. X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 05:07:08 -0000 Peter, When PE report the route as Type3 LSA to CE (redistributed, might be huge in number), In this scenario is there a good mechanism to aggregate Type3 LSAs at PE before sending to CE. For such kind of Type3 Aggregation should we use backbone area range since PE router is considered as integral part of OSPF backbone? Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Peter Psenak Sent: Tuesday, November 16, 2010 4:46 PM To: Keshava.Ayanur Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF::aggregating huge number 'summary LSA" originated AT PE .. Keshava, it's up to the implementation how it handles the aggregation of the BGP redistributed prefixes on PE. The most obvious choice is to treat it the same way as regular redistribution in which case an external LSA is generated for the summary itself. RFC4577 only specifies the behavior when no aggregation is done on PE: In the following, we specify what is reported, in OSPF LSAs, by the PE to the CE, assuming that the PE is not configured to do any further summarization or filtering of the routing information before reporting it to the CE." thanks, Peter On 16.11.2010 11:33, Keshava.Ayanur wrote: > Hi, > > Any thoughts about aggregating the "Summary LSA's' originated in PE > which was redistributed from BGP . > > Regards, > > Keshava.A.K. > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From keshavaak@huawei.com Tue Nov 16 22:46:26 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9D53A680E for ; Tue, 16 Nov 2010 22:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MI42jJa6SDO for ; Tue, 16 Nov 2010 22:46:24 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4A8B23A680C for ; Tue, 16 Nov 2010 22:46:24 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC0006DIO576K@szxga04-in.huawei.com> for ospf@ietf.org; Wed, 17 Nov 2010 14:46:19 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC00018YO57D5@szxga04-in.huawei.com> for ospf@ietf.org; Wed, 17 Nov 2010 14:46:19 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LC000MXLO561Y@szxml04-in.huawei.com> for ospf@ietf.org; Wed, 17 Nov 2010 14:46:19 +0800 (CST) Date: Wed, 17 Nov 2010 12:16:17 +0530 From: "Keshava.Ayanur" In-reply-to: To: 'Rajesh Shetty' , 'Peter Psenak' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcuFgTlfCPst6xkHRoqYWwhUEA3QzwAkCzUgAAQc5iA= References: <51950498A7304D73840906E37A8C5C59@china.huawei.com> <4CE267DE.5050407@cisco.com> Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF::aggregating huge number 'summary LSA" originated AT PE .. X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 06:46:26 -0000 Peter, Instead of leaving this to implementation, it is better to define the exact behavior/rules how to be handled. Else there may be many possibilities like a)aggregation based on backbone area range, b)on area-id map, corresponding area range .. Keshava -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Rajesh Shetty Sent: Wednesday, November 17, 2010 10:38 AM To: 'Peter Psenak' Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF::aggregating huge number 'summary LSA" originated AT PE .. Peter, When PE report the route as Type3 LSA to CE (redistributed, might be huge in number), In this scenario is there a good mechanism to aggregate Type3 LSAs at PE before sending to CE. For such kind of Type3 Aggregation should we use backbone area range since PE router is considered as integral part of OSPF backbone? Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Peter Psenak Sent: Tuesday, November 16, 2010 4:46 PM To: Keshava.Ayanur Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF::aggregating huge number 'summary LSA" originated AT PE .. Keshava, it's up to the implementation how it handles the aggregation of the BGP redistributed prefixes on PE. The most obvious choice is to treat it the same way as regular redistribution in which case an external LSA is generated for the summary itself. RFC4577 only specifies the behavior when no aggregation is done on PE: In the following, we specify what is reported, in OSPF LSAs, by the PE to the CE, assuming that the PE is not configured to do any further summarization or filtering of the routing information before reporting it to the CE." thanks, Peter On 16.11.2010 11:33, Keshava.Ayanur wrote: > Hi, > > Any thoughts about aggregating the "Summary LSA's' originated in PE > which was redistributed from BGP . > > Regards, > > Keshava.A.K. > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ppsenak@cisco.com Wed Nov 17 02:26:29 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456423A68C1 for ; Wed, 17 Nov 2010 02:26:29 -0800 (PST) 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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbDT3i7jizkA for ; Wed, 17 Nov 2010 02:26:28 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id D48123A68A8 for ; Wed, 17 Nov 2010 02:26:27 -0800 (PST) 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 oAHAJbS0024474; Wed, 17 Nov 2010 11:19:38 +0100 (CET) Received: from ams3-vpn-dhcp2547.cisco.com (ams3-vpn-dhcp2547.cisco.com [10.61.73.243]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAHAJbxi010479; Wed, 17 Nov 2010 11:19:37 +0100 (CET) Message-ID: <4CE3AC39.9040404@cisco.com> Date: Wed, 17 Nov 2010 11:19:37 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Keshava.Ayanur" References: <51950498A7304D73840906E37A8C5C59@china.huawei.com> <4CE267DE.5050407@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF::aggregating huge number 'summary LSA" originated AT PE .. X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 10:26:29 -0000 Keshava, I do not see a reason why this needs to be standardized, as this represents a local behavior of the PE and does not pose any interoperability issues. thanks, Peter On 17.11.2010 7:46, Keshava.Ayanur wrote: > Peter, > > Instead of leaving this to implementation, it is better to define the exact > behavior/rules how to be handled. > > Else there may be many possibilities like > a)aggregation based on backbone area range, > b)on area-id map, corresponding area range .. > > Keshava > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Rajesh Shetty > Sent: Wednesday, November 17, 2010 10:38 AM > To: 'Peter Psenak' > Cc: ospf@ietf.org > Subject: Re: [OSPF] OSPF::aggregating huge number 'summary LSA" originated > AT PE .. > > Peter, > > When PE report the route as Type3 LSA to CE (redistributed, might be huge in > number), In this scenario is there a good mechanism to aggregate Type3 LSAs > at PE before sending to CE. > > For such kind of Type3 Aggregation should we use backbone area range since > PE router is considered as integral part of OSPF backbone? > > Thanks > Rajesh > > > > > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Peter Psenak > Sent: Tuesday, November 16, 2010 4:46 PM > To: Keshava.Ayanur > Cc: ospf@ietf.org > Subject: Re: [OSPF] OSPF::aggregating huge number 'summary LSA" originated > AT PE .. > > Keshava, > > it's up to the implementation how it handles the aggregation of the BGP > redistributed prefixes on PE. The most obvious choice is to treat it the > same way as regular redistribution in which case an external LSA is > generated for the summary itself. > > RFC4577 only specifies the behavior when no aggregation is done on PE: > > In the following, we specify what is reported, in OSPF LSAs, by the > PE to the CE, assuming that the PE is not configured to do any > further summarization or filtering of the routing information before > reporting it to the CE." > > thanks, > Peter > > > > On 16.11.2010 11:33, Keshava.Ayanur wrote: >> Hi, >> >> Any thoughts about aggregating the "Summary LSA's' originated in PE >> which was redistributed from BGP . >> >> Regards, >> >> Keshava.A.K. >> >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From acee.lindem@ericsson.com Wed Nov 17 07:06:10 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1BF33A68F6 for ; Wed, 17 Nov 2010 07:06:07 -0800 (PST) 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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRkvweVs9DKh for ; Wed, 17 Nov 2010 07:06:05 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id B22013A6918 for ; Wed, 17 Nov 2010 07:06:04 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oAHFVhtt021459; Wed, 17 Nov 2010 09:31:45 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 17 Nov 2010 10:06:44 -0500 From: Acee Lindem To: Peter Psenak Date: Wed, 17 Nov 2010 10:06:43 -0500 Thread-Topic: [OSPF] OSPF::aggregating huge number 'summary LSA" originated AT PE .. Thread-Index: AcuGaQt3s8SjAsI5SyWhHetMoW5lGw== Message-ID: <5875F8A5-0A55-4D4A-A7B6-4BFB51EAEF6D@ericsson.com> References: <51950498A7304D73840906E37A8C5C59@china.huawei.com> <4CE267DE.5050407@cisco.com> <4CE3AC39.9040404@cisco.com> In-Reply-To: <4CE3AC39.9040404@cisco.com> 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 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF::aggregating huge number 'summary LSA" originated AT PE .. X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 15:06:10 -0000 Hi Peter, Keshava,=20 I agree wholeheartedly with Peter. We've never standardized redistribution = policy in the past and there is no reason to do it now.=20 Thanks, Acee On Nov 17, 2010, at 5:19 AM, Peter Psenak wrote: > Keshava, >=20 > I do not see a reason why this needs to be standardized, as this=20 > represents a local behavior of the PE and does not pose any=20 > interoperability issues. >=20 > thanks, > Peter >=20 > On 17.11.2010 7:46, Keshava.Ayanur wrote: >> Peter, >>=20 >> Instead of leaving this to implementation, it is better to define the ex= act >> behavior/rules how to be handled. >>=20 >> Else there may be many possibilities like >> a)aggregation based on backbone area range, >> b)on area-id map, corresponding area range .. >>=20 >> Keshava >>=20 >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of >> Rajesh Shetty >> Sent: Wednesday, November 17, 2010 10:38 AM >> To: 'Peter Psenak' >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] OSPF::aggregating huge number 'summary LSA" originat= ed >> AT PE .. >>=20 >> Peter, >>=20 >> When PE report the route as Type3 LSA to CE (redistributed, might be hug= e in >> number), In this scenario is there a good mechanism to aggregate Type3 L= SAs >> at PE before sending to CE. >>=20 >> For such kind of Type3 Aggregation should we use backbone area range sin= ce >> PE router is considered as integral part of OSPF backbone? >>=20 >> Thanks >> Rajesh >>=20 >>=20 >>=20 >>=20 >> This e-mail and attachments contain confidential information from HUAWEI= , >> which is intended only for the person or entity whose address is listed >> above. Any use of the information contained herein in any way (including= , >> but not limited to, total or partial disclosure, reproduction, or >> dissemination) by persons other than the intended recipient's) is >> prohibited. If you receive this e-mail in error, please notify the sende= r by >> phone or email immediately and delete it! >>=20 >>=20 >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of >> Peter Psenak >> Sent: Tuesday, November 16, 2010 4:46 PM >> To: Keshava.Ayanur >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] OSPF::aggregating huge number 'summary LSA" originat= ed >> AT PE .. >>=20 >> Keshava, >>=20 >> it's up to the implementation how it handles the aggregation of the BGP >> redistributed prefixes on PE. The most obvious choice is to treat it the >> same way as regular redistribution in which case an external LSA is >> generated for the summary itself. >>=20 >> RFC4577 only specifies the behavior when no aggregation is done on PE: >>=20 >> In the following, we specify what is reported, in OSPF LSAs, by the >> PE to the CE, assuming that the PE is not configured to do any >> further summarization or filtering of the routing information before >> reporting it to the CE." >>=20 >> thanks, >> Peter >>=20 >>=20 >>=20 >> On 16.11.2010 11:33, Keshava.Ayanur wrote: >>> Hi, >>>=20 >>> Any thoughts about aggregating the "Summary LSA's' originated in PE >>> which was redistributed from BGP . >>>=20 >>> Regards, >>>=20 >>> Keshava.A.K. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >>=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From dimitri.papadimitriou@alcatel-lucent.com Sat Nov 20 07:21:16 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C83528C0F0 for ; Sat, 20 Nov 2010 07:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jc8JWXkBPH0a for ; Sat, 20 Nov 2010 07:21:15 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 5F59D28C0D0 for ; Sat, 20 Nov 2010 07:21:14 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAKFM5ET021747 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 20 Nov 2010 16:22:05 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sat, 20 Nov 2010 16:22:05 +0100 From: "Papadimitriou, Dimitri (Dimitri)" To: Glen Kent , "ospf@ietf.org" Date: Sat, 20 Nov 2010 16:22:01 +0100 Thread-Topic: [OSPF] OSPF IETF Meeting Thread-Index: AcuE2BC7MwEJdhvMTFaepSZeMlPh5gAg6rHw Message-ID: References: In-Reply-To: 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.64 on 155.132.188.84 Subject: Re: [OSPF] OSPF IETF Meeting X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 15:21:16 -0000 Glen, > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 > Behalf Of Glen Kent > Sent: Monday, November 15, 2010 4:16 PM > To: ospf@ietf.org > Subject: [OSPF] OSPF IETF Meeting >=20 > (1) While i understand the need to speed up the OSPF adjacency > formation process, i somehow dont think that the mechanism described > in draft-dimitri-ospf-phased-db-sync-00.txt is good enough. It looks a > little tenuous and appears unscalable. Can you please clarify what you mean with i) tenuous and ii) "appears unsca= lable" wrt to what ? and why ? this could be helpful for the next iteration= of the document. > I would like to compare this > vis-a-vis the transport mechanism that has been proposed by some other > folks, since that too attempts to achieve the same thing. As stated during the meeting, if you do such comparison keep in mind object= ives and criteria. Indeed, partitioning instances is detrimental for device= s which uses OSPF for exchanging non-IP routing information but this is the= information from which they derive their forwarding entries. For instance,= with MPLS-TE, separate instances would delay the RSVP-TE LSP setup (since = relying on TE information).=20 =20 Thanks, -d. > (2) I support draft-yang-ospf-hiding-00.txt and i think its makes > sense to progress this draft. >=20 > (3) I also support draft-bhatia-manral-auth-trailer-ospfv3-01, and i > think there clearly is a need to move away from IPsec security for > OSPFv3. >=20 > (4) I am not comfortable with > draft-bhatia-karp-ospf-ip-layer-protection-00.txt, as it currently > stands. While i understand that the author of this draft was one of > the co-authors of RFC 5709, i would like to first understand the > rationale behind introducing Apad in the crypto computation as has > been described in 5709. Thats clearly not a part of the original HMAC > specification. The authors have modified that without giving any > explanation in 5709, and i think its best that we first understand why > that change was introduced before we accept any changes (or > enhancements if you will) to it. >=20 > (5) draft-kini-ospf-fast-notification-00.txt looks interesting and i > would like to see some more discussions on it. I dont think its > currently at a maturity level where it can be progressed, but a > discussion would nevertheless be good. >=20 > Glen > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > = From acee.lindem@ericsson.com Sat Nov 20 08:53:04 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6746A3A6867 for ; Sat, 20 Nov 2010 08:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY5lGqYSWbPe for ; Sat, 20 Nov 2010 08:53:03 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 343893A6886 for ; Sat, 20 Nov 2010 08:53:02 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oAKGrqhj022779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Nov 2010 10:53:52 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sat, 20 Nov 2010 11:53:51 -0500 From: Acee Lindem To: "Dimitri (Dimitri) Papadimitriou" Date: Sat, 20 Nov 2010 11:53:50 -0500 Thread-Topic: Phased OSPF database synchronization Thread-Index: AcuI04HsGygEv5/6Rn+Qr3gofDbCdg== Message-ID: <14047611-AAA8-4095-AF96-FCC35B89E0B3@ericsson.com> References: In-Reply-To: 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 Cc: "ospf@ietf.org" Subject: [OSPF] Phased OSPF database synchronization X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 16:53:04 -0000 As long as we are discussing this draft, I've changed the subject line.=20 Speaking as a WG member, my opinion is that this draft is not worth the com= plexity and I wouldn't implement it even if the WG choose to adopt it as a = WG document.=20 There are many places in RFC 2328 where a decision is made dependent on whe= ther or not a neighbor is FULL and I don't think one can introduce this pro= tocol change under the assumption that the current definition. For example,= MAXAGE LSAs are handled differently dependent on whether or not any neighb= ors are in exchange state. This logic would need to be bifurcated to handle= both types of exchange.=20 Additionally, the database exchange is only one component of separation bet= ween routing and non-routing information. The transport instance is superio= r in that it offers complete separation.=20 See one more comment inline.=20 On Nov 20, 2010, at 10:22 AM, Papadimitriou, Dimitri (Dimitri) wrote: > Glen, >=20 >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 >> Behalf Of Glen Kent >> Sent: Monday, November 15, 2010 4:16 PM >> To: ospf@ietf.org >> Subject: [OSPF] OSPF IETF Meeting >>=20 >> (1) While i understand the need to speed up the OSPF adjacency >> formation process, i somehow dont think that the mechanism described >> in draft-dimitri-ospf-phased-db-sync-00.txt is good enough. It looks a >> little tenuous and appears unscalable. >=20 > Can you please clarify what you mean with i) tenuous and ii) "appears uns= calable" wrt to what ? and why ? this could be helpful for the next iterati= on of the document. >=20 >> I would like to compare this >> vis-a-vis the transport mechanism that has been proposed by some other >> folks, since that too attempts to achieve the same thing. >=20 > As stated during the meeting, if you do such comparison keep in mind obje= ctives and criteria. Indeed, partitioning instances is detrimental for devi= ces which uses OSPF for exchanging non-IP routing information but this is t= he information from which they derive their forwarding entries. For instanc= e, with MPLS-TE, separate instances would delay the RSVP-TE LSP setup (sinc= e relying on TE information). I disagree on two counts.=20 1. There is nothing that says the TE information has to moved to a separa= te instance. It is your draft that arbitrarily splits the database at the o= paque LSA boundary.=20 2. You can not categorically say the transport instance will add delay. W= hile the primary OSPF instance will normally be given priority, there is no= reason delay will be added unless there are bottlenecks in the routing dom= ain.=20 Thanks, Acee=20 >=20 >=20 > Thanks, > -d. >> (2) I support draft-yang-ospf-hiding-00.txt and i think its makes >> sense to progress this draft. >>=20 >> (3) I also support draft-bhatia-manral-auth-trailer-ospfv3-01, and i >> think there clearly is a need to move away from IPsec security for >> OSPFv3. >>=20 >> (4) I am not comfortable with >> draft-bhatia-karp-ospf-ip-layer-protection-00.txt, as it currently >> stands. While i understand that the author of this draft was one of >> the co-authors of RFC 5709, i would like to first understand the >> rationale behind introducing Apad in the crypto computation as has >> been described in 5709. Thats clearly not a part of the original HMAC >> specification. The authors have modified that without giving any >> explanation in 5709, and i think its best that we first understand why >> that change was introduced before we accept any changes (or >> enhancements if you will) to it. >>=20 >> (5) draft-kini-ospf-fast-notification-00.txt looks interesting and i >> would like to see some more discussions on it. I dont think its >> currently at a maturity level where it can be progressed, but a >> discussion would nevertheless be good. >>=20 >> Glen >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >>=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From zzhang@juniper.net Mon Nov 22 08:38:35 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0983A6AD2 for ; Mon, 22 Nov 2010 08:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYeE2Lqr1Xrx for ; Mon, 22 Nov 2010 08:38:34 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 415B53A6A9B for ; Mon, 22 Nov 2010 08:38:34 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTOqcwt0Fkjsgb/tUyZYqFP+aZaeBS6Pm@postini.com; Mon, 22 Nov 2010 08:39:30 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 22 Nov 2010 08:36:47 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 22 Nov 2010 11:36:27 -0500 From: "Jeffrey (Zhaohui) Zhang" To: "ospf@ietf.org" Date: Mon, 22 Nov 2010 11:36:24 -0500 Thread-Topic: OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: AcuKY2cu5o3QK73ETySHPLoujdA/XQ== Message-ID: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 16:38:35 -0000 Hi, I presented the draft http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-an= d-p2mp-01.txt in Beijing (slides http://www.ietf.org/proceedings/79/slides/= ospf-9.ppt) and it was deferred to the mailing list on whether the problem = is worth the working group effort (some who reviewed the draft agreed that = the proposed solution is reasonable for the problem). I'd like to request folks to review the draft/slides and voice your opinion= . We developed the solution for a real network situation and would like to = see that it gets consensus and standardized so that more operators/vendors = can benefit from this. Thanks. Jeffrey= From pjmoyer@gmail.com Mon Nov 22 10:18:35 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84ABE28B797 for ; Mon, 22 Nov 2010 10:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFmhSkh-mT1Y for ; Mon, 22 Nov 2010 10:18:34 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 51FB53A69F4 for ; Mon, 22 Nov 2010 10:18:34 -0800 (PST) Received: by wyb29 with SMTP id 29so7334750wyb.31 for ; Mon, 22 Nov 2010 10:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=55ZDXJkOzHhcmks0So/b2C1odTwGC33raoEE9z8E0ag=; b=Rqzacz9i52/6fAE5sGx1WkgUoY+/IQdMeAr2XQ2/8zrx4rvFHX7XlX7iFimJETQ9tV SZ4yoUEQ0zS44dxka3yoa+WZMQytM9pN9HftjugRvukVxV31IwK/eUPSRmHNVvsC2Ub2 jaPd+YJ67HI/svXC60plLmMSlqmRjBQK6Vog8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qm+NBzIX1HT9ASpyGFE02TbXSqYtiIxdSxREFIiSagDanYG7WNNthQxh4khpnKgjPF I4g69GeRY7L1md4NmJCfAPqVi8xJ5SpS/DD+wzlVPv1GVu+pvt30ZERTysARIdwpOQtr 4uyu6HODnFLuVQgm3/ZxuHaX9np8l50L3TJsY= MIME-Version: 1.0 Received: by 10.227.129.71 with SMTP id n7mr6338357wbs.128.1290449967980; Mon, 22 Nov 2010 10:19:27 -0800 (PST) Received: by 10.227.72.207 with HTTP; Mon, 22 Nov 2010 10:19:27 -0800 (PST) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net> Date: Mon, 22 Nov 2010 10:19:27 -0800 Message-ID: From: pete To: "Jeffrey (Zhaohui) Zhang" Content-Type: multipart/alternative; boundary=0016364c70adf1eab40495a84b0b Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 18:18:35 -0000 --0016364c70adf1eab40495a84b0b Content-Type: text/plain; charset=UTF-8 Hi, There is also a case of multiple ethernet switches connected together serially, with varying propagation delays to the routers that are connected to one of these switches. Imagine different types of transmission technologies in the network but still having ethernet on each end of the links. >From the perspective of a router connected to the nearest switch, a router on a far end switch will have higher propagation delay than a router connected to the same (nearest) switch, so having the ability to define a higher OSPF metric to that far end router can become important. Thanks, pete On Mon, Nov 22, 2010 at 8:36 AM, Jeffrey (Zhaohui) Zhang wrote: > Hi, > > I presented the draft > http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt in > Beijing (slides http://www.ietf.org/proceedings/79/slides/ospf-9.ppt) and > it was deferred to the mailing list on whether the problem is worth the > working group effort (some who reviewed the draft agreed that the proposed > solution is reasonable for the problem). > > I'd like to request folks to review the draft/slides and voice your > opinion. We developed the solution for a real network situation and would > like to see that it gets consensus and standardized so that more > operators/vendors can benefit from this. > > Thanks. > Jeffrey > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --0016364c70adf1eab40495a84b0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

There is also a case of multiple ethernet switches connected tog= ether serially, with varying propagation delays to the routers that are con= nected to one of these switches. Imagine different types of transmission te= chnologies in the network but still having ethernet on each end of the link= s.

From the perspective of a router connected to the nearest switch, a rou= ter on a far end switch will have higher propagation delay than a router co= nnected to the same (nearest) switch, so having the ability to define a hig= her OSPF metric to that far end router can become important.

Thanks,
pete

On Mon, Nov 22, 2010 = at 8:36 AM, Jeffrey (Zhaohui) Zhang <zzhang@juniper.net> wrote:
Hi,

I presented the draft http://www.ietf.org/draft-nshet= h-ospf-hybrid-bcast-and-p2mp-01.txt in Beijing (slides http://w= ww.ietf.org/proceedings/79/slides/ospf-9.ppt) and it was deferred to th= e mailing list on whether the problem is worth the working group effort (so= me who reviewed the draft agreed that the proposed solution is reasonable f= or the problem).

I'd like to request folks to review the draft/slides and voice your opi= nion. We developed the solution for a real network situation and would like= to see that it gets consensus and standardized so that more operators/vend= ors can benefit from this.

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

--0016364c70adf1eab40495a84b0b-- From zzhang@juniper.net Mon Nov 22 10:36:18 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2643A6A21 for ; Mon, 22 Nov 2010 10:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvdjRwkF1BLH for ; Mon, 22 Nov 2010 10:36:16 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 457E83A687F for ; Mon, 22 Nov 2010 10:36:15 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTOq4V80V/R4ZnPIDMLEdSBaL235bu9sK@postini.com; Mon, 22 Nov 2010 10:37:13 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 22 Nov 2010 10:36:13 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 22 Nov 2010 13:36:11 -0500 From: "Jeffrey (Zhaohui) Zhang" To: pete , "ospf@ietf.org" Date: Mon, 22 Nov 2010 13:36:11 -0500 Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: AcuKcc+Nco7zWH3jRsm1mZFGxhWVGQAANcPg Message-ID: <13205C286662DE4387D9AF3AC30EF456B028A55DB6@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456B028A55DB6EMBX01WFjnprn_" MIME-Version: 1.0 Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 18:36:18 -0000 --_000_13205C286662DE4387D9AF3AC30EF456B028A55DB6EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pete, Good point on the "different types of transmission technologies". BTW, I made a mistake for the draft link. It should be http://www.ietf.org/= internet-drafts/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt Thanks. Jeffrey ________________________________ From: pete [mailto:pjmoyer@gmail.com] Sent: Monday, November 22, 2010 1:19 PM To: Jeffrey (Zhaohui) Zhang Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Hi, There is also a case of multiple ethernet switches connected together seria= lly, with varying propagation delays to the routers that are connected to o= ne of these switches. Imagine different types of transmission technologies = in the network but still having ethernet on each end of the links. >From the perspective of a router connected to the nearest switch, a router = on a far end switch will have higher propagation delay than a router connec= ted to the same (nearest) switch, so having the ability to define a higher = OSPF metric to that far end router can become important. Thanks, pete On Mon, Nov 22, 2010 at 8:36 AM, Jeffrey (Zhaohui) Zhang > wrote: Hi, I presented the draft http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-an= d-p2mp-01.txt in Beijing (slides http://www.ietf.org/proceedings/79/slides/= ospf-9.ppt) and it was deferred to the mailing list on whether the problem = is worth the working group effort (some who reviewed the draft agreed that = the proposed solution is reasonable for the problem). I'd like to request folks to review the draft/slides and voice your opinion= . We developed the solution for a real network situation and would like to = see that it gets consensus and standardized so that more operators/vendors = can benefit from this. Thanks. Jeffrey _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --_000_13205C286662DE4387D9AF3AC30EF456B028A55DB6EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pete,
 
Good point on the "
 
BTW, I made a mis= take for=20 the draft link. It should be http://www.ietf.org/internet-drafts/draft-nsheth-ospf-hybr= id-bcast-and-p2mp-01.txt
 
Thanks.
Jeffrey

From: pete [mailto:pjmoyer@gmail.com]= =20
Sent: Monday, November 22, 2010 1:19 PM
To: Jeffrey= =20 (Zhaohui) Zhang
Cc: ospf@ietf.org
Subject: Re: [OSPF]= OSPF=20 Hybrid Broadcast and P2MP Interface Type

Hi,

There is also a case of multiple ethernet switches= =20 connected together serially, with varying propagation delays to the route= rs=20 that are connected to one of these switches. Imagine different types of=20 transmission technologies in the network but still having ethernet on eac= h end=20 of the links.

From the perspective of a router connected to the=20 nearest switch, a router on a far end switch will have higher propagation= =20 delay than a router connected to the same (nearest) switch, so having the= =20 ability to define a higher OSPF metric to that far end router can become= =20 important.

Thanks,
pete

On Mon, Nov 22, 2010 at 8:36 AM, Jeffrey (Zhaohu= i)=20 Zhang <zzhang@juniper.net> wrot= e:
Hi,

I=20 presented the draft http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-and-= p2mp-01.txt=20 in Beijing (slides http://www.ietf.org/proceedings/79/slides/ospf-9.ppt) and=20 it was deferred to the mailing list on whether the problem is worth the= =20 working group effort (some who reviewed the draft agreed that the propo= sed=20 solution is reasonable for the problem).

I'd like to request fol= ks to=20 review the draft/slides and voice your opinion. We developed the soluti= on=20 for a real network situation and would like to see that it gets consens= us=20 and standardized so that more operators/vendors can benefit from=20 this.

Thanks.
Jeffrey
____________________________________= ___________
OSPF=20 mailing list
OSPF@ietf.org
<= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ospf"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ospf

--_000_13205C286662DE4387D9AF3AC30EF456B028A55DB6EMBX01WFjnprn_-- From glen.kent@gmail.com Mon Nov 22 16:24:59 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5AFA3A6A08 for ; Mon, 22 Nov 2010 16:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCMt6wjkyvyH for ; Mon, 22 Nov 2010 16:24:57 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id E13E13A68F9 for ; Mon, 22 Nov 2010 16:24:56 -0800 (PST) Received: by eyd10 with SMTP id 10so4481530eyd.31 for ; Mon, 22 Nov 2010 16:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9Ks4zLF6VE8OPw/OMnmwyGtIm44QRt0ky+2xZf5bQSw=; b=PA/WXprcptqRq/lUZbMMamRH9CXenJeMqsPkAuV6e12DwpPY8zkShPQnhGpGt+w4ee G09azFkWFl8XYKgGYt3n7KXme0F35ZlAYY0DjNCpGe6/m67Nf5hB7xnKWss+UmFjYN/p FZIC93QvnEnJzDSUYCZ67bnqdOI2BcEuF2woA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WfayEWU/DO9qtXx1EJK+QlMfFdzjdxpGwKOVXRNtlsbVBLcYsFjo5F4QOH+CD5UyQX FIx++/VlMY8OY0webaCs/aeDs74TfEkWbAY6qeBUZX1bL2aGAoNEWaHu25H6E5Jrshly Ugp25cCVd+x3FsV6l1eJYXuydspR33GBXFZbY= MIME-Version: 1.0 Received: by 10.14.119.132 with SMTP id n4mr855993eeh.4.1290471952421; Mon, 22 Nov 2010 16:25:52 -0800 (PST) Received: by 10.14.47.197 with HTTP; Mon, 22 Nov 2010 16:25:52 -0800 (PST) In-Reply-To: References: Date: Tue, 23 Nov 2010 05:55:52 +0530 Message-ID: From: Glen Kent To: "Papadimitriou, Dimitri (Dimitri)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF IETF Meeting X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 00:25:00 -0000 Dimitri, >> >> (1) While i understand the need to speed up the OSPF adjacency >> formation process, i somehow dont think that the mechanism described >> in draft-dimitri-ospf-phased-db-sync-00.txt is good enough. It looks a >> little tenuous and appears unscalable. > > Can you please clarify what you mean with i) tenuous and ii) "appears uns= calable" wrt to what ? and why ? this could be helpful for the next iterati= on of the document. As per your draft you exchange the important information first followed by all ancillary stuff. Now, what you have not spelled out is whether SPF should get triggered or not when you do the first phase? If Yes, then you do delay doing the second phase as most OSPF tasks are monolithic and can only do one thing at a time. So, after some delayed time you start the subsequent exchanges, is this correct? Glen > >> I would like to compare this >> vis-a-vis the transport mechanism that has been proposed by some other >> folks, since that too attempts to achieve the same thing. > > As stated during the meeting, if you do such comparison keep in mind obje= ctives and criteria. Indeed, partitioning instances is detrimental for devi= ces which uses OSPF for exchanging non-IP routing information but this is t= he information from which they derive their forwarding entries. For instanc= e, with MPLS-TE, separate instances would delay the RSVP-TE LSP setup (sinc= e relying on TE information). > > Thanks, > -d. >> (2) I support draft-yang-ospf-hiding-00.txt and i think its makes >> sense to progress this draft. >> >> (3) I also support draft-bhatia-manral-auth-trailer-ospfv3-01, and i >> think there clearly is a need to move away from IPsec security for >> OSPFv3. >> >> (4) I am not comfortable with >> draft-bhatia-karp-ospf-ip-layer-protection-00.txt, as it currently >> stands. While i understand that the author of this draft was one of >> the co-authors of RFC 5709, i would like to first understand the >> rationale behind introducing Apad in the crypto computation as has >> been described in 5709. Thats clearly not a part of the original HMAC >> specification. The authors have modified that without giving any >> explanation in 5709, and i think its best that we first understand why >> that change was introduced before we accept any changes (or >> enhancements if you will) to it. >> >> (5) draft-kini-ospf-fast-notification-00.txt looks interesting and i >> would like to see some more discussions on it. I dont think its >> currently at a maturity level where it can be progressed, but a >> discussion would nevertheless be good. >> >> Glen >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> From ppsenak@cisco.com Tue Nov 23 10:09:45 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C4028C12D for ; Tue, 23 Nov 2010 10:09:45 -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.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CzKa9VbILHF for ; Tue, 23 Nov 2010 10:09:45 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 9D75128C120 for ; Tue, 23 Nov 2010 10:09:44 -0800 (PST) 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 oANIAgPE000831; Tue, 23 Nov 2010 19:10:42 +0100 (CET) Received: from dhcp-10-61-100-84.cisco.com (dhcp-10-61-100-84.cisco.com [10.61.100.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oANIAbIr023492; Tue, 23 Nov 2010 19:10:38 +0100 (CET) Message-ID: <4CEC039D.8010305@cisco.com> Date: Tue, 23 Nov 2010 19:10:37 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Jeffrey (Zhaohui) Zhang" References: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 18:09:46 -0000 Hi Jeffrey, one potential issue with this approach is the possible suboptimal traffic path if the L3 p2p topology created as you described do not match the L2 forwarding topology. With large L2 domains it may be be nontrivial to assign L3 metric correctly so that the L2/L3 forwarding match. One possible method to address the problem in hand is to create p2p connections between the routers via the L2 domain, using dedicated VLANs. This way the L2 forwarding is forced to match the L3 p2p topology. thanks, Peter On 22.11.2010 17:36, Jeffrey (Zhaohui) Zhang wrote: > Hi, > > I presented the draft http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt in Beijing (slides http://www.ietf.org/proceedings/79/slides/ospf-9.ppt) and it was deferred to the mailing list on whether the problem is worth the working group effort (some who reviewed the draft agreed that the proposed solution is reasonable for the problem). > > I'd like to request folks to review the draft/slides and voice your opinion. We developed the solution for a real network situation and would like to see that it gets consensus and standardized so that more operators/vendors can benefit from this. > > Thanks. > Jeffrey > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From zzhang@juniper.net Tue Nov 23 10:37:31 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D94B3A699E for ; Tue, 23 Nov 2010 10:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0RiMRWEayeS for ; Tue, 23 Nov 2010 10:37:30 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 8504F3A69A2 for ; Tue, 23 Nov 2010 10:37:28 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTOwKIvrPPqwbfr7tXNtvu2A4Qfv+A7Uq@postini.com; Tue, 23 Nov 2010 10:38:28 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 23 Nov 2010 10:33:45 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 23 Nov 2010 13:33:44 -0500 From: "Jeffrey (Zhaohui) Zhang" To: Peter Psenak Date: Tue, 23 Nov 2010 13:29:37 -0500 Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: AcuLOcFER9+aEW1JQuuy0HV3I+3ScAAAU08g Message-ID: <13205C286662DE4387D9AF3AC30EF456B028A569EE@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net> <4CEC039D.8010305@cisco.com> In-Reply-To: <4CEC039D.8010305@cisco.com> 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 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 18:37:31 -0000 Peter, I think I understand the potential issue you mentioned, but not quite clear= about your solution. The draft mentions that the metrics could be dynamically learned if the und= erlying network support it (in that case the l2 and l3 should match). Howev= er that is outside the scope the draft, which assumes that the metrics is o= btained by some means. Indeed if it is statically configured then the opera= tor needs to be careful. You mentioned creating p2p l2 connections. Does that mean there will be cor= reponding l3 p2p interfaces? If yes isn't it no longer a bcast/p2mp hybrid?= If not can you elaborate? Thanks. Jeffrey > -----Original Message----- > From: Peter Psenak [mailto:ppsenak@cisco.com]=20 > Sent: Tuesday, November 23, 2010 1:11 PM > To: Jeffrey (Zhaohui) Zhang > Cc: ospf@ietf.org > Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >=20 > Hi Jeffrey, >=20 > one potential issue with this approach is the possible suboptimal=20 > traffic path if the L3 p2p topology created as you described do not=20 > match the L2 forwarding topology. With large L2 domains it may be be=20 > nontrivial to assign L3 metric correctly so that the L2/L3=20 > forwarding match. >=20 > One possible method to address the problem in hand is to create p2p=20 > connections between the routers via the L2 domain, using dedicated=20 > VLANs. This way the L2 forwarding is forced to match the L3=20 > p2p topology. >=20 > thanks, > Peter >=20 > On 22.11.2010 17:36, Jeffrey (Zhaohui) Zhang wrote: > > Hi, > > > > I presented the draft=20 > http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01 > .txt in Beijing (slides=20 > http://www.ietf.org/proceedings/79/slides/ospf-9.ppt) and it=20 > was deferred to the mailing list on whether the problem is=20 > worth the working group effort (some who reviewed the draft=20 > agreed that the proposed solution is reasonable for the problem). > > > > I'd like to request folks to review the draft/slides and=20 > voice your opinion. We developed the solution for a real=20 > network situation and would like to see that it gets=20 > consensus and standardized so that more operators/vendors can=20 > benefit from this. > > > > Thanks. > > Jeffrey > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > >=20 > = From ppsenak@cisco.com Tue Nov 23 11:30:41 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A684728C17D for ; Tue, 23 Nov 2010 11:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2Z172q6mxAA for ; Tue, 23 Nov 2010 11:30:38 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 6DC8328C146 for ; Tue, 23 Nov 2010 11:30:37 -0800 (PST) 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 oANJDeES008410; Tue, 23 Nov 2010 20:13:40 +0100 (CET) Received: from dhcp-10-61-100-84.cisco.com (dhcp-10-61-100-84.cisco.com [10.61.100.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oANJDZCF020684; Tue, 23 Nov 2010 20:13:35 +0100 (CET) Message-ID: <4CEC125F.6040701@cisco.com> Date: Tue, 23 Nov 2010 20:13:35 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Jeffrey (Zhaohui) Zhang" References: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net> <4CEC039D.8010305@cisco.com> <13205C286662DE4387D9AF3AC30EF456B028A569EE@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B028A569EE@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 19:30:41 -0000 Hi Jeffrey, please see inline: On 23.11.2010 19:29, Jeffrey (Zhaohui) Zhang wrote: > Peter, > > I think I understand the potential issue you mentioned, but not quite clear about your solution. > > The draft mentions that the metrics could be dynamically learned if the underlying network support it (in that case the l2 and l3 should match). However that is outside the scope the draft, which assumes that the metrics is obtained by some means. Indeed if it is statically configured then the operator needs to be careful. dynamically updating L3 metrics based on the L2 topology is a problem of it own. The consequence is that L2 network changes that mostly used to be hidden to the L3 now becomes propagated to the L3 network. > > You mentioned creating p2p l2 connections. Does that mean there will be correponding l3 p2p interfaces? If yes isn't it no longer a bcast/p2mp hybrid? If not can you elaborate? yes, some form of a sub-interface using the VLAN technology. That is typically a p2p connection between the two OSPF speakers. thanks, Peter > > Thanks. > Jeffrey > >> -----Original Message----- >> From: Peter Psenak [mailto:ppsenak@cisco.com] >> Sent: Tuesday, November 23, 2010 1:11 PM >> To: Jeffrey (Zhaohui) Zhang >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >> >> Hi Jeffrey, >> >> one potential issue with this approach is the possible suboptimal >> traffic path if the L3 p2p topology created as you described do not >> match the L2 forwarding topology. With large L2 domains it may be be >> nontrivial to assign L3 metric correctly so that the L2/L3 >> forwarding match. >> >> One possible method to address the problem in hand is to create p2p >> connections between the routers via the L2 domain, using dedicated >> VLANs. This way the L2 forwarding is forced to match the L3 >> p2p topology. >> >> thanks, >> Peter >> >> On 22.11.2010 17:36, Jeffrey (Zhaohui) Zhang wrote: >>> Hi, >>> >>> I presented the draft >> http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01 >> .txt in Beijing (slides >> http://www.ietf.org/proceedings/79/slides/ospf-9.ppt) and it >> was deferred to the mailing list on whether the problem is >> worth the working group effort (some who reviewed the draft >> agreed that the proposed solution is reasonable for the problem). >>> >>> I'd like to request folks to review the draft/slides and >> voice your opinion. We developed the solution for a real >> network situation and would like to see that it gets >> consensus and standardized so that more operators/vendors can >> benefit from this. >>> >>> Thanks. >>> Jeffrey >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>> >> >> > From zzhang@juniper.net Wed Nov 24 06:50:21 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4AFF28C276 for ; Wed, 24 Nov 2010 06:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ0S8f5oF82B for ; Wed, 24 Nov 2010 06:50:20 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 7F16F28C274 for ; Wed, 24 Nov 2010 06:49:48 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTO0mSO6gebG6hLiHnnVCixEU6nS7ea6Z@postini.com; Wed, 24 Nov 2010 06:50:48 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 24 Nov 2010 06:48:58 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 24 Nov 2010 09:48:53 -0500 From: "Jeffrey (Zhaohui) Zhang" To: Peter Psenak Date: Wed, 24 Nov 2010 09:48:51 -0500 Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: AcuLRB89nAP8G93kQfa3SFme/7Ax6QAoM53Q Message-ID: <13205C286662DE4387D9AF3AC30EF456B028AF2D35@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net> <4CEC039D.8010305@cisco.com> <13205C286662DE4387D9AF3AC30EF456B028A569EE@EMBX01-WF.jnpr.net> <4CEC125F.6040701@cisco.com> In-Reply-To: <4CEC125F.6040701@cisco.com> 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 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 14:50:21 -0000 Peter, Please see inline.=20 > -----Original Message----- > From: Peter Psenak [mailto:ppsenak@cisco.com]=20 > Sent: Tuesday, November 23, 2010 2:14 PM > To: Jeffrey (Zhaohui) Zhang > Cc: ospf@ietf.org > Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >=20 > Hi Jeffrey, >=20 > please see inline: >=20 > On 23.11.2010 19:29, Jeffrey (Zhaohui) Zhang wrote: > > Peter, > > > > I think I understand the potential issue you mentioned, but=20 > not quite clear about your solution. > > > > The draft mentions that the metrics could be dynamically=20 > learned if the underlying network support it (in that case=20 > the l2 and l3 should match). However that is outside the=20 > scope the draft, which assumes that the metrics is obtained=20 > by some means. Indeed if it is statically configured then the=20 > operator needs to be careful. >=20 > dynamically updating L3 metrics based on the L2 topology is a=20 > problem of=20 > it own. The consequence is that L2 network changes that=20 > mostly used to=20 > be hidden to the L3 now becomes propagated to the L3 network. If L2 network changes lead to L3 metric change, then it should not be hidde= n though? I agree that the propogation of the changes needs to be rate limited, and a= balance needs to be kept between routing stability and routing optimizatio= n. Also about your original concern with l2/l3 mismatch - I don't think it is = unique with this proposal. When you assign an interface metric for a regula= r interface (or neighbor in p2mp case) you also need to make sure that the = metric reflects the l2 characteristics. >=20 > > > > You mentioned creating p2p l2 connections. Does that mean=20 > there will be correponding l3 p2p interfaces? If yes isn't it=20 > no longer a bcast/p2mp hybrid? If not can you elaborate? >=20 > yes, some form of a sub-interface using the VLAN technology. That is=20 > typically a p2p connection between the two OSPF speakers. The very purpose of the proposal is to use the hybrid interface type to avo= id the inefficiency with p2p/p2mp links when it comes to adjaceny and db sy= nchronization, while being able to advertise different metrics per neighbor= . Thanks. Jeffrey >=20 > thanks, > Peter > > > > Thanks. > > Jeffrey > > > >> -----Original Message----- > >> From: Peter Psenak [mailto:ppsenak@cisco.com] > >> Sent: Tuesday, November 23, 2010 1:11 PM > >> To: Jeffrey (Zhaohui) Zhang > >> Cc: ospf@ietf.org > >> Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type > >> > >> Hi Jeffrey, > >> > >> one potential issue with this approach is the possible suboptimal > >> traffic path if the L3 p2p topology created as you described do not > >> match the L2 forwarding topology. With large L2 domains it=20 > may be be > >> nontrivial to assign L3 metric correctly so that the L2/L3 > >> forwarding match. > >> > >> One possible method to address the problem in hand is to create p2p > >> connections between the routers via the L2 domain, using dedicated > >> VLANs. This way the L2 forwarding is forced to match the L3 > >> p2p topology. > >> > >> thanks, > >> Peter > >> > >> On 22.11.2010 17:36, Jeffrey (Zhaohui) Zhang wrote: > >>> Hi, > >>> > >>> I presented the draft > >> http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01 > >> .txt in Beijing (slides > >> http://www.ietf.org/proceedings/79/slides/ospf-9.ppt) and it > >> was deferred to the mailing list on whether the problem is > >> worth the working group effort (some who reviewed the draft > >> agreed that the proposed solution is reasonable for the problem). > >>> > >>> I'd like to request folks to review the draft/slides and > >> voice your opinion. We developed the solution for a real > >> network situation and would like to see that it gets > >> consensus and standardized so that more operators/vendors can > >> benefit from this. > >>> > >>> Thanks. > >>> Jeffrey > >>> _______________________________________________ > >>> OSPF mailing list > >>> OSPF@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ospf > >>> > >> > >> > > >=20 > = From ppsenak@cisco.com Wed Nov 24 10:05:17 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649433A68D7 for ; Wed, 24 Nov 2010 10:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4T05wSOsC8d for ; Wed, 24 Nov 2010 10:05:12 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 55DCF3A68E0 for ; Wed, 24 Nov 2010 10:05:03 -0800 (PST) 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 oAOI62Fh000068; Wed, 24 Nov 2010 19:06:02 +0100 (CET) Received: from dhcp-10-61-101-154.cisco.com (dhcp-10-61-101-154.cisco.com [10.61.101.154]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAOI5woo022646; Wed, 24 Nov 2010 19:05:59 +0100 (CET) Message-ID: <4CED5406.1030000@cisco.com> Date: Wed, 24 Nov 2010 19:05:58 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Jeffrey (Zhaohui) Zhang" References: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net> <4CEC039D.8010305@cisco.com> <13205C286662DE4387D9AF3AC30EF456B028A569EE@EMBX01-WF.jnpr.net> <4CEC125F.6040701@cisco.com> <13205C286662DE4387D9AF3AC30EF456B028AF2D35@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B028AF2D35@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 18:05:17 -0000 Hi Jeffrey, sure, the L2/L3 topology mismatch is not unique to your draft. My point was that representing a true broadcast network as a set of p2p links has a fair potential of creating such a mismatch if not done properly. thanks, Peter On 24.11.2010 15:48, Jeffrey (Zhaohui) Zhang wrote: > Peter, > > Please see inline. > >> -----Original Message----- >> From: Peter Psenak [mailto:ppsenak@cisco.com] >> Sent: Tuesday, November 23, 2010 2:14 PM >> To: Jeffrey (Zhaohui) Zhang >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >> >> Hi Jeffrey, >> >> please see inline: >> >> On 23.11.2010 19:29, Jeffrey (Zhaohui) Zhang wrote: >>> Peter, >>> >>> I think I understand the potential issue you mentioned, but >> not quite clear about your solution. >>> >>> The draft mentions that the metrics could be dynamically >> learned if the underlying network support it (in that case >> the l2 and l3 should match). However that is outside the >> scope the draft, which assumes that the metrics is obtained >> by some means. Indeed if it is statically configured then the >> operator needs to be careful. >> >> dynamically updating L3 metrics based on the L2 topology is a >> problem of >> it own. The consequence is that L2 network changes that >> mostly used to >> be hidden to the L3 now becomes propagated to the L3 network. > > If L2 network changes lead to L3 metric change, then it should not be hidden though? > > I agree that the propogation of the changes needs to be rate limited, and a balance needs to be kept between routing stability and routing optimization. > > Also about your original concern with l2/l3 mismatch - I don't think it is unique with this proposal. When you assign an interface metric for a regular interface (or neighbor in p2mp case) you also need to make sure that the metric reflects the l2 characteristics. > >> >>> >>> You mentioned creating p2p l2 connections. Does that mean >> there will be correponding l3 p2p interfaces? If yes isn't it >> no longer a bcast/p2mp hybrid? If not can you elaborate? >> >> yes, some form of a sub-interface using the VLAN technology. That is >> typically a p2p connection between the two OSPF speakers. > > The very purpose of the proposal is to use the hybrid interface type to avoid the inefficiency with p2p/p2mp links when it comes to adjaceny and db synchronization, while being able to advertise different metrics per neighbor. > > Thanks. > Jeffrey > >> >> thanks, >> Peter >>> >>> Thanks. >>> Jeffrey >>> >>>> -----Original Message----- >>>> From: Peter Psenak [mailto:ppsenak@cisco.com] >>>> Sent: Tuesday, November 23, 2010 1:11 PM >>>> To: Jeffrey (Zhaohui) Zhang >>>> Cc: ospf@ietf.org >>>> Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >>>> >>>> Hi Jeffrey, >>>> >>>> one potential issue with this approach is the possible suboptimal >>>> traffic path if the L3 p2p topology created as you described do not >>>> match the L2 forwarding topology. With large L2 domains it >> may be be >>>> nontrivial to assign L3 metric correctly so that the L2/L3 >>>> forwarding match. >>>> >>>> One possible method to address the problem in hand is to create p2p >>>> connections between the routers via the L2 domain, using dedicated >>>> VLANs. This way the L2 forwarding is forced to match the L3 >>>> p2p topology. >>>> >>>> thanks, >>>> Peter >>>> >>>> On 22.11.2010 17:36, Jeffrey (Zhaohui) Zhang wrote: >>>>> Hi, >>>>> >>>>> I presented the draft >>>> http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01 >>>> .txt in Beijing (slides >>>> http://www.ietf.org/proceedings/79/slides/ospf-9.ppt) and it >>>> was deferred to the mailing list on whether the problem is >>>> worth the working group effort (some who reviewed the draft >>>> agreed that the proposed solution is reasonable for the problem). >>>>> >>>>> I'd like to request folks to review the draft/slides and >>>> voice your opinion. We developed the solution for a real >>>> network situation and would like to see that it gets >>>> consensus and standardized so that more operators/vendors can >>>> benefit from this. >>>>> >>>>> Thanks. >>>>> Jeffrey >>>>> _______________________________________________ >>>>> OSPF mailing list >>>>> OSPF@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>> >>>> >>>> >>> >> >> > From p6c6d6@gmail.com Sun Nov 28 18:38:55 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1ED828C114 for ; Sun, 28 Nov 2010 18:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdSxW4usJpab for ; Sun, 28 Nov 2010 18:38:53 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id EDADE3A6BA6 for ; Sun, 28 Nov 2010 18:38:52 -0800 (PST) Received: by pvc21 with SMTP id 21so888094pvc.31 for ; Sun, 28 Nov 2010 18:40:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=8szLfJBCCSAcdMF/VQCyz8nVL9Os3cntpPP3O9BcrTs=; b=Sg11fI8tt3MYfHQ6yIKuwQwwgdr2AA+0xsSSO30wnq9c3Fu7uq17k3afV56pK88taF ADSXBVH3A0Kj5h8w9Pw6wUiDtKA9QPbykEhG3d2iu2E/xRqFkUU4nSepPWcG+41QnCFW n8a7HDPEfgVMqTHJRwkzP9UOc7oqa1fxQd+pc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HLevsMBJbl6uArvrNwDQGRi0v4vmXR12WzyrCsPwLzhkriDO8lYWD7yAFSXyp2HjRh 1UNzh2JgFZJufWElb3hpnBrF0vP9hDIVUJjiMoXL0xA2j2wICFaI3jtLpOUqB6T1cwXV 8UljAjugEwTgfgrWQWQl0a1ahQoi+BcPck7MQ= MIME-Version: 1.0 Received: by 10.142.72.12 with SMTP id u12mr4757935wfa.159.1290998401337; Sun, 28 Nov 2010 18:40:01 -0800 (PST) Received: by 10.142.178.16 with HTTP; Sun, 28 Nov 2010 18:40:01 -0800 (PST) Date: Mon, 29 Nov 2010 08:10:01 +0530 Message-ID: From: p6 c6d6 To: ospf@ietf.org Content-Type: multipart/alternative; boundary=001636ed69a31e09f5049627fd82 Subject: [OSPF] spf scheduling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 02:38:55 -0000 --001636ed69a31e09f5049627fd82 Content-Type: text/plain; charset=ISO-8859-1 hi, when should an spf be run, there are several events which cause the spf to be scheduled. i feel the rfc doesn't talk about it clearly. i want to know all the cases which leads to the scheduling of spf, and running spf eventually and i have the following questions. 1. when an interface state changes, should the spf be run immediately or should i originate the router lsa and then run it. 2. what happens when an interface state change happens while spf is running. 3. what happens when a new lsa is received while spf is running. 4. should i run spf while one of my neighbor is in the process of dd exchange. i think there are awful lot of scenarios, i'm relatively new to ospf. i want to understand all the scenarios of spf scheduling (running) and the best way to do it. by bestway i mean, for example, if an interface state changes, is it good to do spf right after i originate the router lsa or should i wait for some time expecting i might receive some new lsas from my neighbors because of my router lsa change. please shed some light. thanks --001636ed69a31e09f5049627fd82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,

when should an spf be run, there are several events which cause<= br>the spf to be scheduled. i feel the rfc doesn't talk about it clearl= y. i want
to know all the cases which leads to the scheduling of spf, an= d running spf
eventually and i have the following questions.

1. when an interface = state changes, should the spf be run immediately
=A0=A0=A0 or should i o= riginate the router lsa and then run it.

2. what happens when an int= erface state change happens while spf is running.

3. what happens when a new lsa is received while spf is running.
4. should i run spf while one of my neighbor is in the process of dd excha= nge.

i think there are awful lot of scenarios, i'm relatively ne= w to ospf. i want to
understand all the scenarios of spf scheduling (running) and the best way t= o do it.
by bestway i mean, for example, if an interface state changes, = is it good
to do spf right after i originate the router lsa or should i = wait for some
time expecting i might receive some new lsas from my neighbors
because = of my router lsa change.

please shed some light.

thanks

--001636ed69a31e09f5049627fd82-- From dkatz@juniper.net Sun Nov 28 21:23:30 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A10A28C148 for ; Sun, 28 Nov 2010 21:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aEGDhCcpmLD for ; Sun, 28 Nov 2010 21:23:28 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id EDDE428C14A for ; Sun, 28 Nov 2010 21:23:27 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTPM5E8TFad2aop3Glf3bBPF21oqvLEWD@postini.com; Sun, 28 Nov 2010 21:24:37 PST Received: from merlot.juniper.net (172.17.27.10) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 28 Nov 2010 21:23:26 -0800 Received: from nimbus-sc.juniper.net (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id oAT5NLb44784; Sun, 28 Nov 2010 21:23:21 -0800 (PST) (envelope-from dkatz@juniper.net) MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: Date: Sun, 28 Nov 2010 21:23:20 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <647E8805-43D8-44B6-BC38-D66DE3E3A78F@juniper.net> References: To: p6 c6d6 X-Mailer: Apple Mail (2.1082) Cc: ospf@ietf.org Subject: Re: [OSPF] spf scheduling X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 05:23:31 -0000 There are no hard and fast answers to any of these questions, and they = are largely implementation-dependent. For example, "new lsa is received = when spf is running" implies a multithreaded environment (hats off to = you for taking on this challenge if in fact you are doing so); the = "best way" in turn depends on whether LSA database locking is required, = etc., etc. However, the short answer is that there is so much CPU power these days = that, unless you are dealing with extremely large networks, the cost of = SPF itself ought to be negligible. The real cost is how running SPF = interacts with other parts of the system (the multithreading question, = for example) and what comes *after* the SPF (how routing table and = forwarding table updates are handled, what happens with potentially = numerous dependent BGP routes, etc.) and all of that is highly = implementation-dependent. Doing this well requires system-level analysis rather than just focusing = on the protocol implementation. And of course the commercial reality is that, in a standards-based = world, product differentiation is all about implementation, and so you = may find it difficult to get guidance at this level of detail. For what it's worth, the OSPF spec is as close to a complete = implementation guide as you'll find in a protocol standard. I happen to = be philosophically opposed to such specs, as they make it more = challenging to understand what normative behavior actually should be. = The OSPF spec is a fine guide to building a solid implementation, albeit = one with scaling challenges. To do it the "best way" requires a = detailed understanding of the protocol's subtleties, and you won't find = that written down anywhere. That's what makes it fun. ;-) --Dave On Nov 28, 2010, at 6:40 PM, p6 c6d6 wrote: > hi, >=20 > when should an spf be run, there are several events which cause > the spf to be scheduled. i feel the rfc doesn't talk about it clearly. = i want > to know all the cases which leads to the scheduling of spf, and = running spf > eventually and i have the following questions. >=20 > 1. when an interface state changes, should the spf be run immediately > or should i originate the router lsa and then run it. >=20 > 2. what happens when an interface state change happens while spf is = running. >=20 > 3. what happens when a new lsa is received while spf is running. >=20 > 4. should i run spf while one of my neighbor is in the process of dd = exchange. >=20 > i think there are awful lot of scenarios, i'm relatively new to ospf. = i want to=20 > understand all the scenarios of spf scheduling (running) and the best = way to do it. > by bestway i mean, for example, if an interface state changes, is it = good > to do spf right after i originate the router lsa or should i wait for = some > time expecting i might receive some new lsas from my neighbors=20 > because of my router lsa change. >=20 > please shed some light. >=20 > thanks >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From aretana@cisco.com Tue Nov 30 13:54:06 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9B53A6C44 for ; Tue, 30 Nov 2010 13:54:06 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id box+e9qUoJd9 for ; Tue, 30 Nov 2010 13:54:05 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 03F663A6A6E for ; Tue, 30 Nov 2010 13:54:04 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAsB9UytJXG8/2dsb2JhbACjDnGoW5s8AoMJgjwEhFxViEY X-IronPort-AV: E=Sophos;i="4.59,282,1288569600"; d="scan'208";a="187692810" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rtp-iport-2.cisco.com with ESMTP; 30 Nov 2010 21:55:17 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id oAULtGVU028296 for ; Tue, 30 Nov 2010 21:55:16 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Nov 2010 15:55:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: Eko= AOgQ AiiZ A7Ft BJc/ BTLv C0TB DN7+ EemP EsdQ Grrl HTE9 IDvV JwxF K/wU MJ2Z; 1; bwBzAHAAZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {96E8F3CB-EB0D-40FD-804A-91AAE34C1A22}; YQByAGUAdABhAG4AYQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Tue, 30 Nov 2010 21:54:57 GMT; SQBuAGMAcgBlAG0AZQBuAHQAYQBsACAATABTAEQAQgAgAFMAeQBuAGMA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {96E8F3CB-EB0D-40FD-804A-91AAE34C1A22} Content-class: urn:content-classes:message Date: Tue, 30 Nov 2010 15:54:57 -0600 Message-ID: <1D23749D4168CC4D8B8652397B5F643203CEE4A4@XMB-RCD-206.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Incremental LSDB Sync Thread-Index: AcuQ2TpugVn4ONquR0uYgpoAibn96Q== From: "Alvaro Retana (aretana)" To: X-OriginalArrivalTime: 30 Nov 2010 21:55:17.0099 (UTC) FILETIME=[463E6BB0:01CB90D9] Subject: [OSPF] Incremental LSDB Sync X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 21:54:06 -0000 Hi! During Dimitri's presentation of his "Phased OSPF Link-State Database Synchronization' draft (draft-dimitri-ospf-phased-db-sync) in Beijing I mentioned that the same result (2 stage LSDB sync) can be achieved using OOB Resync (rfc4811). I just posted a new draft that talks about that. I called it 'Incremental LSDB Sync" (ILS) and it uses existing mechanisms. Here's the abstract: OSPF Incremental Link State Database Synchronization draft-retana-ospf-ils-00 Abstract The ability of OSPF to transport non-routing information to be used by other applications was defined by the Opaque LSA Option. In order to not impact the convergence of routing information, this document describes a simple process to incrementally synchronize the routing and non-routing information residing in an OSPF link-state database. Looks like the draft is not up on the web site yet, so I'm attaching a copy below. Comments/thoughts/flames? Thanks! Alvaro. ---------------------------------------------------------------- Network Working Group A. Retana Internet-Draft Cisco Systems, Inc. Intended status: Informational November 30, 2010 Expires: June 3, 2011 OSPF Incremental Link State Database Synchronization draft-retana-ospf-ils-00 Abstract The ability of OSPF to transport non-routing information to be used by other applications was defined by the Opaque LSA Option. In order to not impact the convergence of routing information, this document describes a simple process to incrementally synchronize the routing and non-routing information residing in an OSPF link-state database. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 3, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Retana Expires June 3, 2011 [Page 1] Internet-Draft OSPF Incremental LSDB Sync November 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. Incremental LSDB Synchronization Process . . . . . . . . . . . 3 3.1. Graceful Restart . . . . . . . . . . . . . . . . . . . . . 4 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Retana Expires June 3, 2011 [Page 2] Internet-Draft OSPF Incremental LSDB Sync November 2010 1. Introduction Opaque LSAs [RFC5250] provide the ability for OSPFv2 [RFC2328] to transport non-routing information to be used by other applications. A similar capability exists in OSPFv3 [RFC5340] through the use of the U-bit and an appropriate LSA Function Code. Throughout this document Opaque LSAs and ones with unrecognized link-state types will be referred to simply as "opaque". The presence of opaque information in the OSPF Link-State Database (LSDB) may result in longer database exchange times, especially in cases where the amount of data is significantly larger than the routing-specific information. In order to not impact the convergence of routing information, this document describes a simple process to incrementally synchronize the information residing in an OSPF LSDB. The process uses existing mechanisms. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Incremental LSDB Synchronization Process The Incremental LSBD Synchronization (ILS) process consists of the following steps: LSA Prioritization The contents of the local LSDB are classified to determine which LSAs require prioritized synchronization. In general, LSAs containing routing-specific information SHOULD be classified as requiring prioritized synchronization, while other LSAs MAY be classified as not requiring it. Prioritized LSDB Synchronization This step corresponds to the adjacency establishment process as described in RFC 2328 [RFC2328]. LSAs classified as not requiring prioritized synchronization MUST NOT be included in Database Description (DBD) Packets during the Database Exchange Process. The OSPF routing table structure SHOULD be calculated before moving on to the next step. Retana Expires June 3, 2011 [Page 3] Internet-Draft OSPF Incremental LSDB Sync November 2010 Final LSDB Synchronization In this step, any remaining LSAs in the LSDB SHOULD be synchronized. The routers MUST use the Out-of-Band LSDB Resynchronization [RFC4811] (OOB Resync) mechanism, which provides a way to resynchronize the LSDB without affecting the advertised neighbor state. The process is described in terms of LSAs containing (or not) routing-specific information, but it may be generalized to include any other criteria considered significant in the local network and protocol instance. The last step in the process MAY be used recursively to achieve an incremental LSDB synchronization through different types of data, making it also applicable to environments where only non-routing information exists. 3.1. Graceful Restart The restart of the OSPF software in a router also presents an opportunity for LSDB synchronization. Because the restarting router is still in the forwarding path, it is important for the routing information in the LSDB to be synchronized as fast as possible. ILS can be used, with minor modifications, to reduce the synchronization time and the probability of network topology changes. Graceful OSPF Restart Graceful OSPF Restart for OSPFv2 [RFC3623] and OSPFv3 [RFC5187] don't specify any changes to the adjacency establishment process. ILS can be used by the Helper Neighbor during the Grace Period; if so, then the Helper Node MUST include any Grace- LSAs in the DBD Packets during the Prioritized LSDB Synchronization step. OSPF Restart Signaling OSPF Restart Signaling [RFC4812] defines a mechanism to inform neighbors about a local restart, in which the LSDB synchronization is achieved using OOB Resync. In other words, the Prioritized LSDB Synchronization step would use OOB Resync if the non-restarting router uses ILS. No other changes to the process are needed. Retana Expires June 3, 2011 [Page 4] Internet-Draft OSPF Incremental LSDB Sync November 2010 4. Backward Compatibility The operation of ILS depends on the support of OOB Resync during synchronization; no backwards compatibility issues exist there [RFC4811]. If OOB Resync is not supported by one of the routers, then the LSDB synchronization would fall back to the adjacency establishment process as described in RFC 2328 [RFC2328]. If OOB Resync is supported, but ILS has not been implemented by all the routers involved, the operation is still backwards compatible. Note that the process (Section 3) depends on the database description by the local router. In other words, a router may decide to not fully describe the contents of its LSDB to its neighbor during the adjacency establishment process, and later use OOB Resync to incrementally describe the difference; the receiver doesn't need to be aware of ILS. The benefits of ILS may only be partially realized if not supported by all the routers involved in synchronization. 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations The process described in this document does not introduce any new security issues into the OSPF protocol. 7. Acknowledgements The author would like to thank Abhay Roy and Liem Nguyen for their comments, and Dimitri Papadimitriou for his comments and for providing the motivation for this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4811] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link State Database (LSDB) Resynchronization", RFC 4811, March 2007. Retana Expires June 3, 2011 [Page 5] Internet-Draft OSPF Incremental LSDB Sync November 2010 8.2. Informative References [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003. [RFC4812] Nguyen, L., Roy, A., and A. Zinin, "OSPF Restart Signaling", RFC 4812, March 2007. [RFC5187] Pillay-Esnault, P. and A. Lindem, "OSPFv3 Graceful Restart", RFC 5187, June 2008. [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. Author's Address Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA Phone: +1 919 392 2061 Email: aretana@cisco.com Retana Expires June 3, 2011 [Page 6]