Message

hi,

Doubt: = When=20 Interface ID for normal interfaces is not made configurable, why is = Virtual=20 Link's Interface ID made configurable in Virtual Interface=20 Table?

As = Virtual=20 Interface's Interface ID need to be unique amongst all the Interface IDs = within=20 the router, the administrator had to check what all interface IDs are in = use at=20 present and make a selection. All this is not = unavoidable.

I feel = it would be=20 better if we make it read-only object and leave the selection of it to=20 implementation.

thanx

ramana

------_=_NextPart_001_01C68ED3.75AC4DA4-- --===============1153798682== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1153798682==-- From ospf-bounces@ietf.org Tue Jun 13 06:59:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq6cD-0006Qc-Va; Tue, 13 Jun 2006 06:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq6cC-0006QS-PP for ospf@ietf.org; Tue, 13 Jun 2006 06:59:20 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq6cB-0004kx-B2 for ospf@ietf.org; Tue, 13 Jun 2006 06:59:20 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k5DAxEmi024075 for ; Tue, 13 Jun 2006 03:59:18 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5DAxBg2012538 for ; Tue, 13 Jun 2006 05:59:13 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [OSPF] Link LSA generation in OSPFv3 Date: Tue, 13 Jun 2006 18:59:04 +0800 Message-ID: <988EE2C769AC284ABAE9328BFC10703FCAEA79@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Link LSA generation in OSPFv3 Thread-Index: AcaOzCmqAUHSLTSXRNeXi9AxVFjeDAAC389Q From: "Khan Amir-G20247" To: "fabien.verhaeghe" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1861009336==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============1861009336== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68ED8.66AE2504" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68ED8.66AE2504 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fabien =20 As per my understanding Link LSA can be originated when any of the NBR on the link reaches TWO-WAY state.=20 =20 Regards Aamir =20 ________________________________ From: fabien.verhaeghe [mailto:fabien.verhaeghe@atosorigin.com]=20 Sent: Tuesday, June 13, 2006 3:00 PM To: ospf@ietf.org Subject: [OSPF] Link LSA generation in OSPFv3 Hello All, =20 >From draft-ietf-ospf-ospfv3-update-09.txt section 3.4.3.6 "A router originates a separate link-LSA for each attached link that supports 2 or more (including the originating router itself) routers" I understand that a router originates a link LSA only if it has at least one fully adjacent neighbor. =20 But in section 3.4.3 the link-lsa is note mentionned in the item: =20 o A neighbor transitions to/from "Full" state. The router may need to (re)originate or flush the link's network-LSA and one or more router-LSAs and/or intra-area-prefix-LSAs. =20 Instead it is put in the first item about interface state change. o The state or interface ID of one of the router's interfaces changes. The router may need to (re)originate or flush its link- LSA and one or more router-LSAs and/or intra-area-prefix-LSAs. If the router is DR, the router may also need to (re)originate and/or flush the network LSA corresponding to the interface. =20 Does this mean link LSA has to be originate when the interface is up and not when a first full neighbor appears? =20 Another point concerning network LSA origination. Shouldn't we have an item stating that network LSA may be re-originated upon receipt (or purged) of a link-LSA because it may=20 entail a change in the option field. =20 Thanks Fabien Verhaeghe Atos Origin=20 ------_=_NextPart_001_01C68ED8.66AE2504 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Fabien

As per my understanding = Link=20 LSA can be originated when any of the NBR on the=20 link reaches TWO-WAY state.

Regards

Aamir

From: fabien.verhaeghe=20 [mailto:fabien.verhaeghe@atosorigin.com]
Sent: Tuesday, June = 13, 2006=20 3:00 PM
To: ospf@ietf.org
Subject: [OSPF] Link LSA=20 generation in OSPFv3

Hello All,

From = draft-ietf-ospf-ospfv3-update-09.txt section=20 3.4.3.6 "A router originates a separate link-LSA

for each attached link that supports 2 = or more=20 (including the originating router itself) routers"

I understand that a router originates a = link LSA=20 only if it has at least one fully adjacent neighbor.

But in section 3.4.3 the link-lsa is = note=20 mentionned in the item:

   o A neighbor = transitions to/from=20 "Full" state. The router may = need
      to=20 (re)originate or flush the link's network-LSA and one or=20 more
      router-LSAs and/or=20 intra-area-prefix-LSAs.

Instead it is put in the first item = about interface=20 state change.

   o The state or = interface ID=20 of one of the router's interfaces
     =20 changes. The router may need to (re)originate or flush its=20 link-
      LSA and one or more router-LSAs = and/or=20 intra-area-prefix-LSAs. If
      the = router is=20 DR, the router may also need to (re)originate=20 and/or
      flush the network LSA = corresponding to=20 the interface.

Does this mean link LSA has to be originate when the interface is = up and=20 not when a

first full neighbor appears?

Another point concerning network LSA origination. Shouldn't we have = an item=20 stating that

network LSA may be re-originated upon receipt (or purged) of a = link-LSA=20 because it may

entail a change in the option field.

Thanks

Fabien Verhaeghe

Atos Origin

------_=_NextPart_001_01C68ED8.66AE2504-- --===============1861009336== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1861009336==-- From ospf-bounces@ietf.org Tue Jun 13 11:37:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqAxY-0002n8-S0; Tue, 13 Jun 2006 11:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqAxY-0002mz-4i for ospf@ietf.org; Tue, 13 Jun 2006 11:37:40 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqAxW-0007W9-Of for ospf@ietf.org; Tue, 13 Jun 2006 11:37:40 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k5DFWJw18849; Tue, 13 Jun 2006 11:32:19 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Jun 2006 11:36:25 -0400 Message-ID: <4B7DAC3FEFD35D4A96BDD0116990501403365F5C@zrtphxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [REPOSTING] OSPFv3 MIB: InterfaceID in Vlink Thread-Index: AcaKE4SYyZFO/b6RQEuZbN2XPAuRoQEvzr4wAAlT+3A= From: "Daniel Joyal" To: "Ramana Koppula-G20085" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: vishwas@sinett.com Subject: [OSPF] RE: [REPOSTING] OSPFv3 MIB: InterfaceID in Vlink X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1700915400==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============1700915400== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68EFF.2163BFA7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68EFF.2163BFA7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ramana, =20 I think from recent WG discussions it has been established that an OSPFv3 interface is identified by the interface InstanceID object. So, for physical links we have an Interface index and for an OSPFv3 interface on that link (of possibly multiple OSPFv3 interfaces) we have the interface InstanceID. =20 Currently, the Virtual Link table entry has both ospfv3VirtIfIndex=20 and ospfv3VirtIfInstId objects. I believe that only the ospfv3VirtIfInstId object is necessary and its usage would be symmetric with that of the ospfv3IfInstId object in the interface table. Since ospfv3IfInstId is configurable for physical interfaces, it should remain configurable for virtual interfaces. Does this make sense? =20 -Dan -----Original Message----- From: Ramana Koppula-G20085 [mailto:ramanakumar@motorola.com]=20 Sent: Tuesday, June 13, 2006 6:24 AM To: ospf@ietf.org Cc: Joyal, Daniel [BL60:SF23:EXCH]; vishwas@sinett.com Subject: [REPOSTING] OSPFv3 MIB: InterfaceID in Vlink =09 =09 I am eagerly waiting for some comments, whether its valid to keep a read-only or is there any issue if we make it read-only. =20 hi, =20 Doubt: When Interface ID for normal interfaces is not made configurable, why is Virtual Link's Interface ID made configurable in Virtual Interface Table? =20 As Virtual Interface's Interface ID need to be unique amongst all the Interface IDs within the router, the administrator had to check what all interface IDs are in use at present and make a selection. All this is not unavoidable. =20 I feel it would be better if we make it read-only object and leave the selection of it to implementation. =20 thanx ramana ------_=_NextPart_001_01C68EFF.2163BFA7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi=20 Ramana,

I=20 think from recent WG discussions it has been=20 established that

an=20 OSPFv3 interface is identified by the interface=20 InstanceID object.

So,=20 for physical links we have an Interface index and for an = OSPFv3

interface on that link (of possibly multiple OSPFv3 = interfaces)=20 we

have=20 the interface InstanceID.

Currently, the Virtual Link table entry has both=20 ospfv3VirtIfIndex

and=20 ospfv3VirtIfInstId objects. I believe that only the=20 ospfv3VirtIfInstId

object=20 is necessary and its usage would be symmetric with that = of

the ospfv3IfInstId object in the interface table. Since=20 ospfv3IfInstId

is=20 configurable for physical interfaces, it should remain=20 configurable

for=20 virtual interfaces. Does this make sense?

-Dan

-----Original Message-----
From: = Ramana=20 Koppula-G20085 [mailto:ramanakumar@motorola.com]
Sent: = Tuesday,=20 June 13, 2006 6:24 AM
To: ospf@ietf.org
Cc: Joyal, = Daniel=20 [BL60:SF23:EXCH]; vishwas@sinett.com
Subject: [REPOSTING] = OSPFv3=20 MIB: InterfaceID in Vlink

I am eagerly waiting for some comments, whether = its valid=20 to keep a read-only or is there any issue if we make it=20 read-only.

hi,

Doubt: When=20 Interface ID for normal interfaces is not made configurable, why is = Virtual=20 Link's Interface ID made configurable in Virtual Interface=20 Table?

As = Virtual=20 Interface's Interface ID need to be unique amongst all the Interface = IDs=20 within the router, the administrator had to check what all interface = IDs are=20 in use at present and make a selection. All this is not=20 unavoidable.

I = feel it would be=20 better if we make it read-only object and leave the selection of it to = implementation.

thanx

ramana

------_=_NextPart_001_01C68EFF.2163BFA7-- --===============1700915400== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1700915400==-- From ospf-bounces@ietf.org Tue Jun 13 13:49:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqD1Q-0002sR-9h; Tue, 13 Jun 2006 13:49:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqD1O-0002mU-BP for ospf@ietf.org; Tue, 13 Jun 2006 13:49:46 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqCxr-0004EZ-B0 for ospf@ietf.org; Tue, 13 Jun 2006 13:46:08 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Jun 2006 10:46:06 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5DHk54e032452 for ; Tue, 13 Jun 2006 10:46:05 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5DHk5CU007649 for ; Tue, 13 Jun 2006 10:46:05 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 10:46:05 -0700 Received: from [128.107.175.85] ([128.107.175.85]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 10:46:05 -0700 Message-ID: <448EF9DD.7020007@cisco.com> Date: Tue, 13 Jun 2006 13:46:05 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OSPF List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2006 17:46:05.0312 (UTC) FILETIME=[3E8A8800:01C68F11] DKIM-Signature: a=rsa-sha1; q=dns; l=766; t=1150220765; x=1151084765; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:[Fwd=3A=20Recommending=20the=20'Tao=20of=20the=20IETF'=20to=20your=20WG= 20members]; X=v=3Dcisco.com=3B=20h=3DHH6SfMCZOB52WESmMVwEX8ag6O4=3D; b=btSo7aADtcxZdNwpsXgsTZedZUovtdaaHmZIfx+sz1r14/f9FPv1ULZjqHI1R2AlJQR7+1Y6 nc9NRbzMKNghg/JytZHYE5EjqjawqnlYdYKA6yIwuoWI2XPzS4OHTflP; Authentication-Results: sj-dkim-3.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [OSPF] [Fwd: Recommending the 'Tao of the IETF' to your WG members] X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org FYI - A new version of "The Tao of the IETF" has been approved for publication. IMHO, this is a very informative and well writen document. Thanks, Acee -------- Original Message -------- Subject: Recommending the 'Tao of the IETF' to your WG members Date: Mon, 12 Jun 2006 10:38:10 -0700 From: Paul Hoffman To: wgchairs@ietf.org Greetings again. If you have been suggesting that newbies in your WG coming to their first IETF read the 'Tao of the IETF', there is now a new official version. Feel free to point them at , which has just been approved as an Informational RFC to replace the old Tao. --Paul Hoffman, Director --VPN Consortium _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jun 13 16:51:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqFr2-0003ud-7H; Tue, 13 Jun 2006 16:51:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqFr1-0003uY-Oq for ospf@ietf.org; Tue, 13 Jun 2006 16:51:15 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqFr0-00072M-AL for ospf@ietf.org; Tue, 13 Jun 2006 16:51:15 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 13 Jun 2006 13:51:13 -0700 X-IronPort-AV: i="4.06,128,1149490800"; d="scan'208"; a="294093923:sNHT49672020" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5DKpChC010048; Tue, 13 Jun 2006 13:51:12 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5DKp7Ce020130; Tue, 13 Jun 2006 13:51:12 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 13:51:07 -0700 Received: from [128.107.175.85] ([128.107.175.85]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 13:51:07 -0700 Message-ID: <448F253B.7070004@cisco.com> Date: Tue, 13 Jun 2006 16:51:07 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Khan Amir-G20247 Subject: Re: [OSPF] Link LSA generation in OSPFv3 References: <988EE2C769AC284ABAE9328BFC10703FCAEA79@ZMY16EXM66.ds.mot.com> In-Reply-To: <988EE2C769AC284ABAE9328BFC10703FCAEA79@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2006 20:51:07.0479 (UTC) FILETIME=[17F2C670:01C68F2B] DKIM-Signature: a=rsa-sha1; q=dns; l=2429; t=1150231872; x=1151095872; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20Link=20LSA=20generation=20in=20OSPFv3; X=v=3Dcisco.com=3B=20h=3DVku1yTe66j6L6E2wlWSoFlyY7qA=3D; b=nMWaCIBNihqibbNJOmP4A8bLMyVnPorfiiF4bfY87Eo+vcSX6M6SR3YqfAceXR8aHFWlHDz8 ah7pO9i/KPwF5nl0cvNtCl3ls4T8g3+qLPlsSIU0Bn7OAtnOb56xZMdz; Authentication-Results: sj-dkim-2.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Fabien, Khan, Khan Amir-G20247 wrote: >Hi Fabien > >As per my understanding Link LSA can be originated when any of the NBR >on the link reaches TWO-WAY state. > > I'd say this is an implementation choice. However, the link-LSA must be originated in time to be including in the database exchange. I've always found it to be simpler to originate it when the link comes up. See one additional point below. > >Regards >Aamir > > > >________________________________ > >From: fabien.verhaeghe [mailto:fabien.verhaeghe@atosorigin.com] >Sent: Tuesday, June 13, 2006 3:00 PM >To: ospf@ietf.org >Subject: [OSPF] Link LSA generation in OSPFv3 > > >Hello All, > >>From draft-ietf-ospf-ospfv3-update-09.txt section 3.4.3.6 "A router >originates a separate link-LSA >for each attached link that supports 2 or more (including the >originating router itself) routers" >I understand that a router originates a link LSA only if it has at least >one fully adjacent neighbor. > >But in section 3.4.3 the link-lsa is note mentionned in the item: > > o A neighbor transitions to/from "Full" state. The router may need > to (re)originate or flush the link's network-LSA and one or more > router-LSAs and/or intra-area-prefix-LSAs. > >Instead it is put in the first item about interface state change. > > o The state or interface ID of one of the router's interfaces > changes. The router may need to (re)originate or flush its link- > LSA and one or more router-LSAs and/or intra-area-prefix-LSAs. If > the router is DR, the router may also need to (re)originate and/or > flush the network LSA corresponding to the interface. > >Does this mean link LSA has to be originate when the interface is up and >not when a >first full neighbor appears? > >Another point concerning network LSA origination. Shouldn't we have an >item stating that >network LSA may be re-originated upon receipt (or purged) of a link-LSA >because it may >entail a change in the option field. > > I agree, I'll add this to section 3.4.3 in the 10 version. Thanks, Acee > >Thanks >Fabien Verhaeghe >Atos Origin > > > >------------------------------------------------------------------------ > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jun 14 12:45:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYUh-000403-US; Wed, 14 Jun 2006 12:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYUg-0003zy-Pz for ospf@ietf.org; Wed, 14 Jun 2006 12:45:26 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqYUg-0003fU-2Q for ospf@ietf.org; Wed, 14 Jun 2006 12:45:26 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k5EGjPhF016505 for ; Wed, 14 Jun 2006 09:45:25 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5EGjMFU015617 for ; Wed, 14 Jun 2006 11:45:24 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jun 2006 00:45:12 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [REPOSTING] OSPFv3 MIB: InterfaceID in Vlink Thread-Index: AcaKE4SYyZFO/b6RQEuZbN2XPAuRoQEvzr4wAAlT+3AANi9C8A== From: "Ramana Koppula-G20085" To: "Daniel Joyal" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: vishwas@sinett.com Subject: [OSPF] RE: [REPOSTING] OSPFv3 MIB: InterfaceID in Vlink X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0844114177==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============0844114177== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68FD1.ED76DEDF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68FD1.ED76DEDF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Daniel, =20 Yes, removing VirtIfIndex is Ok. Which is not mandatory to show also as we consistent with interface table also. =20 thanx ramana ________________________________ From: Daniel Joyal [mailto:djoyal@nortel.com]=20 Sent: Tuesday, June 13, 2006 9:06 PM To: Ramana Koppula-G20085; ospf@ietf.org Cc: vishwas@sinett.com Subject: RE: [REPOSTING] OSPFv3 MIB: InterfaceID in Vlink Hi Ramana, =20 I think from recent WG discussions it has been established that an OSPFv3 interface is identified by the interface InstanceID object. So, for physical links we have an Interface index and for an OSPFv3 interface on that link (of possibly multiple OSPFv3 interfaces) we have the interface InstanceID. =20 Currently, the Virtual Link table entry has both ospfv3VirtIfIndex=20 and ospfv3VirtIfInstId objects. I believe that only the ospfv3VirtIfInstId object is necessary and its usage would be symmetric with that of the ospfv3IfInstId object in the interface table. Since ospfv3IfInstId is configurable for physical interfaces, it should remain configurable for virtual interfaces. Does this make sense? =20 -Dan -----Original Message----- From: Ramana Koppula-G20085 [mailto:ramanakumar@motorola.com]=20 Sent: Tuesday, June 13, 2006 6:24 AM To: ospf@ietf.org Cc: Joyal, Daniel [BL60:SF23:EXCH]; vishwas@sinett.com Subject: [REPOSTING] OSPFv3 MIB: InterfaceID in Vlink =09 =09 I am eagerly waiting for some comments, whether its valid to keep a read-only or is there any issue if we make it read-only. =20 hi, =20 Doubt: When Interface ID for normal interfaces is not made configurable, why is Virtual Link's Interface ID made configurable in Virtual Interface Table? =20 As Virtual Interface's Interface ID need to be unique amongst all the Interface IDs within the router, the administrator had to check what all interface IDs are in use at present and make a selection. All this is not unavoidable. =20 I feel it would be better if we make it read-only object and leave the selection of it to implementation. =20 thanx ramana ------_=_NextPart_001_01C68FD1.ED76DEDF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi Daniel,

Yes, removing VirtIfIndex is Ok. Which is not = mandatory=20 to show also as we consistent with interface table = also.

thanx

ramana

From: Daniel Joyal = [mailto:djoyal@nortel.com]=20
Sent: Tuesday, June 13, 2006 9:06 PM
To: Ramana=20 Koppula-G20085; ospf@ietf.org
Cc:=20 vishwas@sinett.com
Subject: RE: [REPOSTING] OSPFv3 MIB: = InterfaceID in=20 Vlink

Hi=20 Ramana,

I=20 think from recent WG discussions it has been=20 established that

an=20 OSPFv3 interface is identified by the interface=20 InstanceID object.

So,=20 for physical links we have an Interface index and for an = OSPFv3

interface on that link (of possibly multiple OSPFv3 = interfaces)=20 we

have=20 the interface InstanceID.

Currently, the Virtual Link table entry has both=20 ospfv3VirtIfIndex=20

and=20 ospfv3VirtIfInstId objects. I believe that only the=20 ospfv3VirtIfInstId

object=20 is necessary and its usage would be symmetric with that = of

the ospfv3IfInstId object in the interface table. Since=20 ospfv3IfInstId

is=20 configurable for physical interfaces, it should remain=20 configurable

for=20 virtual interfaces. Does this make sense?

-Dan

-----Original Message-----
From: = Ramana=20 Koppula-G20085 [mailto:ramanakumar@motorola.com]
Sent: = Tuesday,=20 June 13, 2006 6:24 AM
To: ospf@ietf.org
Cc: Joyal, = Daniel=20 [BL60:SF23:EXCH]; vishwas@sinett.com
Subject: [REPOSTING] = OSPFv3=20 MIB: InterfaceID in Vlink

I am eagerly waiting for some comments, whether = its valid=20 to keep a read-only or is there any issue if we make it=20 read-only.

hi,

Doubt: When=20 Interface ID for normal interfaces is not made configurable, why is = Virtual=20 Link's Interface ID made configurable in Virtual Interface=20 Table?

As = Virtual=20 Interface's Interface ID need to be unique amongst all the Interface = IDs=20 within the router, the administrator had to check what all interface = IDs are=20 in use at present and make a selection. All this is not=20 unavoidable.

I = feel it would be=20 better if we make it read-only object and leave the selection of it to = implementation.

thanx

ramana

------_=_NextPart_001_01C68FD1.ED76DEDF-- --===============0844114177== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0844114177==-- From MAILER-DAEMON Wed Jun 14 13:54:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZZy-0005K7-38 for ospf-archive@lists.ietf.org; Wed, 14 Jun 2006 13:54:58 -0400 Received: from mail.gtec.com ([66.117.96.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqZZw-0005EN-Sf for ospf-archive@lists.ietf.org; Wed, 14 Jun 2006 13:54:58 -0400 Received: from mail.gtec.com by mail.gtec.com (VisNetic.MailServer.v8.0.3.1) with SMTP id ABM38377 for ; Wed, 14 Jun 2006 12:54:56 -0500 Date: Wed, 14 Jun 2006 12:54:56 -0500 From: VisNetic MailServer To: Message-Id: <885941980@mail.gtec.com> Subject: Returned mail: DNS server responded with 3 (Domain Not Found) Content-Type: multipart/report; report-type=delivery-status; boundary="88594198020060614125456C885@mail.gtec.com" X-Spam-Score: 0.5 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 --88594198020060614125456C885@mail.gtec.com The original message was received at Wed, 14 Jun 2006 12:54:56 -0500 ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while issuing MX query to 66.117.96.6 554 DNS server responded with 3 (Domain Not Found) --88594198020060614125456C885@mail.gtec.com Content-Type: message/delivery-status Reporting-MTA: DNS; mail.gtec.com Arrival-Date: Wed, 14 Jun 2006 12:54:58 -0500 Original-Recipient: RFC822; Final-Recipient: RFC822; Action: failed Last-Attempt-Date: Wed, 14 Jun 2006 12:54:56 -0500 --88594198020060614125456C885@mail.gtec.com Content-Type: message/rfc822 Return-Path: Received: from lists.ietf.org ([66.117.99.136]) by mail.gtec.com (VisNetic.MailServer.v8.0.3.1) with ESMTP id ABM38377 for ; Wed, 14 Jun 2006 12:54:54 -0500 From: ospf-archive@lists.ietf.org To: e1e7ylj-0000o4-bl@newodin.ietf.org Subject: e1e7ylj-0000o4-bl@newodin.ietf.org Date: Wed, 14 Jun 2006 12:50:04 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_06BBA66F.AC03D67B" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 --88594198020060614125456C885@mail.gtec.com-- From ospf-bounces@ietf.org Thu Jun 15 06:58:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqpXs-00036S-QB; Thu, 15 Jun 2006 06:57:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqpXr-00036N-3r for ospf@ietf.org; Thu, 15 Jun 2006 06:57:51 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqpXo-0007F7-RJ for ospf@ietf.org; Thu, 15 Jun 2006 06:57:51 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5FAvmu5018665 for ; Thu, 15 Jun 2006 03:57:48 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5FAvkpP010088 for ; Thu, 15 Jun 2006 05:57:47 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jun 2006 18:57:35 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OSPFv3 Draft 9: Equal-cost paths through mutliple interfaces in a single link Thread-Index: AcaQaoI2xGcg2P2BSAaaKvAxyz6I0g== From: "Ramana Koppula-G20085" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [OSPF] OSPFv3 Draft 9: Equal-cost paths through mutliple interfaces in a single link X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0942105952==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============0942105952== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6906A.88E1AF31" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6906A.88E1AF31 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In Section 3.9: "The interfaces in this list are used as equal-cost paths when routes are installed in the routing table." =20 In the same Section: "If the Active Interface fails, another will have to take over, reforming all neighbor adjacencies from scratch." =20 The motive of equal-cost paths is to retain a route to a router even if one path goes down. By mandating the StandBy to reform all the neighbor adjacencies from scratch, are we not losing that edge. =20 thanx ramana ------_=_NextPart_001_01C6906A.88E1AF31 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

In Section 3.9: "The interfaces in this list are used as = equal-cost=20 paths when routes are installed = in the=20 routing table."

In the = same Section:=20 "If the Active Interface fails, another will have to take over, = reforming all=20 neighbor adjacencies from scratch."

The = motive of=20 equal-cost paths is to retain a route to a router even if one path goes=20 down.

By = mandating the=20 StandBy to reform all the neighbor adjacencies from scratch, are we not = losing=20 that edge.

thanx

ramana

------_=_NextPart_001_01C6906A.88E1AF31-- --===============0942105952== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0942105952==-- From ospf-bounces@ietf.org Thu Jun 15 12:59:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvBa-0003Kt-J4; Thu, 15 Jun 2006 12:59:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvBZ-0003Km-1w for ospf@ietf.org; Thu, 15 Jun 2006 12:59:13 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqvBX-0003I8-Iu for ospf@ietf.org; Thu, 15 Jun 2006 12:59:13 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 15 Jun 2006 09:58:49 -0700 X-IronPort-AV: i="4.06,137,1149490800"; d="scan'208"; a="1826322621:sNHT954351996" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k5FGwnXD024832; Thu, 15 Jun 2006 09:58:49 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5FGwnIs021296; Thu, 15 Jun 2006 09:58:49 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Jun 2006 09:58:49 -0700 Received: from cisco.com ([128.107.163.166]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Jun 2006 09:58:48 -0700 Message-ID: <449191C8.1010704@cisco.com> Date: Thu, 15 Jun 2006 09:58:48 -0700 From: Michael J Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ramana Koppula-G20085 Subject: Re: [OSPF] OSPFv3 Draft 9: Equal-cost paths through mutliple interfaces in a single link References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 16:58:48.0671 (UTC) FILETIME=[F898F6F0:01C6909C] DKIM-Signature: a=rsa-sha1; q=dns; l=1563; t=1150390729; x=1151254729; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjbarnes@cisco.com; z=From:Michael=20J=20Barnes=20 |Subject:Re=3A=20[OSPF]=20OSPFv3=20Draft=209=3A=20Equal-cost=20paths=20through=20 mutliple=20interfaces=0A=20in=20a=20single=20link; X=v=3Dcisco.com=3B=20h=3DINkHvxvPsuwaQHqeNwA0CRf4Wao=3D; b=frx0TKPitj6FW0DPhlAdV0qeZz5qC5E78iMEXnr57RChQvNCxvKnY01KM4VI/qNZgX8bVaEe FMIK0OX8xY8DzWhqYztuyQQXMIhdZK3hKasMksmV9cGKWgxKPBNjgUAq; Authentication-Results: sj-dkim-6.cisco.com; header.From=mjbarnes@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hello Ramana, There are a few reasons for the newly active interface to reform adjacencies. First is that it is unknown why the standby interface is no longer able to see the hello packets from the active. It is possible, for example, that the standby has been physically rewired such that it is connected to a different LAN, or a VLAN may have been reconfigured, and there are many other possibilities. On top of that, is that the standby has a different interface ID and also a different link-local address. It must be assured that the neighbors have the correct information. If the adjacencies are not reformed, then it is possible that the neighbors will keep out of date information in their neighbor data structure and/or LSAs. Thanks, Michael Ramana Koppula-G20085 wrote: > Hi, > > In Section 3.9: "The interfaces in this list are used as equal-cost > paths when routes are installed in the routing table." > > In the same Section: "If the Active Interface fails, another will have > to take over, reforming all neighbor adjacencies from scratch." > > The motive of equal-cost paths is to retain a route to a router even if > one path goes down. > By mandating the StandBy to reform all the neighbor adjacencies from > scratch, are we not losing that edge. > > thanx > ramana > > > ------------------------------------------------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jun 16 01:07:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr6Xt-0002h7-7n; Fri, 16 Jun 2006 01:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr6Xr-0002ak-4j for ospf@ietf.org; Fri, 16 Jun 2006 01:06:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr6Xr-0002fU-3B for ospf@ietf.org; Fri, 16 Jun 2006 01:06:59 -0400 Received: from london.unik.no ([193.156.97.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fr6Xn-0004rk-88 for ospf@ietf.org; Fri, 16 Jun 2006 01:06:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jun 2006 07:08:09 +0200 Message-ID: <093EBAF8333DBD49A5CC0A045175A6E8346F62@london.unik.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Implementation of a Wireless MANET Extension to OSPF Thread-Index: AcaRAtxc/L519j/0Si6JcS/LnM+8lg== From: "Andreas Hafslund" To: X-Spam-Score: -2.6 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kenneho@gmail.com Subject: [OSPF] Implementation of a Wireless MANET Extension to OSPF X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org All, Kenneth Holter at the UniK - University Graduate Center at Kjeller, and = the University of Oslo, has made an implementation of a Wireless MANET = Extension to OSPF. The implementation can be downloaded from here: http://folk.uio.no/kenneho/index.php?page=3Dstudies&subpage=3Dwospf Documentation of this implementation can be found here: http://folk.uio.no/kenneho/studies/master_thesis_Kenneth_Holter.pdf A technical report was presented at the 6th Scandinavian Workshop on = Wireless Ad-hoc Networks: "Design and Implementation of Wireless OSPF = for Mobile Ad Hoc Networks" by Kenneth Holter, Andreas Hafslund, Frank = Y. Li and Knut =D8vsthus. The report can be downloaded from here: http://www.wireless.kth.se/adhoc06/program.shtml The implementation is based on the IETF Internet-draft "Extensions to = OSPF to Support Mobile Ad Hoc Networking" by M Chandra, and it is a = patch for the Quagga 0.98.5 Routing Software Suite. Regards, Andreas. --=20 Andreas Hafslund Thales Norway AS _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jun 16 01:40:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr741-0006wv-SY; Fri, 16 Jun 2006 01:40:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr740-0006qS-Om for ospf@ietf.org; Fri, 16 Jun 2006 01:40:12 -0400 Received: from [203.199.83.136] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fr73z-0005o2-D0 for ospf@ietf.org; Fri, 16 Jun 2006 01:40:12 -0400 Received: (qmail 2585 invoked by uid 510); 16 Jun 2006 05:38:23 -0000 Date: 16 Jun 2006 05:38:23 -0000 Message-ID: <20060616053823.2584.qmail@webmail62.rediffmail.com> Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 16 jun 2006 05:38:23 -0000 MIME-Version: 1.0 From: "Vivek Dubey" To: "Michael J Barnes" Subject: Re: Re: [OSPF] OSPFv3 Draft 9: Equal-cost paths through mutliple interfaces in a single link X-Spam-Score: 0.3 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vivek Dubey List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1937190295==" Errors-To: ospf-bounces@ietf.org This is a multipart mime message --===============1937190295== Content-type: multipart/alternative; boundary="Next_1150436303---0-203.199.83.136-2580" This is a multipart mime message --Next_1150436303---0-203.199.83.136-2580 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, =A0=0AThere are a few reasons for the newly active interface to reform = adjacencies. First is that it is unknown why the standby interface is no lo= nger able to see the hello packets from the active. It is possible, for exa= mple, that the standby has been physically rewired such that it is connecte= d to a different LAN, or a VLAN may have been reconfigured, and there are m= any other possibilities.=0A=0A Reason is unknown no doubt when Activ= e's hellos are not seen.=0ABut to quote draft "This failure can be detected= by the router itself, when the other interfaces to the same link cease to = hear the router's own Hellos or through internal mechanisms such as when th= e interface is disabled by a configuration change"=0ASo in case of internal= mechanisms "reasons can be known".=0A=0AOn top of that, is that the standb= y has a different interface ID and also a different link-local address. It = must be assured that the neighbors have the correct information. If the adj= acencies are not reformed, then it is possible that the neighbors will keep= out of date information in their neighbor data structure and/or LSAs.=0A= =0A Re-origination of LSAs should be able to take care of this scena= rion. Section 3.4.3 of Draft 10 has few events which can play a role.=0A=0A= -Vivek=0A=0A=0A=0A=0A=0A=0A=0A=0AOn Thu, 15 Jun 2006 Michael J Barnes wrote= :=0A>Hello Ramana,=0A>=0A>There are a few reasons for the newly active int= erface to reform adjacencies. First is that it is unknown why the standby i= nterface is no longer able to see the hello packets from the active. It is = possible, for example, that the standby has been physically rewired such th= at it is connected to a different LAN, or a VLAN may have been reconfigured= , and there are many other possibilities. On top of that, is that the stand= by has a different interface ID and also a different link-local address. It= must be assured that the neighbors have the correct information. If the ad= jacencies are not reformed, then it is possible that the neighbors will kee= p out of date information in their neighbor data structure and/or LSAs.=0A>= =0A>Thanks,=0A>Michael=0A>=0A>Ramana Koppula-G20085 wrote:=0A>>Hi,=0A>> In= Section 3.9: "The interfaces in this list are used as equal-cost paths whe= n routes are installed in the routing table."=0A>> In the same Section: "I= f the Active Interface fails, another will have to take over, reforming all= neighbor adjacencies from scratch."=0A>> The motive of equal-cost paths i= s to retain a route to a router even if one path goes down.=0A>>By mandatin= g the StandBy to reform all the neighbor adjacencies from scratch, are we n= ot losing that edge.=0A>> thanx=0A>>ramana=0A>>=0A>>=0A>>-----------------= -------------------------------------------------------=0A>>=0A>>__________= _____________________________________=0A>>OSPF mailing list=0A>>OSPF@ietf.o= rg=0A>>https://www1.ietf.org/mailman/listinfo/ospf=0A>=0A>_________________= ______________________________=0A>OSPF mailing list=0A>OSPF@ietf.org=0A>htt= ps://www1.ietf.org/mailman/listinfo/ospf=0A --Next_1150436303---0-203.199.83.136-2580 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi,
=0AThere are a few reasons for the newly active interfa= ce to reform adjacencies. First is that it is unknown why the standby inter= face is no longer able to see the hello packets from the active. It is poss= ible, for example, that the standby has been physically rewired such that i= t is connected to a different LAN, or a VLAN may have been reconfigured, an= d there are many other possibilities.
=0A
=0A<vivek> Reason is = unknown no doubt when Active's hellos are not seen.
=0ABut to quote draf= t "This failure can be detected by the router itself, when the other i= nterfaces to the same link cease to hear the router's own Hellos or through= internal mechanisms such as when the interface is disabled by a configurat= ion change"
=0ASo in case of internal mechanisms "reasons can = be known".
=0A
=0AOn top of that, is that the standby has a diff= erent interface ID and also a different link-local address. It must be assu= red that the neighbors have the correct information. If the adjacencies are= not reformed, then it is possible that the neighbors will keep out of date= information in their neighbor data structure and/or LSAs.
=0A
=0A<= ;vivek> Re-origination of LSAs should be able to take care of this scena= rion. Section 3.4.3 of Draft 10 has few events which can play a role.
= =0A
=0A-Vivek
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0AOn Thu, 15 Jun 2006 Michael J Barnes wrote :
=0A>Hello Ramana,=0A>
=0A>There are a few reasons for the newly active interface t= o reform adjacencies. First is that it is unknown why the standby interface= is no longer able to see the hello packets from the active. It is possible= , for example, that the standby has been physically rewired such that it is= connected to a different LAN, or a VLAN may have been reconfigured, and th= ere are many other possibilities. On top of that, is that the standby has a= different interface ID and also a different link-local address. It must be= assured that the neighbors have the correct information. If the adjacencie= s are not reformed, then it is possible that the neighbors will keep out of= date information in their neighbor data structure and/or LSAs.
=0A><= BR>=0A>Thanks,
=0A>Michael
=0A>
=0A>Ramana Koppula-G20= 085 wrote:
=0A>>Hi,
=0A>> In Section 3.9: "The= interfaces in this list are used as equal-cost paths when routes are insta= lled in the routing table."
=0A>> In the same Section: = "If the Active Interface fails, another will have to take over, reform= ing all neighbor adjacencies from scratch."
=0A>> The m= otive of equal-cost paths is to retain a route to a router even if one path= goes down.
=0A>>By mandating the StandBy to reform all the neighb= or adjacencies from scratch, are we not losing that edge.
=0A>>&nb= sp; thanx
=0A>>ramana
=0A>>
=0A>>
=0A>>= ------------------------------------------------------------------------=0A>>
=0A>>_______________________________________________<= BR>=0A>>OSPF mailing list
=0A>>OSPF@ietf.org
=0A>>h= ttps://www1.ietf.org/mailman/listinfo/ospf
=0A>
=0A>___________= ____________________________________
=0A>OSPF mailing list
=0A>= OSPF@ietf.org
=0A>https://www1.ietf.org/mailman/listinfo/ospf
=0A= =0A

=0A

=0A

=0A --Next_1150436303---0-203.199.83.136-2580-- --===============1937190295== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1937190295==-- From ospf-bounces@ietf.org Fri Jun 16 18:30:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMpE-0007RO-DF; Fri, 16 Jun 2006 18:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMpD-0007RG-00 for ospf@ietf.org; Fri, 16 Jun 2006 18:29:59 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrMpB-0002yL-Lz for ospf@ietf.org; Fri, 16 Jun 2006 18:29:58 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2006 18:29:57 -0400 X-IronPort-AV: i="4.06,144,1149480000"; d="scan'208"; a="90261477:sNHT133131296" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5GMTtYL009674; Fri, 16 Jun 2006 18:29:55 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 18:29:55 -0400 Received: from [10.82.216.166] ([10.82.216.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 18:29:55 -0400 Message-ID: <4492D4D7.6070805@cisco.com> Date: Fri, 16 Jun 2006 11:57:11 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zengjie Kou Subject: Re: [OSPF] update "draft-kou-ospf-immediately-replying-hello-00.txt" References: <00a901c68ece$65b73330$96726e0a@china.huawei.com> In-Reply-To: <00a901c68ece$65b73330$96726e0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2006 22:29:55.0392 (UTC) FILETIME=[647FC400:01C69194] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org This draft was presented in Dallas. A show-of-hands poll in a Dallas was mixed with more people against than for making it accepting it as a working group document. We than tabled it to further discussion on the OSPF WG list. Speaking as a WG member, my personal opinion is that the WG should accept this document an an informational of BCP track RFC. 1. This behavior is not new - there are several implementations that already reply immediately in certain situations. 2. There are many ways of doing this and it is unlikely we will agree on the exact details of how it should be done. I, for one, have implemented it differently than documented in this draft. Thanks, Acee Zengjie Kou wrote: >hi,all > I updated the draft "draft-kou-ospf-immediately-replying-hello-00.txt". The link is following: >http://tools.ietf.org/wg/ospf/draft-kou-ospf-immediately-replying-hello-01.txt > In the new version, interoperation of immediate hello is added and the additional immediate hello >traffic is avoided by auto configuration. > The abstract is following: >This memo documents an extension of the OSPF protocol to reach > "ExStart" state more quickly. Currently, the OSPF behavior requires > the Hello Packet to be sent between the neighbors every > HelloInterval. This document proposes to generalize the use of > Immediately Replying Hello which could reduce the time required to > reach the OSPF "ExStart" state and expedite the routing table > convergence. > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sat Jun 17 08:56:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FraLw-0001ZV-Ol; Sat, 17 Jun 2006 08:56:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FraLv-0001ZQ-KG for ospf@ietf.org; Sat, 17 Jun 2006 08:56:39 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FraLu-0003qI-EE for ospf@ietf.org; Sat, 17 Jun 2006 08:56:39 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 17 Jun 2006 08:56:38 -0400 X-IronPort-AV: i="4.06,144,1149480000"; d="scan'208"; a="90293786:sNHT27331396" Received: from [10.82.216.143] (rtp-vpn3-143.cisco.com [10.82.216.143]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5HCuano002976; Sat, 17 Jun 2006 08:56:36 -0400 (EDT) Message-ID: <4493FC03.9000007@cisco.com> Date: Sat, 17 Jun 2006 08:56:35 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Acee Lindem Subject: Re: [OSPF] update "draft-kou-ospf-immediately-replying-hello-00.txt" References: <00a901c68ece$65b73330$96726e0a@china.huawei.com> <4492D4D7.6070805@cisco.com> In-Reply-To: <4492D4D7.6070805@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Speaking as a WG member, my personal opinion is that the WG should > accept this document an an informational of BCP track RFC. This sounds fine.... Count my vote in that direction, as well. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEk/wDER27sUhU9OQRAvY9AKCrebSk6VRgr6L/SJGB12m4ZErV0ACg1B+8 UKcbdXfJwL/u5nzZERpS7HI= =8pvC -----END PGP SIGNATURE----- _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sat Jun 17 15:09:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrgAO-00007Z-I3; Sat, 17 Jun 2006 15:09:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrgAN-00007U-7Y for ospf@ietf.org; Sat, 17 Jun 2006 15:09:07 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrgAK-00060n-U3 for ospf@ietf.org; Sat, 17 Jun 2006 15:09:07 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 17 Jun 2006 15:09:05 -0400 X-IronPort-AV: i="4.06,145,1149480000"; d="scan'208"; a="90308520:sNHT30032976" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5HJ93no024521; Sat, 17 Jun 2006 15:09:03 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Jun 2006 15:09:03 -0400 Received: from [10.82.216.166] ([10.82.216.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Jun 2006 15:09:02 -0400 Message-ID: <4494534E.1060804@cisco.com> Date: Sat, 17 Jun 2006 15:09:02 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ White Subject: Re: [OSPF] update "draft-kou-ospf-immediately-replying-hello-00.txt" References: <00a901c68ece$65b73330$96726e0a@china.huawei.com> <4492D4D7.6070805@cisco.com> <4493FC03.9000007@cisco.com> In-Reply-To: <4493FC03.9000007@cisco.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jun 2006 19:09:02.0895 (UTC) FILETIME=[7F106BF0:01C69241] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Zengjie, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > > >>Speaking as a WG member, my personal opinion is that the WG should >>accept this document an an informational of BCP track RFC. >> >> > >This sounds fine.... Count my vote in that direction, as well. > > Actually, I meant NOT accept as WG document I guess that what I get for trying to respond to E-mail sitting in the middle seat on a crowded plane. Here is my reasoning why: 1. This behavior is not new - there are several implementations that already reply immediately in certain situations. 2. There are many ways of doing this and it is unlikely we will agree on the exact details of how it should be done. I, for one, have implemented it differently than documented in this draft. I just don't think there is that much to be gained by documenting this after the fact when there isn't agreement on the sudtleties of operation. Sorry for the confusion. Thanks, Acee >:-) > >Russ > > > >- -- >riw@cisco.com CCIE <>< Grace Alone > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.2.2 (MingW32) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iD8DBQFEk/wDER27sUhU9OQRAvY9AKCrebSk6VRgr6L/SJGB12m4ZErV0ACg1B+8 >UKcbdXfJwL/u5nzZERpS7HI= >=8pvC >-----END PGP SIGNATURE----- > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Jun 19 02:55:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsDfc-0001bC-86; Mon, 19 Jun 2006 02:55:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsDfa-0001b2-7B for ospf@ietf.org; Mon, 19 Jun 2006 02:55:34 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsDfY-0002wb-Lu for ospf@ietf.org; Mon, 19 Jun 2006 02:55:34 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J13000K7HXDY0@szxga01-in.huawei.com> for ospf@ietf.org; Mon, 19 Jun 2006 14:56:01 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J13007KOHXDTD@szxga01-in.huawei.com> for ospf@ietf.org; Mon, 19 Jun 2006 14:56:01 +0800 (CST) Received: from k49110 ([10.110.114.150]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J13003OAICHRD@szxml04-in.huawei.com> for ospf@ietf.org; Mon, 19 Jun 2006 15:05:05 +0800 (CST) Date: Mon, 19 Jun 2006 14:54:22 +0800 From: Zengjie Kou Subject: Re: [OSPF] update "draft-kou-ospf-immediately-replying-hello-00.txt" To: Acee Lindem Message-id: <002e01c6936d$32361000$96726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00a901c68ece$65b73330$96726e0a@china.huawei.com> <4492D4D7.6070805@cisco.com> <4493FC03.9000007@cisco.com> <4494534E.1060804@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org hi,Acee For immediately replying, I'd like to know what are other implementations(including yours). Would you like to make them included in the dratf? I hope to discuss detailedly. What's your opinion? thanks Zengjie. ----- Original Message ----- From: "Acee Lindem" To: "Russ White" Cc: "Zengjie Kou" ; Sent: Sunday, June 18, 2006 3:09 AM Subject: Re: [OSPF] update "draft-kou-ospf-immediately-replying-hello-00.txt" > Hi Zengjie, > Russ White wrote: > >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >> >> >> >>>Speaking as a WG member, my personal opinion is that the WG should >>>accept this document an an informational of BCP track RFC. >>> >>> >> >>This sounds fine.... Count my vote in that direction, as well. >> >> > Actually, I meant NOT accept as WG document I guess that what I get for > trying > to respond to E-mail sitting in the middle seat on a crowded plane. Here > is my > reasoning why: > > 1. This behavior is not new - there are several implementations that > already reply immediately in certain situations. > 2. There are many ways of doing this and it is unlikely we will > agree on the exact details of how it should be done. I, for one, > have implemented it differently than documented in this draft. > > I just don't think there is that much to be gained by documenting > this after the fact when there isn't agreement on the sudtleties of > operation. > > Sorry for the confusion. > > Thanks, > Acee > >>:-) >> >>Russ >> >> >> >>- -- >>riw@cisco.com CCIE <>< Grace Alone >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.2.2 (MingW32) >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >>iD8DBQFEk/wDER27sUhU9OQRAvY9AKCrebSk6VRgr6L/SJGB12m4ZErV0ACg1B+8 >>UKcbdXfJwL/u5nzZERpS7HI= >>=8pvC >>-----END PGP SIGNATURE----- >> >> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From MAILER-DAEMON Mon Jun 19 03:14:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsDxH-0001Zz-Sy for ospf-archive@lists.ietf.org; Mon, 19 Jun 2006 03:13:51 -0400 Received: from mail.bcc.com.uz ([217.12.81.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsDkv-00044E-HN for ospf-archive@lists.ietf.org; Mon, 19 Jun 2006 03:01:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.bcc.com.uz (Postfix) with ESMTP id BBFE2196751 for ; Mon, 19 Jun 2006 12:01:02 +0500 (UZT) MIME-Version: 1.0 Subject: VIRUS (Worm.Mydoom.M) IN MAIL FROM YOU In-Reply-To: <20060619070055.34F2219679E@mail.bcc.com.uz> Message-Id: Content-Type: multipart/report; report-type=delivery-status; boundary="----------=_1150700462-8862-1" From: Automatic Anti-virus Mail Checking System To: Date: Mon, 19 Jun 2006 12:01:02 +0500 (UZT) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format... ------------=_1150700462-8862-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit VIRUS ALERT Our content checker found virus: Worm.Mydoom.M in email presumably from you (), to the following recipient: -> ipactr@bcc.com.uz Please check your system for viruses, or ask your system administrator to do so. Delivery of the email was stopped! For your reference, here are headers from your email: ------------------------- BEGIN HEADERS ----------------------------- Return-Path: Received: from lists.ietf.org (unknown [195.46.1.97]) by mail.bcc.com.uz (Postfix) with ESMTP id 34F2219679E for ; Mon, 19 Jun 2006 12:00:55 +0500 (UZT) From: ospf-archive@lists.ietf.org To: ugalumni@actr.bcc.com.uz Subject: ugalumni@actr.bcc.com.uz Date: Mon, 19 Jun 2006 10:00:15 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_77605556.D5ADB4F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20060619070055.34F2219679E@mail.bcc.com.uz> -------------------------- END HEADERS ------------------------------ ------------=_1150700462-8862-1 Content-Type: message/delivery-status Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Description: Delivery error report Reporting-MTA: dns; mail.bcc.com.uz Received-From-MTA: smtp; mail.bcc.com.uz ([127.0.0.1]) Arrival-Date: Mon, 19 Jun 2006 12:00:59 +0500 (UZT) Final-Recipient: rfc822; ipactr@bcc.com.uz Action: failed Status: 5.7.1 Diagnostic-Code: smtp; 550 5.7.1 Message content rejected, id=08862-02 - VIRUS: Worm.Mydoom.M Last-Attempt-Date: Mon, 19 Jun 2006 12:01:02 +0500 (UZT) ------------=_1150700462-8862-1 Content-Type: text/rfc822-headers Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Description: Undelivered-message headers Received: from lists.ietf.org (unknown [195.46.1.97]) by mail.bcc.com.uz (Postfix) with ESMTP id 34F2219679E for ; Mon, 19 Jun 2006 12:00:55 +0500 (UZT) From: ospf-archive@lists.ietf.org To: ugalumni@actr.bcc.com.uz Subject: ugalumni@actr.bcc.com.uz Date: Mon, 19 Jun 2006 10:00:15 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_77605556.D5ADB4F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20060619070055.34F2219679E@mail.bcc.com.uz> ------------=_1150700462-8862-1-- From ospf-bounces@ietf.org Mon Jun 19 05:22:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFxS-0005XT-0M; Mon, 19 Jun 2006 05:22:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFxQ-0005QS-IT for ospf@ietf.org; Mon, 19 Jun 2006 05:22:08 -0400 Received: from [203.199.83.147] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsFsU-0007tj-GY for ospf@ietf.org; Mon, 19 Jun 2006 05:17:04 -0400 Received: (qmail 2610 invoked by uid 510); 19 Jun 2006 08:43:37 -0000 Date: 19 Jun 2006 08:43:37 -0000 Message-ID: <20060619084337.2609.qmail@webmail25.rediffmail.com> Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 19 jun 2006 08:43:37 -0000 MIME-Version: 1.0 From: "Vivek Dubey" To: ospf@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [OSPF] Ospfv3 - Multiple Interfaces to same link X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vivek Dubey List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2090655595==" Errors-To: ospf-bounces@ietf.org This is a multipart mime message --===============2090655595== Content-type: multipart/alternative; boundary="Next_1150706617---0-203.199.83.147-2570" This is a multipart mime message --Next_1150706617---0-203.199.83.147-2570 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,=0AI'll like to know the views of WG on:=0A=0A1) Motivation for support = of multiple interfaces on the same link=0A That should give some hint as = to how the "ActiveInterfaceDead" =0A event be handled=0A=0A2) And in case= "Active" interface fails, why should neighbor adjacency =0A be reformed = with scratch? Is it mandatory behavior?=0A=0AThanks=0AVivek=0A --Next_1150706617---0-203.199.83.147-2570 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi,
=0AI'll like to know the views of WG on:
=0A
=0A1) Motiv= ation for support of multiple interfaces on the same link
=0A Tha= t should give some hint as to how the "ActiveInterfaceDead"
= =0A event be handled
=0A
=0A2) And in case "Active" = interface fails, why should neighbor adjacency
=0A be reformed w= ith scratch? Is it mandatory behavior?
=0A
=0AThanks
=0AVivek
= =0A=0A

=0A

=0A

=0A --Next_1150706617---0-203.199.83.147-2570-- --===============2090655595== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============2090655595==-- From ospf-bounces@ietf.org Mon Jun 19 05:57:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsGV9-0004iO-P7; Mon, 19 Jun 2006 05:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsGV9-0004iJ-Dj for ospf@ietf.org; Mon, 19 Jun 2006 05:56:59 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsGV8-0006oL-2h for ospf@ietf.org; Mon, 19 Jun 2006 05:56:59 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Jun 2006 11:56:57 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5J9uvrq007180; Mon, 19 Jun 2006 11:56:57 +0200 (MEST) Received: from mshand-wxp.cisco.com (ams3-vpn-dhcp4228.cisco.com [10.61.80.131]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA15462; Mon, 19 Jun 2006 10:56:56 +0100 (BST) Message-Id: <7.0.1.0.0.20060619105457.02108aa0@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 19 Jun 2006 10:56:24 +0100 To: Acee Lindem From: mike shand Subject: Re: [OSPF] update "draft-kou-ospf-immediately-replying-hello-00.txt" In-Reply-To: <4494534E.1060804@cisco.com> References: <00a901c68ece$65b73330$96726e0a@china.huawei.com> <4492D4D7.6070805@cisco.com> <4493FC03.9000007@cisco.com> <4494534E.1060804@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org At 20:09 17/06/2006, Acee Lindem wrote: >Hi Zengjie, >Russ White wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > > > > > > > >>Speaking as a WG member, my personal opinion is that the WG should > >>accept this document an an informational of BCP track RFC. > >> > >> > > > >This sounds fine.... Count my vote in that direction, as well. > > > > >Actually, I meant NOT accept as WG document I guess that what I get for >trying >to respond to E-mail sitting in the middle seat on a crowded plane. Here >is my >reasoning why: > >1. This behavior is not new - there are several implementations that >already reply immediately in certain situations. >2. There are many ways of doing this and it is unlikely we will >agree on the exact details of how it should be done. I, for one, >have implemented it differently than documented in this draft. and more particularly it doesn't matter from an interoperability point of view which way you do it, so this doesn't seem to be behaviour which it makes sense to standardize. Mike >I just don't think there is that much to be gained by documenting >this after the fact when there isn't agreement on the sudtleties of >operation. > >Sorry for the confusion. > >Thanks, >Acee > > >:-) > > > >Russ > > > > > > > >- -- > >riw@cisco.com CCIE <>< Grace Alone > > > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.4.2.2 (MingW32) > >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > >iD8DBQFEk/wDER27sUhU9OQRAvY9AKCrebSk6VRgr6L/SJGB12m4ZErV0ACg1B+8 > >UKcbdXfJwL/u5nzZERpS7HI= > >=8pvC > >-----END PGP SIGNATURE----- > > > > > > > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Jun 19 07:34:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsI1k-0002M8-UL; Mon, 19 Jun 2006 07:34:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsI1j-0002M3-H8 for ospf@ietf.org; Mon, 19 Jun 2006 07:34:43 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsI1h-0002uA-K6 for ospf@ietf.org; Mon, 19 Jun 2006 07:34:43 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1300K8ZVBHTG@szxga02-in.huawei.com> for ospf@ietf.org; Mon, 19 Jun 2006 19:45:17 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1300CPAVBH7N@szxga02-in.huawei.com> for ospf@ietf.org; Mon, 19 Jun 2006 19:45:17 +0800 (CST) Received: from k49110 ([10.110.114.150]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J130045WV2PGC@szxml04-in.huawei.com> for ospf@ietf.org; Mon, 19 Jun 2006 19:40:02 +0800 (CST) Date: Mon, 19 Jun 2006 19:29:20 +0800 From: Zengjie Kou Subject: Re: [OSPF] update "draft-kou-ospf-immediately-replying-hello-00.txt" To: mike shand , Acee Lindem Message-id: <001901c69393$9ba00930$96726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00a901c68ece$65b73330$96726e0a@china.huawei.com> <4492D4D7.6070805@cisco.com> <4493FC03.9000007@cisco.com> <4494534E.1060804@cisco.com> <7.0.1.0.0.20060619105457.02108aa0@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org hi, mike For interoperability of the immediate hello, i think it is necessary. If each implementation is independent, the mechanism will be not consistent and the effort of immediate hello will be small. If we standardize the implementation or mechanism, all the router supporting immediate hello will respond conformably. The effort will be great. The experiment data in the draft shows some evident benefits with immediate hello consistent interoperability. thanks Zengjie ----- Original Message ----- From: "mike shand" To: "Acee Lindem" Cc: Sent: Monday, June 19, 2006 5:56 PM Subject: Re: [OSPF] update "draft-kou-ospf-immediately-replying-hello-00.txt" > At 20:09 17/06/2006, Acee Lindem wrote: >>Hi Zengjie, >>Russ White wrote: >> >> >-----BEGIN PGP SIGNED MESSAGE----- >> >Hash: SHA1 >> > >> > >> > >> > >> >>Speaking as a WG member, my personal opinion is that the WG should >> >>accept this document an an informational of BCP track RFC. >> >> >> >> >> > >> >This sounds fine.... Count my vote in that direction, as well. >> > >> > >>Actually, I meant NOT accept as WG document I guess that what I get for >>trying >>to respond to E-mail sitting in the middle seat on a crowded plane. Here >>is my >>reasoning why: >> >>1. This behavior is not new - there are several implementations that >>already reply immediately in certain situations. >>2. There are many ways of doing this and it is unlikely we will >>agree on the exact details of how it should be done. I, for one, >>have implemented it differently than documented in this draft. > > and more particularly it doesn't matter from an interoperability > point of view which way you do it, so > this doesn't seem to be behaviour which it makes sense to standardize. > > Mike > > > >>I just don't think there is that much to be gained by documenting >>this after the fact when there isn't agreement on the sudtleties of >>operation. >> >>Sorry for the confusion. >> >>Thanks, >>Acee >> >> >:-) >> > >> >Russ >> > >> > >> > >> >- -- >> >riw@cisco.com CCIE <>< Grace Alone >> > >> >-----BEGIN PGP SIGNATURE----- >> >Version: GnuPG v1.4.2.2 (MingW32) >> >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> > >> >iD8DBQFEk/wDER27sUhU9OQRAvY9AKCrebSk6VRgr6L/SJGB12m4ZErV0ACg1B+8 >> >UKcbdXfJwL/u5nzZERpS7HI= >> >=8pvC >> >-----END PGP SIGNATURE----- >> > >> > >> > >> >>_______________________________________________ >>OSPF mailing list >>OSPF@ietf.org >>https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jun 20 06:47:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdln-0006eF-GL; Tue, 20 Jun 2006 06:47:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdlm-0006eA-RI for ospf@ietf.org; Tue, 20 Jun 2006 06:47:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsdll-0001ar-Dt for ospf@ietf.org; Tue, 20 Jun 2006 06:47:42 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsdlk-0006G4-NG; Tue, 20 Jun 2006 10:47:40 +0000 Date: Tue, 20 Jun 2006 03:47:33 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1941664064.20060620034733@psg.com> To: Zengjie Kou Subject: Re: [OSPF] update "draft-kou-ospf-immediately-replying-hello-00.txt" In-Reply-To: <001901c69393$9ba00930$96726e0a@china.huawei.com> References: <00a901c68ece$65b73330$96726e0a@china.huawei.com> <4492D4D7.6070805@cisco.com> <4493FC03.9000007@cisco.com> <4494534E.1060804@cisco.com> <7.0.1.0.0.20060619105457.02108aa0@cisco.com> <001901c69393$9ba00930$96726e0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Zengjie, I could only see two potential reasons for the IETF to publish a document of this kind: a) if proposed behavior affected interoperability and thus correct network behavior OR b) we wanted to encourage implementers to introduce certain optimizations so as to improve overall network experience for the user Unfortunately, the situation at hand doesn't qualify for either of the two: a) timing of hellos does not affect protocol correctness AND b) there's no need to encourage this behavior as people actually do that already. So, it has nothing to do with how good your idea is, but rather that there is no apparent need for a document. BTW, I personally don't see a need for this doc either. -- Alex http://www.psg.com/~zinin Monday, June 19, 2006, 4:29:20 AM, Zengjie Kou wrote: > hi, mike > For interoperability of the immediate hello, i think it is necessary. > If each implementation is independent, the mechanism will be not > consistent and the effort of immediate hello will be small. > If we standardize the implementation or mechanism, all the router > supporting immediate hello will respond conformably. The > effort will be great. > The experiment data in the draft shows some evident benefits with > immediate hello consistent interoperability. > thanks > Zengjie > ----- Original Message ----- > From: "mike shand" > To: "Acee Lindem" > Cc: > Sent: Monday, June 19, 2006 5:56 PM > Subject: Re: [OSPF] update > "draft-kou-ospf-immediately-replying-hello-00.txt" >> At 20:09 17/06/2006, Acee Lindem wrote: >>>Hi Zengjie, >>>Russ White wrote: >>> >>> >-----BEGIN PGP SIGNED MESSAGE----- >>> >Hash: SHA1 >>> > >>> > >>> > >>> > >>> >>Speaking as a WG member, my personal opinion is that the WG should >>> >>accept this document an an informational of BCP track RFC. >>> >> >>> >> >>> > >>> >This sounds fine.... Count my vote in that direction, as well. >>> > >>> > >>>Actually, I meant NOT accept as WG document I guess that what I get for >>>trying >>>to respond to E-mail sitting in the middle seat on a crowded plane. Here >>>is my >>>reasoning why: >>> >>>1. This behavior is not new - there are several implementations that >>>already reply immediately in certain situations. >>>2. There are many ways of doing this and it is unlikely we will >>>agree on the exact details of how it should be done. I, for one, >>>have implemented it differently than documented in this draft. >> >> and more particularly it doesn't matter from an interoperability >> point of view which way you do it, so >> this doesn't seem to be behaviour which it makes sense to standardize. >> >> Mike >> >> >> >>>I just don't think there is that much to be gained by documenting >>>this after the fact when there isn't agreement on the sudtleties of >>>operation. >>> >>>Sorry for the confusion. >>> >>>Thanks, >>>Acee >>> >>> >:-) >>> > >>> >Russ >>> > >>> > >>> > >>> >- -- >>> >riw@cisco.com CCIE <>< Grace Alone >>> > >>> >-----BEGIN PGP SIGNATURE----- >>> >Version: GnuPG v1.4.2.2 (MingW32) >>> >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> > >>> >iD8DBQFEk/wDER27sUhU9OQRAvY9AKCrebSk6VRgr6L/SJGB12m4ZErV0ACg1B+8 >>> >UKcbdXfJwL/u5nzZERpS7HI= >>> >=8pvC >>> >-----END PGP SIGNATURE----- >>> > >>> > >>> > >>> >>>_______________________________________________ >>>OSPF mailing list >>>OSPF@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jun 20 09:20:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsg9a-0004dx-3d; Tue, 20 Jun 2006 09:20:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsg9Z-0004dl-Fu for ospf@ietf.org; Tue, 20 Jun 2006 09:20:25 -0400 Received: from [203.199.83.135] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fsg9X-0007i0-C3 for ospf@ietf.org; Tue, 20 Jun 2006 09:20:25 -0400 Received: (qmail 9283 invoked by uid 510); 20 Jun 2006 13:18:34 -0000 Date: 20 Jun 2006 13:18:34 -0000 Message-ID: <20060620131834.9282.qmail@webmail45.rediffmail.com> Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 20 jun 2006 13:18:34 -0000 MIME-Version: 1.0 From: "Vivek Dubey" To: ospf@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [OSPF] Question: Intra-area Prefix Lsa X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vivek Dubey List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0581328372==" Errors-To: ospf-bounces@ietf.org This is a multipart mime message --===============0581328372== Content-type: multipart/alternative; boundary="Next_1150809514---0-203.199.83.135-9270" This is a multipart mime message --Next_1150809514---0-203.199.83.135-9270 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,=0AQueries tagged by for (3) cases listed below.=0A=0A1) Case1: = Transit Link=0A----------------------=0ADraft quote=0A"Each IPv6 address pr= efix that has been configured on Link L is added to the link-LSA by specify= ing values for PrefixLength, PrefixOptions, and Address Prefix fields"=0A= =0ASo prefix can be:=0Aa) Global Ipv6 address (LA bit) i.e global ipv6 addr= ess associated =0A with the link (RFC 4293 ipAddressTable)=0Ab) Global Ip= v6 Prefix i.e global ipv6 prefix associated with the link =0A (RFC 4293 i= pAddressPrefixTable)=0Ac) Further (a) can be part of (b) or independent (RF= C 4293 =0A ipAddressPrefix)=0A=0AFurther while DR builds an intra-area-pr= efix lsa associated with the network LSA=0A=0ADraft quote=0A"the list of pr= efixes in the link-LSA is copied into the intra-area-prefix-LSA that is bei= ng built. Prefixes having the NU-bit and/or LA-bit set in their Options fi= eld SHOULD NOT be copied, nor should link-local addresses be copied"=0A=0A<= vivek1> Since DR does not use prefixes having NU/LA bit set while =0A = originating intra-area-prefix lsa, why should they be made =0A p= art of link lsa originated for the transit link=0A=0A If global ipv= 6 address associated with the link, is not part =0A of global ipv6 = address prefix of the link, how would that be =0A reachable in the = Ospf domain, as DR does not advertise such =0A prefixes (LA bit set= ), in the intra-area-prefix LSA=0A=0A2) Case2: P2P link=0A-----------------= --=0AThe link prefixes can be:=0Aa) Global Ipv6 address (LA bit) i.e global= ipv6 address associated=0A with the link (RFC 4293 ipAddressTable)=0Ab) = Global Ipv6 Prefix i.e global ipv6 prefix associated with the link =0A (RF= C 4293 ipAddressPrefixTable)=0Ac) The entry (a) part of prefix (b) above (R= FC 4293 ipAddressPrefix)=0Ad) The entry (a) NOT part of prefix (b) above (R= FC 4293 =0A ipAddressPrefix being NULL)=0A=0A Should intra-area p= refix Lsa associated with the router =0A include separate entry for= :=0A a) Global Ipv6 address (LA bit)=0A b) Global Ipv6 Prefix i.e global = ipv6 prefix associated with =0A the link=0A=0A If (c) ab= ove is TRUE, should (a) be included separately or =0A just (b) woul= d do?=0A=0A3) Case3: Stub Link=0A--------------------=0AThe link prefixes c= an be:=0Aa) Global Ipv6 address (LA bit) i.e global ipv6 address associated= =0A with the link (RFC 4293 ipAddressTable)=0Ab) Global Ipv6 Prefix i.e = global ipv6 prefix associated with the link =0A (RFC 4293 ipAddressPrefix= Table)=0Ac) The entry (a) part of prefix (b) above (RFC 4293 ipAddressPrefi= x)=0Ad) The entry (a) NOT part of prefix (b) above (RFC 4293 =0A ipAddres= sPrefix being NULL)=0A=0A Should intra-area prefix Lsa associated w= ith the router =0A include separate entry for:=0A a) Global Ipv6 a= ddress (LA bit)=0A b) Global Ipv6 Prefix i.e global ipv6 prefix associated= with =0A the link=0A=0A In (c) above is TRUE, should (a= ) be included separately or =0A just (b) would do?=0A=0AThanks=0AVi= vek=0A=0A --Next_1150809514---0-203.199.83.135-9270 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi,
=0AQueries tagged by <vivek> for (3) cases listed below.=
=0A
=0A1) Case1: Transit Link
=0A----------------------
=0ADra= ft quote
=0A"Each IPv6 address prefix that has been configured on L= ink L is added to the link-LSA by specifying values for PrefixLength, Prefi= xOptions, and Address Prefix fields"
=0A
=0ASo prefix can be:=0Aa) Global Ipv6 address (LA bit) i.e global ipv6 address associated
= =0A with the link (RFC 4293 ipAddressTable)
=0Ab) Global Ipv6 Pre= fix i.e global ipv6 prefix associated with the link
=0A (RFC 429= 3 ipAddressPrefixTable)
=0Ac) Further (a) can be part of (b) or independ= ent (RFC 4293
=0A ipAddressPrefix)
=0A
=0AFurther while DR= builds an intra-area-prefix lsa associated with the network LSA
=0A
= =0ADraft quote
=0A"the list of prefixes in the link-LSA is copied i= nto the intra-area-prefix-LSA that is being built. Prefixes having th= e NU-bit and/or LA-bit set in their Options field SHOULD NOT be copied, nor= should link-local addresses be copied"
=0A
=0A<vivek1> Si= nce DR does not use prefixes having NU/LA bit set while
=0A = ; originating intra-area-prefix lsa, why should they be made=
=0A part of link lsa originated for the tr= ansit link
=0A
=0A<vivek2> If global ipv6 address associated wi= th the link, is not part
=0A of global ipv6= address prefix of the link, how would that be
=0A = reachable in the Ospf domain, as DR does not advertise such
=0A= prefixes (LA bit set), in the intra-area-prefi= x LSA
=0A
=0A2) Case2: P2P link
=0A-------------------
=0AThe l= ink prefixes can be:
=0Aa) Global Ipv6 address (LA bit) i.e global ipv6 = address associated
=0A with the link (RFC 4293 ipAddressTable)=0Ab) Global Ipv6 Prefix i.e global ipv6 prefix associated with the link <= BR>=0A (RFC 4293 ipAddressPrefixTable)
=0Ac) The entry (a) part of= prefix (b) above (RFC 4293 ipAddressPrefix)
=0Ad) The entry (a) NOT par= t of prefix (b) above (RFC 4293
=0A ipAddressPrefix being NULL)<= BR>=0A
=0A<vivek3> Should intra-area prefix Lsa associated with th= e router
=0A include separate entry for:=0A a) Global Ipv6 address (LA bit)
=0A = ; b) Global Ipv6 Prefix i.e global ipv6 prefix associated with
= =0A the link
=0A
=0A<vive= k4> If (c) above is TRUE, should (a) be included separately or
=0A&n= bsp; just (b) would do?
=0A
=0A3) Case3: Stub L= ink
=0A--------------------
=0AThe link prefixes can be:
=0Aa) Glo= bal Ipv6 address (LA bit) i.e global ipv6 address associated
=0A = with the link (RFC 4293 ipAddressTable)
=0Ab) Global Ipv6 Prefix i.e gl= obal ipv6 prefix associated with the link
=0A (RFC 4293 ipAddres= sPrefixTable)
=0Ac) The entry (a) part of prefix (b) above (RFC 4293 ipA= ddressPrefix)
=0Ad) The entry (a) NOT part of prefix (b) above (RFC 4293=
=0A ipAddressPrefix being NULL)
=0A
=0A<vivek5> Sho= uld intra-area prefix Lsa associated with the router
=0A &= nbsp; include separate entry for:
=0A a) Glo= bal Ipv6 address (LA bit)
=0A b) Global Ipv6 Prefix = i.e global ipv6 prefix associated with
=0A &= nbsp; the link
=0A
=0A<vivek6> In (c) above is TRUE, sho= uld (a) be included separately or
=0A just = (b) would do?
=0A
=0AThanks
=0AVivek
=0A
=0A=0A

=0A
=0A

=0A --Next_1150809514---0-203.199.83.135-9270-- --===============0581328372== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0581328372==-- From ospf-bounces@ietf.org Tue Jun 20 10:21:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsh6d-00083M-Lg; Tue, 20 Jun 2006 10:21:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsh6c-000832-Cr for ospf@ietf.org; Tue, 20 Jun 2006 10:21:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsh6b-0004qh-Pt for ospf@ietf.org; Tue, 20 Jun 2006 10:21:26 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 20 Jun 2006 07:21:22 -0700 X-IronPort-AV: i="4.06,156,1149490800"; d="scan'208"; a="297746118:sNHT1529285726" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5KELLGe022358; Tue, 20 Jun 2006 07:21:21 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5KELFcT014889; Tue, 20 Jun 2006 07:21:21 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 10:21:18 -0400 Received: from [10.82.216.166] ([10.82.216.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 10:21:17 -0400 Message-ID: <4498045D.1060600@cisco.com> Date: Tue, 20 Jun 2006 10:21:17 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vivek Dubey Subject: Re: [OSPF] Question: Intra-area Prefix Lsa References: <20060620131834.9282.qmail@webmail45.rediffmail.com> In-Reply-To: <20060620131834.9282.qmail@webmail45.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 14:21:17.0975 (UTC) FILETIME=[CB9BF270:01C69474] DKIM-Signature: a=rsa-sha1; q=dns; l=4945; t=1150813281; x=1151677281; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20Question=3A=20Intra-area=20Prefix=20Lsa; X=v=3Dcisco.com=3B=20h=3DTyh88E8vdTYHQWoKGcZ5ZCvC4AU=3D; b=W5/T4nhYRdE6vU50/9KorxcgYCJ6JUHGepBZE68w91thiPITXrXGNI2f85dUzuPRZzvxtYTB uCEA+WYe706qT5XtyzJrvCNYPqp0cu6Y5wbDg1bQBSgjsSHHY5DADePX; Authentication-Results: sj-dkim-7.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Vivek, Vivek Dubey wrote: >Hi, >Queries tagged by for (3) cases listed below. > >1) Case1: Transit Link >---------------------- >Draft quote >"Each IPv6 address prefix that has been configured on Link L is added to the link-LSA by specifying values for PrefixLength, PrefixOptions, and Address Prefix fields" > >So prefix can be: >a) Global Ipv6 address (LA bit) i.e global ipv6 address associated > with the link (RFC 4293 ipAddressTable) >b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the link > (RFC 4293 ipAddressPrefixTable) >c) Further (a) can be part of (b) or independent (RFC 4293 > ipAddressPrefix) > >Further while DR builds an intra-area-prefix lsa associated with the network LSA > >Draft quote >"the list of prefixes in the link-LSA is copied into the intra-area-prefix-LSA that is being built. Prefixes having the NU-bit and/or LA-bit set in their Options field SHOULD NOT be copied, nor should link-local addresses be copied" > > Since DR does not use prefixes having NU/LA bit set while > originating intra-area-prefix lsa, why should they be made > part of link lsa originated for the transit link > > The link-LSA has always included a complete set of prefixes for the link. In the case where the multi-access network has only one connected router, the prefixes will be advertised in the intra-area-prefix LSA associated with the router and will be more useful. Note that for all link types other than broadcast and NBMA, the prefixes in the link LSA are NOT used and the link-LSA could, in fact, be limited to the link-local address. Maybe, I should document this as an option. I've been somewhat hesitant to provide additional capabilities in the respin since the purpose is mainly to correct and clarify what is currently in RFC 2740. IMHO, we should have deprecated MOSPF which would have gotten rid of the NU and MC bits. However, there was some opposition to this - perhaps, we will be able to do it in the future. > If global ipv6 address associated with the link, is not part > of global ipv6 address prefix of the link, how would that be > reachable in the Ospf domain, as DR does not advertise such > prefixes (LA bit set), in the intra-area-prefix LSA > > A router that has a virtual link is responsible for advertising at least one address with the LA-bit set in the intra-area-prefix-LSA corresponding to the router. If it is necessary for this address to be the interface address of a multi-access link, it would be advertised there. For the other cases where the draft dictates that the LA-bit is set, the DR isn't applicable (loopback and Point-to-Multipoint interfaces). >2) Case2: P2P link >------------------- >The link prefixes can be: >a) Global Ipv6 address (LA bit) i.e global ipv6 address associated > with the link (RFC 4293 ipAddressTable) >b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the link > (RFC 4293 ipAddressPrefixTable) >c) The entry (a) part of prefix (b) above (RFC 4293 ipAddressPrefix) >d) The entry (a) NOT part of prefix (b) above (RFC 4293 > ipAddressPrefix being NULL) > > Should intra-area prefix Lsa associated with the router > include separate entry for: > a) Global Ipv6 address (LA bit) > b) Global Ipv6 Prefix i.e global ipv6 prefix associated with > the link > > If (c) above is TRUE, should (a) be included separately or > just (b) would do? > > For P2P links, the global IPv6 address with the LA-bit set should only be advertised if it necessary to provide an endpoint for a virtual link. In this case, both the global prefix and the local address (i.e., /128) should be advertised. >3) Case3: Stub Link >-------------------- >The link prefixes can be: >a) Global Ipv6 address (LA bit) i.e global ipv6 address associated > with the link (RFC 4293 ipAddressTable) >b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the link > (RFC 4293 ipAddressPrefixTable) >c) The entry (a) part of prefix (b) above (RFC 4293 ipAddressPrefix) >d) The entry (a) NOT part of prefix (b) above (RFC 4293 > ipAddressPrefix being NULL) > > Should intra-area prefix Lsa associated with the router > include separate entry for: > a) Global Ipv6 address (LA bit) > b) Global Ipv6 Prefix i.e global ipv6 prefix associated with > the link > > In (c) above is TRUE, should (a) be included separately or > just (b) would do? > > Same as P2P links. Thanks, Acee >Thanks >Vivek > > > > >------------------------------------------------------------------------ > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jun 20 13:06:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsjgS-0002B6-4j; Tue, 20 Jun 2006 13:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsjgQ-000266-Ow for ospf@ietf.org; Tue, 20 Jun 2006 13:06:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsjgP-0000VD-GF for ospf@ietf.org; Tue, 20 Jun 2006 13:06:34 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 20 Jun 2006 10:06:33 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,157,1149490800"; d="scan'208"; a="30052235:sNHT22725364" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5KH6WYL004562; Tue, 20 Jun 2006 13:06:32 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 13:06:32 -0400 Received: from [10.82.216.166] ([10.82.216.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 13:06:31 -0400 Message-ID: <44982B17.9060802@cisco.com> Date: Tue, 20 Jun 2006 13:06:31 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zengjie Kou Subject: Re: [OSPF] update "draft-kou-ospf-immediately-replying-hello-00.txt" References: <00a901c68ece$65b73330$96726e0a@china.huawei.com> <4492D4D7.6070805@cisco.com> <4493FC03.9000007@cisco.com> <4494534E.1060804@cisco.com> <002e01c6936d$32361000$96726e0a@china.huawei.com> In-Reply-To: <002e01c6936d$32361000$96726e0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 17:06:32.0061 (UTC) FILETIME=[E0DD6AD0:01C6948B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Zengjie, Zengjie Kou wrote: >hi,Acee > For immediately replying, I'd like to know what are other implementations(including yours). > > The two that I've worked on most recently for sure. I also seem to remember someone saying their variant of Zebra had this modification. I'll let others speak for their own implementations. >Would you like to make them included in the dratf? I hope to discuss detailedly. >What's your opinion? > > As I previously stated, I'm not all the high on trying to standardize the immediate reply behavior. Thanks, Acee >thanks >Zengjie. > >----- Original Message ----- >From: "Acee Lindem" >To: "Russ White" >Cc: "Zengjie Kou" ; >Sent: Sunday, June 18, 2006 3:09 AM >Subject: Re: [OSPF] update "draft-kou-ospf-immediately-replying-hello-00.txt" > > > > >>Hi Zengjie, >>Russ White wrote: >> >> >> >>>-----BEGIN PGP SIGNED MESSAGE----- >>>Hash: SHA1 >>> >>> >>> >>> >>> >>> >>>>Speaking as a WG member, my personal opinion is that the WG should >>>>accept this document an an informational of BCP track RFC. >>>> >>>> >>>> >>>> >>>This sounds fine.... Count my vote in that direction, as well. >>> >>> >>> >>> >>Actually, I meant NOT accept as WG document I guess that what I get for >>trying >>to respond to E-mail sitting in the middle seat on a crowded plane. Here >>is my >>reasoning why: >> >>1. This behavior is not new - there are several implementations that >>already reply immediately in certain situations. >>2. There are many ways of doing this and it is unlikely we will >>agree on the exact details of how it should be done. I, for one, >>have implemented it differently than documented in this draft. >> >>I just don't think there is that much to be gained by documenting >>this after the fact when there isn't agreement on the sudtleties of >>operation. >> >>Sorry for the confusion. >> >>Thanks, >>Acee >> >> >> >>>:-) >>> >>>Russ >>> >>> >>> >>>- -- >>>riw@cisco.com CCIE <>< Grace Alone >>> >>>-----BEGIN PGP SIGNATURE----- >>>Version: GnuPG v1.4.2.2 (MingW32) >>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>>iD8DBQFEk/wDER27sUhU9OQRAvY9AKCrebSk6VRgr6L/SJGB12m4ZErV0ACg1B+8 >>>UKcbdXfJwL/u5nzZERpS7HI= >>>=8pvC >>>-----END PGP SIGNATURE----- >>> >>> >>> >>> >>> > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From postmaster@lists.ietf.org Tue Jun 20 20:12:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsqKD-0008Mx-BE for ospf-archive@lists.ietf.org; Tue, 20 Jun 2006 20:12:05 -0400 Received: from imf24aec.mail.bellsouth.net ([205.152.59.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsqKC-0002XA-3E for ospf-archive@lists.ietf.org; Tue, 20 Jun 2006 20:12:05 -0400 Received: from ibm56aec-qfe0 ([192.168.51.66]) by imf24aec.mail.bellsouth.net with ESMTP id <20060621001203.TBUC27842.imf24aec.mail.bellsouth.net@ibm56aec-qfe0> for ; Tue, 20 Jun 2006 20:12:03 -0400 Received: from ibm56aec.bellsouth.net ([67.35.253.151]) by imf16aec.mail.bellsouth.net with ESMTP id <20060621000646.IDTJ6799.imf16aec.mail.bellsouth.net@ibm56aec.bellsouth.net> for ; Tue, 20 Jun 2006 20:06:46 -0400 Received: from lists.ietf.org ([67.35.253.151]) by ibm56aec.bellsouth.net with ESMTP id <20060621000641.IWSV8102.ibm56aec.bellsouth.net@lists.ietf.org> for ; Tue, 20 Jun 2006 20:06:41 -0400 From: "Automatic Email Delivery Software" To: ospf-archive@lists.ietf.org Subject: ospf-archive@lists.ietf.org Date: Tue, 20 Jun 2006 19:05:38 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20060621000641.IWSV8102.ibm56aec.bellsouth.net@lists.ietf.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SVWYZabcefghiklmnoprstuvwyz012356789ACDE" X-BLTSYMAVREINSERT: PtIrju6Y4UTshrHSbl6Xn4ifn9cA X-Spam-Score: 4.5 (++++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is a multi-part message in MIME format. --SVWYZabcefghiklmnoprstuvwyz012356789ACDE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This message has been processed by Symantec AntiVirus. message.scr was infected with the malicious virus W32.Mydoom!gen and has been deleted because the file cannot be cleaned. --SVWYZabcefghiklmnoprstuvwyz012356789ACDE Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ibm56aec.bellsouth.net ([67.35.253.151]) by imf16aec.mail.bellsouth.net with ESMTP id <20060621000646.IDTJ6799.imf16aec.mail.bellsouth.net@ibm56aec.bellsouth.net> for ; Tue, 20 Jun 2006 20:06:46 -0400 Received: from lists.ietf.org ([67.35.253.151]) by ibm56aec.bellsouth.net with ESMTP id <20060621000641.IWSV8102.ibm56aec.bellsouth.net@lists.ietf.org> for ; Tue, 20 Jun 2006 20:06:41 -0400 From: "Automatic Email Delivery Software" To: ospf-archive@lists.ietf.org Subject: ospf-archive@lists.ietf.org Date: Tue, 20 Jun 2006 19:05:38 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_8AF3720F.70AA4D9F" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20060621000641.IWSV8102.ibm56aec.bellsouth.net@lists.ietf.org> This is a multi-part message in MIME format. ------=_NextPart_000_0014_8AF3720F.70AA4D9F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The original message was received at Tue, 20 Jun 2006 19:05:38 -0500 from lists.ietf.org [51.113.28.249] ----- The following addresses had permanent fatal errors ----- ospf-archive@lists.ietf.org ----- Transcript of session follows ----- ... while talking to lists.ietf.org.: 554 ... Message is too large 554 ... Service unavailable ------=_NextPart_000_0014_8AF3720F.70AA4D9F Content-Type: application/octet-stream; name="message.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="message.zip" UEsDBBQAAAAIALMA1TQOxcvXCAAAABYAAAALAAAAbWVzc2FnZS56aXAL8GZlY8AAAFBLAQIU ABQAAAAIALMA1TQOxcvXCAAAABYAAAALAAAAAAAAAAAAAAAAAAAAAABtZXNzYWdlLnppcFBL BQYAAAAAAQABADkAAAAxAAAAAAA= ------=_NextPart_000_0014_8AF3720F.70AA4D9F-- --SVWYZabcefghiklmnoprstuvwyz012356789ACDE-- From ospf-bounces@ietf.org Wed Jun 21 04:14:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsxqk-0003Em-36; Wed, 21 Jun 2006 04:14:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsxqj-0003Ed-3w for ospf@ietf.org; Wed, 21 Jun 2006 04:14:09 -0400 Received: from [203.199.83.248] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fsxqf-0005e6-3S for ospf@ietf.org; Wed, 21 Jun 2006 04:14:09 -0400 Received: (qmail 18146 invoked by uid 510); 21 Jun 2006 08:12:11 -0000 Date: 21 Jun 2006 08:12:11 -0000 Message-ID: <20060621081211.18145.qmail@webmail36.rediffmail.com> Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 21 jun 2006 08:12:11 -0000 MIME-Version: 1.0 From: "Vivek Dubey" To: ospf@ietf.org Subject: Re: [OSPF] Question: Intra-area Prefix Lsa X-Spam-Score: 0.5 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vivek Dubey List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0559285279==" Errors-To: ospf-bounces@ietf.org This is a multipart mime message --===============0559285279== Content-type: multipart/alternative; boundary="Next_1150877531---0-203.199.83.248-18109" This is a multipart mime message --Next_1150877531---0-203.199.83.248-18109 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Acee,=0APls check tagged with =0A=0AOn Tue, 20 Jun 2006 Acee Lin= dem wrote :=0AHi Vivek,=0A=0AVivek Dubey wrote:=0A=0AHi,=0AQueries tagged b= y for (3) cases listed below.=0A=0A1) Case1: Transit Link=0A-------= ---------------=0ADraft quote=0A"Each IPv6 address prefix that has been con= figured on Link L is added to the link-LSA by specifying values for PrefixL= ength, PrefixOptions, and Address Prefix fields"=0A=0ASo prefix can be:=0Aa= ) Global Ipv6 address (LA bit) i.e global ipv6 address associated with th= e link (RFC 4293 ipAddressTable)=0Ab) Global Ipv6 Prefix i.e global ipv6 pr= efix associated with the link (RFC 4293 ipAddressPrefixTable)=0Ac) Furthe= r (a) can be part of (b) or independent (RFC 4293 ipAddressPrefix)=0A=0AF= urther while DR builds an intra-area-prefix lsa associated with the network= LSA=0A=0ADraft quote=0A"the list of prefixes in the link-LSA is copied int= o the intra-area-prefix-LSA that is being built. Prefixes having the NU-bi= t and/or LA-bit set in their Options field SHOULD NOT be copied, nor should= link-local addresses be copied"=0A=0A Since DR does not use prefix= es having NU/LA bit set while originating intra-area-prefix lsa, wh= y should they be made part of link lsa originated for the transit l= ink=0A =0AThe link-LSA has always included a complete set of prefixes for = the link. In the case where=0Athe multi-access network has only one connect= ed router, the prefixes will be advertised=0Ain the intra-area-prefix LSA a= ssociated with the router and will be more useful.=0A=0A How are we= deciding to set/clear LA bit? Is it Ospf level decision?=0A Or is = it based on whether global unicast ipv6 address associated with the link is= present in "ipAddressTable" =0A (RFC4293)=0A=0A=0A So the = question is when Ospf says "prefixes for the link" where they belong from a= s per Ipv6, =0A "ipAddressPrefixTable" OR "ipAddressTable".=0A=0A = If they belong to "ipAddressTable" (prefix length 128), should LA bi= t be set?=0A If they belong to "ipAddressPrefixTable" (prefix lengt= h 0...128), should LA bit be set?=0A=0A If above is right, advertis= ing prefixes lying in "ipAddressTable" (i.e LA bit set), in link-lsa=0A = of multiaccess link (non-stub link), is not useful. Than why to includ= e prefixes with LA bit set?=0A =0A =0ANote that for all link types= other than broadcast and NBMA, the prefixes in the link LSA=0Aare NOT used= and the link-LSA could, in fact, be limited to the link-local address. May= be,=0AI should document this as an option. I've been somewhat hesitant to p= rovide additional=0Acapabilities in the respin since the purpose is mainly = to correct and clarify what is currently=0Ain RFC 2740.=0A=0A Agree= d. Only P2MP link type is applicabale for link lsa(s) other than broadcast = and NBMA and link-lsa associated =0A with that can be limited to li= nk-local address.=0A=0AIMHO, we should have deprecated MOSPF which would ha= ve gotten rid of the NU and=0AMC bits. However, there was some opposition t= o this - perhaps, we will be able to do=0Ait in the future.=0A=0A I= f global ipv6 address associated with the link, is not part of glob= al ipv6 address prefix of the link, how would that be reachable in = the Ospf domain, as DR does not advertise such prefixes (LA bit set= ), in the intra-area-prefix LSA=0A =0AA router that has a virtual link is = responsible for advertising at least one address with=0Athe LA-bit set in t= he intra-area-prefix-LSA corresponding to the router. If it is necessary=0A= for this address to be the interface address of a multi-access link, it wou= ld be advertised=0Athere. For the other cases where the draft dictates that= the LA-bit is set, the DR isn't=0Aapplicable (loopback and Point-to-Multip= oint interfaces).=0A=0A=0A=0A2) Case2: P2P link=0A-------------------=0AThe= link prefixes can be:=0Aa) Global Ipv6 address (LA bit) i.e global ipv6 ad= dress associated=0A with the link (RFC 4293 ipAddressTable)=0Ab) Global I= pv6 Prefix i.e global ipv6 prefix associated with the link (RFC 4293 ipAdd= ressPrefixTable)=0Ac) The entry (a) part of prefix (b) above (RFC 4293 ipAd= dressPrefix)=0Ad) The entry (a) NOT part of prefix (b) above (RFC 4293 ip= AddressPrefix being NULL)=0A=0A Should intra-area prefix Lsa associ= ated with the router include separate entry for:=0A a) Global Ipv6= address (LA bit)=0A b) Global Ipv6 Prefix i.e global ipv6 prefix associat= ed with the link=0A=0A If (c) above is TRUE, should (a) = be included separately or just (b) would do?=0A =0AFor P2P links, = the global IPv6 address with the LA-bit set should only be advertised if=0A= it necessary to provide an endpoint for a virtual link. In this case, both = the global prefix=0Aand the local address (i.e., /128) should be advertised= .=0A=0A3) Case3: Stub Link=0A--------------------=0AThe link prefixes can b= e:=0Aa) Global Ipv6 address (LA bit) i.e global ipv6 address associated w= ith the link (RFC 4293 ipAddressTable)=0Ab) Global Ipv6 Prefix i.e global i= pv6 prefix associated with the link (RFC 4293 ipAddressPrefixTable)=0Ac) = The entry (a) part of prefix (b) above (RFC 4293 ipAddressPrefix)=0Ad) The = entry (a) NOT part of prefix (b) above (RFC 4293 ipAddressPrefix being NU= LL)=0A=0A Should intra-area prefix Lsa associated with the router = include separate entry for:=0A a) Global Ipv6 address (LA bit)=0A b)= Global Ipv6 Prefix i.e global ipv6 prefix associated with the l= ink=0A=0A In (c) above is TRUE, should (a) be included separately o= r just (b) would do?=0A =0ASame as P2P links.=0A=0AThanks,=0AAcee= =0A=0AThanks=0AVivek --Next_1150877531---0-203.199.83.248-18109 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi Acee,
=0APls check tagged with <repviv>
=0A
=0AOn T= ue, 20 Jun 2006 Acee Lindem wrote :
=0AHi Vivek,
=0A
=0AVivek Dube= y wrote:
=0A
=0AHi,
=0AQueries tagged by <vivek> for (3) cas= es listed below.
=0A
=0A1) Case1: Transit Link
=0A----------------= ------
=0ADraft quote
=0A"Each IPv6 address prefix that has been= configured on Link L is added to the link-LSA by specifying values for Pre= fixLength, PrefixOptions, and Address Prefix fields"
=0A
=0ASo p= refix can be:
=0Aa) Global Ipv6 address (LA bit) i.e global ipv6 address= associated with the link (RFC 4293 ipAddressTable)
=0Ab) Global = Ipv6 Prefix i.e global ipv6 prefix associated with the link (RFC 429= 3 ipAddressPrefixTable)
=0Ac) Further (a) can be part of (b) or independ= ent (RFC 4293 ipAddressPrefix)
=0A
=0AFurther while DR builds = an intra-area-prefix lsa associated with the network LSA
=0A
=0ADraft= quote
=0A"the list of prefixes in the link-LSA is copied into the = intra-area-prefix-LSA that is being built. Prefixes having the NU-bit= and/or LA-bit set in their Options field SHOULD NOT be copied, nor should = link-local addresses be copied"
=0A
=0A<vivek1> Since DR d= oes not use prefixes having NU/LA bit set while = originating intra-area-prefix lsa, why should they be made &n= bsp; part of link lsa originated for the transit link
=0A =
=0AThe link-LSA has always included a complete set of prefixes for the = link. In the case where
=0Athe multi-access network has only one connect= ed router, the prefixes will be advertised
=0Ain the intra-area-prefix L= SA associated with the router and will be more useful.
=0A
=0A<rep= viv> How are we deciding to set/clear LA bit? Is it Ospf level decision?=
=0A Or is it based on whether global unicas= t ipv6 address associated with the link is present in "ipAddressTable&= quot;
=0A (RFC4293)
=0A
=0A
=0A&nb= sp; So the question is when Ospf says "prefixes = for the link" where they belong from as per Ipv6,
=0A = "ipAddressPrefixTable" OR "ipAddressTable&qu= ot;.
=0A
=0A If they belong to "ipAd= dressTable" (prefix length 128), should LA bit be set?
=0A &n= bsp; If they belong to "ipAddressPrefixTable" (pre= fix length 0...128), should LA bit be set?
=0A
=0A = ; If above is right, advertising prefixes lying in "ipAddressT= able" (i.e LA bit set), in link-lsa
=0A = of multiaccess link (non-stub link), is not useful. Than why to include pr= efixes with LA bit set?
=0A
=0A =0ANote that for all link types other than broadcast and NBMA, the prefix= es in the link LSA
=0Aare NOT used and the link-LSA could, in fact, be l= imited to the link-local address. Maybe,
=0AI should document this as an= option. I've been somewhat hesitant to provide additional
=0Acapabiliti= es in the respin since the purpose is mainly to correct and clarify what is= currently
=0Ain RFC 2740.
=0A
=0A<repviv> Agreed. Only P2MP= link type is applicabale for link lsa(s) other than broadcast and NBMA and= link-lsa associated
=0A with that can be l= imited to link-local address.
=0A
=0AIMHO, we should have deprecated = MOSPF which would have gotten rid of the NU and
=0AMC bits. However, the= re was some opposition to this - perhaps, we will be able to do
=0Ait in= the future.
=0A
=0A<vivek2> If global ipv6 address associated = with the link, is not part of global ipv6 addre= ss prefix of the link, how would that be reacha= ble in the Ospf domain, as DR does not advertise such &= nbsp; prefixes (LA bit set), in the intra-area-prefix LSA
=0A =0AA router that has a virtual link is responsible for advertising at leas= t one address with
=0Athe LA-bit set in the intra-area-prefix-LSA corres= ponding to the router. If it is necessary
=0Afor this address to be the = interface address of a multi-access link, it would be advertised
=0Ather= e. For the other cases where the draft dictates that the LA-bit is set, the= DR isn't
=0Aapplicable (loopback and Point-to-Multipoint interfaces).=0A
=0A
=0A
=0A2) Case2: P2P link
=0A-------------------
= =0AThe link prefixes can be:
=0Aa) Global Ipv6 address (LA bit) i.e glob= al ipv6 address associated
=0A with the link (RFC 4293 ipAddressT= able)
=0Ab) Global Ipv6 Prefix i.e global ipv6 prefix associated with th= e link (RFC 4293 ipAddressPrefixTable)
=0Ac) The entry (a) part of= prefix (b) above (RFC 4293 ipAddressPrefix)
=0Ad) The entry (a) NOT par= t of prefix (b) above (RFC 4293 ipAddressPrefix being NULL)
=0A=0A<vivek3> Should intra-area prefix Lsa associated with the router= include separate entry for:
=0A a) Gl= obal Ipv6 address (LA bit)
=0A b) Global Ipv6 Prefix i.e global ip= v6 prefix associated with the link=
=0A
=0A<vivek4> If (c) above is TRUE, should (a) be included s= eparately or just (b) would do?
=0A =0AFor P2P links, the global IPv6 address with the LA-bit set should only= be advertised if
=0Ait necessary to provide an endpoint for a virtual l= ink. In this case, both the global prefix
=0Aand the local address (i.e.= , /128) should be advertised.
=0A
=0A3) Case3: Stub Link
=0A------= --------------
=0AThe link prefixes can be:
=0Aa) Global Ipv6 address= (LA bit) i.e global ipv6 address associated with the link (RFC 4293= ipAddressTable)
=0Ab) Global Ipv6 Prefix i.e global ipv6 prefix associa= ted with the link (RFC 4293 ipAddressPrefixTable)
=0Ac) The entry= (a) part of prefix (b) above (RFC 4293 ipAddressPrefix)
=0Ad) The entry= (a) NOT part of prefix (b) above (RFC 4293 ipAddressPrefix being NU= LL)
=0A
=0A<vivek5> Should intra-area prefix Lsa associated wit= h the router include separate entry for:
=0A= a) Global Ipv6 address (LA bit)
=0A b) Global Ipv6 Prefix i.e global ip= v6 prefix associated with the link=
=0A
=0A<vivek6> In (c) above is TRUE, should (a) be included s= eparately or just (b) would do?
=0A
=0AS= ame as P2P links.
=0A
=0AThanks,
=0AAcee
=0A
=0AThanks
= =0AVivek=0A

=0A

=0A

=0A --Next_1150877531---0-203.199.83.248-18109-- --===============0559285279== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0559285279==-- From MAILER-DAEMON Wed Jun 21 09:54:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3A8-000855-BD for ospf-archive@lists.ietf.org; Wed, 21 Jun 2006 09:54:32 -0400 Received: from imf21aec.mail.bellsouth.net ([205.152.59.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3A7-0006Ki-3m for ospf-archive@lists.ietf.org; Wed, 21 Jun 2006 09:54:32 -0400 To: ospf-archive@lists.ietf.org From: Mail Administrator > Reply-To: Subject: Mail System Error - Returned Mail Date: Wed, 21 Jun 2006 09:54:30 -0400 Message-ID: <20060621135430.NRZP518.imf21aec.mail.bellsouth.net@imf21aec> MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; Boundary="===========================_ _= 9890136(518)1150898070" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 --===========================_ _= 9890136(518)1150898070 Content-Type: text/plain .net 007: This e-mail message was undeliverable due to the following reason: .net 018: Each of the following recipients were rejected by a destination mail system. Note: The reasons given by the destination mail system are included to help you determine why each recipient was rejected. Solution: Attempt to resend, or contact the recipient by alternate means to let them know about the issue. Recipient: Reason: sorry, sorry, that domain isn't allowed to relay (#5.7.1) --===========================_ _= 9890136(518)1150898070 Content-Type: message/delivery-status Reporting-MTA: dns; imf21aec.mail.bellsouth.net Arrival-Date: Wed, 21 Jun 2006 09:54:24 -0400 Received-From-MTA: dns; ibm75aec-ce5 (192.168.51.85) Final-Recipient: RFC822; Action: failed Status: 5.1.3 Remote-MTA: dns; mail.zzz.org (220.95.230.22) Diagnostic-Code: smtp; 553 sorry, sorry, that domain isn't allowed to relay (#5.7.1) --===========================_ _= 9890136(518)1150898070 Content-Type: message/rfc822 Received: from ibm75aec-ce5 ([192.168.51.85]) by imf21aec.mail.bellsouth.net with ESMTP id <20060621135424.NRUS518.imf21aec.mail.bellsouth.net@ibm75aec-ce5> for ; Wed, 21 Jun 2006 09:54:24 -0400 Received: from ibm66aec.bellsouth.net ([67.35.253.151]) by imf23aec.mail.bellsouth.net with ESMTP id <20060621134725.GWOQ29501.imf23aec.mail.bellsouth.net@ibm66aec.bellsouth.net> for ; Wed, 21 Jun 2006 09:47:25 -0400 Received: from lists.ietf.org ([67.35.253.151]) by ibm66aec.bellsouth.net with ESMTP id <20060621134717.GRLT19715.ibm66aec.bellsouth.net@lists.ietf.org> for ; Wed, 21 Jun 2006 09:47:17 -0400 From: ospf-archive@lists.ietf.org To: ppp@zzz.org Subject: Mail System Error - Returned Mail Date: Wed, 21 Jun 2006 08:45:24 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20060621134717.GRLT19715.ibm66aec.bellsouth.net@lists.ietf.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VYZabccdefghijklmmnopqrstuuvwxyz01223456" X-BLTSYMAVREINSERT: aoynT86ZrURNHKZzniXP2LG+EicA This is a multi-part message in MIME format. --VYZabccdefghijklmmnopqrstuuvwxyz01223456 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This message has been processed by Symantec AntiVirus. FILE.SCR was infected with the malicious virus W32.Mydoom!gen and has been deleted because the file cannot be cleaned. --VYZabccdefghijklmmnopqrstuuvwxyz01223456 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ibm66aec.bellsouth.net ([67.35.253.151]) by imf23aec.mail.bellsouth.net with ESMTP id <20060621134725.GWOQ29501.imf23aec.mail.bellsouth.net@ibm66aec.bellsouth.net> for ; Wed, 21 Jun 2006 09:47:25 -0400 Received: from lists.ietf.org ([67.35.253.151]) by ibm66aec.bellsouth.net with ESMTP id <20060621134717.GRLT19715.ibm66aec.bellsouth.net@lists.ietf.org> for ; Wed, 21 Jun 2006 09:47:17 -0400 From: ospf-archive@lists.ietf.org To: ppp@zzz.org Subject: Mail System Error - Returned Mail Date: Wed, 21 Jun 2006 08:45:24 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_D1994582.C1FC82D9" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20060621134717.GRLT19715.ibm66aec.bellsouth.net@lists.ietf.org> This is a multi-part message in MIME format. ------=_NextPart_000_0006_D1994582.C1FC82D9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message could not be delivered ------=_NextPart_000_0006_D1994582.C1FC82D9-- --VYZabccdefghijklmmnopqrstuuvwxyz01223456-- --===========================_ _= 9890136(518)1150898070-- From ospf-bounces@ietf.org Wed Jun 21 13:45:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6lT-0003Z1-2n; Wed, 21 Jun 2006 13:45:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6lR-0003Yw-Sv for ospf@ietf.org; Wed, 21 Jun 2006 13:45:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6lQ-0006mr-9k for ospf@ietf.org; Wed, 21 Jun 2006 13:45:17 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2006 10:45:15 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,163,1149490800"; d="scan'208"; a="30155928:sNHT24736184" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5LHjFno017768; Wed, 21 Jun 2006 13:45:15 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 13:45:15 -0400 Received: from [10.82.216.166] ([10.82.216.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 13:45:14 -0400 Message-ID: <449985AA.1080402@cisco.com> Date: Wed, 21 Jun 2006 13:45:14 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vivek Dubey Subject: Re: [OSPF] Question: Intra-area Prefix Lsa References: <20060621081211.18145.qmail@webmail36.rediffmail.com> In-Reply-To: <20060621081211.18145.qmail@webmail36.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 17:45:15.0010 (UTC) FILETIME=[73DD0E20:01C6955A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Vivek, Vivek Dubey wrote: >Hi Acee, >Pls check tagged with > > It would be easier if you used a mail client which quoted your responses so I didn't have to hunt for the latest :^) >On Tue, 20 Jun 2006 Acee Lindem wrote : >Hi Vivek, > >Vivek Dubey wrote: > >Hi, >Queries tagged by for (3) cases listed below. > >1) Case1: Transit Link >---------------------- >Draft quote >"Each IPv6 address prefix that has been configured on Link L is added to the link-LSA by specifying values for PrefixLength, PrefixOptions, and Address Prefix fields" > >So prefix can be: >a) Global Ipv6 address (LA bit) i.e global ipv6 address associated with the link (RFC 4293 ipAddressTable) >b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the link (RFC 4293 ipAddressPrefixTable) >c) Further (a) can be part of (b) or independent (RFC 4293 ipAddressPrefix) > >Further while DR builds an intra-area-prefix lsa associated with the network LSA > >Draft quote >"the list of prefixes in the link-LSA is copied into the intra-area-prefix-LSA that is being built. Prefixes having the NU-bit and/or LA-bit set in their Options field SHOULD NOT be copied, nor should link-local addresses be copied" > > Since DR does not use prefixes having NU/LA bit set while originating intra-area-prefix lsa, why should they be made part of link lsa originated for the transit link > >The link-LSA has always included a complete set of prefixes for the link. In the case where >the multi-access network has only one connected router, the prefixes will be advertised >in the intra-area-prefix LSA associated with the router and will be more useful. > > How are we deciding to set/clear LA bit? Is it Ospf level decision? > Or is it based on whether global unicast ipv6 address associated with the link is present in "ipAddressTable" > (RFC4293) > > The OSPFv3 specification is the only place where reference is made to the LA bit. So, I'd say that setting/clearing this bit is solely within the purview of OSPFv3. > So the question is when Ospf says "prefixes for the link" where they belong from as per Ipv6, > "ipAddressPrefixTable" OR "ipAddressTable". > > If they belong to "ipAddressTable" (prefix length 128), should LA bit be set? > If they belong to "ipAddressPrefixTable" (prefix length 0...128), should LA bit be set? > > If above is right, advertising prefixes lying in "ipAddressTable" (i.e LA bit set), in link-lsa > of multiaccess link (non-stub link), is not useful. Than why to include prefixes with LA bit set? > > >Note that for all link types other than broadcast and NBMA, the prefixes in the link LSA >are NOT used and the link-LSA could, in fact, be limited to the link-local address. Maybe, >I should document this as an option. I've been somewhat hesitant to provide additional >capabilities in the respin since the purpose is mainly to correct and clarify what is currently >in RFC 2740. > > Agreed. Only P2MP link type is applicabale for link lsa(s) other than broadcast and NBMA and link-lsa associated > with that can be limited to link-local address. > > I didn't say that - I said that advertising prefixes other than the link-local address isn't really required for link types other than multiaccess links (wheher a DR is elected). While it might be more efficient to suppress advertisement of the link-LSA altogether, it wouldn't really be backward compatible to do this (at least not without a knob), since RFC 2740, section 3.8.1.1 uses the link-LSA to obtain the next-hop for all link types. I'll update the text to say advertising other global prefixes is optionally. This was discussed once before with Manoj Gopal. Hope this helps, Acee >IMHO, we should have deprecated MOSPF which would have gotten rid of the NU and >MC bits. However, there was some opposition to this - perhaps, we will be able to do >it in the future. > > If global ipv6 address associated with the link, is not part of global ipv6 address prefix of the link, how would that be reachable in the Ospf domain, as DR does not advertise such prefixes (LA bit set), in the intra-area-prefix LSA > >A router that has a virtual link is responsible for advertising at least one address with >the LA-bit set in the intra-area-prefix-LSA corresponding to the router. If it is necessary >for this address to be the interface address of a multi-access link, it would be advertised >there. For the other cases where the draft dictates that the LA-bit is set, the DR isn't >applicable (loopback and Point-to-Multipoint interfaces). > > > >2) Case2: P2P link >------------------- >The link prefixes can be: >a) Global Ipv6 address (LA bit) i.e global ipv6 address associated > with the link (RFC 4293 ipAddressTable) >b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the link (RFC 4293 ipAddressPrefixTable) >c) The entry (a) part of prefix (b) above (RFC 4293 ipAddressPrefix) >d) The entry (a) NOT part of prefix (b) above (RFC 4293 ipAddressPrefix being NULL) > > Should intra-area prefix Lsa associated with the router include separate entry for: > a) Global Ipv6 address (LA bit) > b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the link > > If (c) above is TRUE, should (a) be included separately or just (b) would do? > >For P2P links, the global IPv6 address with the LA-bit set should only be advertised if >it necessary to provide an endpoint for a virtual link. In this case, both the global prefix >and the local address (i.e., /128) should be advertised. > >3) Case3: Stub Link >-------------------- >The link prefixes can be: >a) Global Ipv6 address (LA bit) i.e global ipv6 address associated with the link (RFC 4293 ipAddressTable) >b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the link (RFC 4293 ipAddressPrefixTable) >c) The entry (a) part of prefix (b) above (RFC 4293 ipAddressPrefix) >d) The entry (a) NOT part of prefix (b) above (RFC 4293 ipAddressPrefix being NULL) > > Should intra-area prefix Lsa associated with the router include separate entry for: > a) Global Ipv6 address (LA bit) > b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the link > > In (c) above is TRUE, should (a) be included separately or just (b) would do? > >Same as P2P links. > >Thanks, >Acee > >Thanks >Vivek > > >------------------------------------------------------------------------ > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jun 21 16:48:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9cs-00060Y-NS; Wed, 21 Jun 2006 16:48:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9cr-00060N-Jc for ospf@ietf.org; Wed, 21 Jun 2006 16:48:37 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft9cp-0003gd-UI for ospf@ietf.org; Wed, 21 Jun 2006 16:48:37 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2006 13:48:34 -0700 X-IronPort-AV: i="4.06,163,1149490800"; d="scan'208"; a="298766777:sNHT38726294" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5LKmYo5009278 for ; Wed, 21 Jun 2006 13:48:34 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5LKmWIw000142 for ; Wed, 21 Jun 2006 13:48:34 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 16:48:33 -0400 Received: from [10.82.216.166] ([10.82.216.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 16:48:32 -0400 Message-ID: <4499B0A0.1090000@cisco.com> Date: Wed, 21 Jun 2006 16:48:32 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ospf@ietf.org Subject: Re: [OSPF] Question: Intra-area Prefix Lsa References: <20060621081211.18145.qmail@webmail36.rediffmail.com> <449985AA.1080402@cisco.com> In-Reply-To: <449985AA.1080402@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 20:48:32.0938 (UTC) FILETIME=[0F23B0A0:01C69574] DKIM-Signature: a=rsa-sha1; q=dns; l=8534; t=1150922914; x=1151786914; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20Question=3A=20Intra-area=20Prefix=20Lsa; X=v=3Dcisco.com=3B=20h=3DTyh88E8vdTYHQWoKGcZ5ZCvC4AU=3D; b=333eaaF81z3aqbd7AO/JEYIFcehi2dy+HFwo+l1UQi/1zjGPU0k/+5wSfazxenGPb1QMOSDa HmqJSSrHxQSqk115kXhNPbMdeCG0O66MB9BjI3SCkHJGrZKgNpLFujO0; Authentication-Results: sj-dkim-5.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Rather than change the RFC 2740 Link-LSA content, I have introduced a new interface configation parameter. LinkLSASuppression Indicates whether or not origination of a Link-LSA is suppressed. If set to "enabled" and the interface type is not broadcast or NBMA, the router will not originate a Link-LSA for the link. This implies that other routers on the link will ascertain the router's next-hop address using a mechanism other than the Link-LSA (see Section 3.8.2). The default value is "disabled" for interface types described in this specification. It is implicitly "disabled" if the interface type is broadcast or NBMA. Future interface types MAY specify a different default. This will satisfy Vivek's and Manoj's concern regarding the unneeded overhead of Link-LSA while affording full backward compatibility. For better or worse, this will be in the 10 version of the specification. Thanks, Acee Acee Lindem wrote: > Hi Vivek, > > Vivek Dubey wrote: > >> Hi Acee, >> Pls check tagged with >> >> > It would be easier if you used a mail client which quoted your > responses so I didn't have to hunt for the latest :^) > >> On Tue, 20 Jun 2006 Acee Lindem wrote : >> Hi Vivek, >> >> Vivek Dubey wrote: >> >> Hi, >> Queries tagged by for (3) cases listed below. >> >> 1) Case1: Transit Link >> ---------------------- >> Draft quote >> "Each IPv6 address prefix that has been configured on Link L is added >> to the link-LSA by specifying values for PrefixLength, PrefixOptions, >> and Address Prefix fields" >> >> So prefix can be: >> a) Global Ipv6 address (LA bit) i.e global ipv6 address associated >> with the link (RFC 4293 ipAddressTable) >> b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the >> link (RFC 4293 ipAddressPrefixTable) >> c) Further (a) can be part of (b) or independent (RFC 4293 >> ipAddressPrefix) >> >> Further while DR builds an intra-area-prefix lsa associated with the >> network LSA >> >> Draft quote >> "the list of prefixes in the link-LSA is copied into the >> intra-area-prefix-LSA that is being built. Prefixes having the >> NU-bit and/or LA-bit set in their Options field SHOULD NOT be copied, >> nor should link-local addresses be copied" >> >> Since DR does not use prefixes having NU/LA bit set >> while originating intra-area-prefix lsa, why should they be >> made part of link lsa originated for the transit link >> >> The link-LSA has always included a complete set of prefixes for the >> link. In the case where >> the multi-access network has only one connected router, the prefixes >> will be advertised >> in the intra-area-prefix LSA associated with the router and will be >> more useful. >> >> How are we deciding to set/clear LA bit? Is it Ospf level >> decision? >> Or is it based on whether global unicast ipv6 address >> associated with the link is present in "ipAddressTable" >> (RFC4293) >> >> > The OSPFv3 specification is the only place where reference is made to the > LA bit. So, I'd say that setting/clearing this bit is solely within the > purview of OSPFv3. > >> So the question is when Ospf says "prefixes for the link" >> where they belong from as per Ipv6, "ipAddressPrefixTable" OR >> "ipAddressTable". >> >> If they belong to "ipAddressTable" (prefix length 128), >> should LA bit be set? >> If they belong to "ipAddressPrefixTable" (prefix length >> 0...128), should LA bit be set? >> >> If above is right, advertising prefixes lying in >> "ipAddressTable" (i.e LA bit set), in link-lsa >> of multiaccess link (non-stub link), is not useful. Than why >> to include prefixes with LA bit set? >> >> Note that for all link types other than broadcast and NBMA, the >> prefixes in the link LSA >> are NOT used and the link-LSA could, in fact, be limited to the >> link-local address. Maybe, >> I should document this as an option. I've been somewhat hesitant to >> provide additional >> capabilities in the respin since the purpose is mainly to correct and >> clarify what is currently >> in RFC 2740. >> >> Agreed. Only P2MP link type is applicabale for link lsa(s) >> other than broadcast and NBMA and link-lsa associated with >> that can be limited to link-local address. >> >> > I didn't say that - I said that advertising prefixes other than the > link-local address > isn't really required for link types other than multiaccess links > (wheher a DR is > elected). While it might be more efficient to suppress advertisement > of the > link-LSA altogether, it wouldn't really be backward compatible to do this > (at least not without a knob), since RFC 2740, section 3.8.1.1 uses > the link-LSA > to obtain the next-hop for all link types. I'll update the text to say > advertising > other global prefixes is optionally. This was discussed once before with > Manoj Gopal. > > Hope this helps, > Acee > >> IMHO, we should have deprecated MOSPF which would have gotten rid of >> the NU and >> MC bits. However, there was some opposition to this - perhaps, we >> will be able to do >> it in the future. >> >> If global ipv6 address associated with the link, is not >> part of global ipv6 address prefix of the link, how would >> that be reachable in the Ospf domain, as DR does not >> advertise such prefixes (LA bit set), in the >> intra-area-prefix LSA >> >> A router that has a virtual link is responsible for advertising at >> least one address with >> the LA-bit set in the intra-area-prefix-LSA corresponding to the >> router. If it is necessary >> for this address to be the interface address of a multi-access link, >> it would be advertised >> there. For the other cases where the draft dictates that the LA-bit >> is set, the DR isn't >> applicable (loopback and Point-to-Multipoint interfaces). >> >> >> >> 2) Case2: P2P link >> ------------------- >> The link prefixes can be: >> a) Global Ipv6 address (LA bit) i.e global ipv6 address associated >> with the link (RFC 4293 ipAddressTable) >> b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the >> link (RFC 4293 ipAddressPrefixTable) >> c) The entry (a) part of prefix (b) above (RFC 4293 ipAddressPrefix) >> d) The entry (a) NOT part of prefix (b) above (RFC 4293 >> ipAddressPrefix being NULL) >> >> Should intra-area prefix Lsa associated with the >> router include separate entry for: >> a) Global Ipv6 address (LA bit) >> b) Global Ipv6 Prefix i.e global ipv6 prefix associated >> with the link >> >> If (c) above is TRUE, should (a) be included separately >> or just (b) would do? >> >> For P2P links, the global IPv6 address with the LA-bit set should >> only be advertised if >> it necessary to provide an endpoint for a virtual link. In this case, >> both the global prefix >> and the local address (i.e., /128) should be advertised. >> >> 3) Case3: Stub Link >> -------------------- >> The link prefixes can be: >> a) Global Ipv6 address (LA bit) i.e global ipv6 address associated >> with the link (RFC 4293 ipAddressTable) >> b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the >> link (RFC 4293 ipAddressPrefixTable) >> c) The entry (a) part of prefix (b) above (RFC 4293 ipAddressPrefix) >> d) The entry (a) NOT part of prefix (b) above (RFC 4293 >> ipAddressPrefix being NULL) >> >> Should intra-area prefix Lsa associated with the >> router include separate entry for: >> a) Global Ipv6 address (LA bit) >> b) Global Ipv6 Prefix i.e global ipv6 prefix associated >> with the link >> >> In (c) above is TRUE, should (a) be included separately >> or just (b) would do? >> >> Same as P2P links. >> >> Thanks, >> Acee >> >> Thanks >> Vivek >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf >> >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jun 21 18:20:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtB3z-00060K-NL; Wed, 21 Jun 2006 18:20:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtB3y-0005zB-Ij for ospf@ietf.org; Wed, 21 Jun 2006 18:20:42 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtB3x-00044E-54 for ospf@ietf.org; Wed, 21 Jun 2006 18:20:42 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 21 Jun 2006 15:20:40 -0700 X-IronPort-AV: i="4.06,163,1149490800"; d="scan'208"; a="1830201866:sNHT572682214" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5LMKcEC006471; Wed, 21 Jun 2006 15:20:38 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5LMKbIs002089; Wed, 21 Jun 2006 15:20:38 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 18:20:37 -0400 Received: from [10.82.216.166] ([10.82.216.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 18:20:37 -0400 Message-ID: <4499C634.5070107@cisco.com> Date: Wed, 21 Jun 2006 18:20:36 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OSPF List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 22:20:37.0346 (UTC) FILETIME=[EBF17420:01C69580] DKIM-Signature: a=rsa-sha1; q=dns; l=4187; t=1150928438; x=1151792438; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:OSPF=20WG=20Charter=20Update=20Straw=20Man; X=v=3Dcisco.com=3B=20h=3DZ4lFyNf74vvg6l0ShqVN4/QU0rM=3D; b=Cs8m8qwfcDfRw94oVBjFTQBY+ayJv5ZnLkrMKtevA0T5Z+mppElbu8nuE62bzafREjbg3uR9 puXX3OBxfmOn26nX6U4mo0JEQOfoApA4qLMokwHux2MAw76P4Ob6fMyK; Authentication-Results: sj-dkim-5.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Ross Callon Subject: [OSPF] OSPF WG Charter Update Straw Man X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Here is a straw man for the WG charter update. Most of what we've included are things we've already been working on. This wouldn't preclude work on smaller items which aren't specifically enumerated in the charter milestones. Charter Update Description of Working Group: The OSPF Working develops and documents extensions and bug fixes to the OSPF protocols as well as documenting OSPF usage scenarios. The specific protocol work items area listed in the Goals and Milestones section below. Additional major work items will require rechartering. Goals and Milestones: Done Gather operational experience with the OSPF protocol and submit the document as an Informational RFC. Done Develop multiple implementations, and test against each other. Done Design the routing protocol, and write its specification. Done Obtain performance data for the protocol. Done Make changes to the specification (if necessary) and publish the protocol as a Draft Standard RFC. Done Submit OSPF for IPv6 to IESG for consideration as a Standard. Done Update the OSPF NSSA option specified in RFC 1587 and submit to IESG for consideration as a Proposed Standard Done Develop Traffic Engineering extensions for OSPFv2 and submit it to the IESG as a Proposed Standard Done Submit to IESG a document which updates RFC 1793 allowing detection of demand circuit neighbors whose OSPF process has exited. Done Submit to IESG a BCP advocating that OSPF LSA refreshes be spread out over time Done Develop a hitless restart mechanism for OSPF and submit it to the IESG as a Proposed Standard. Done Document Alternative ABR implementations and submit ti IESG as an Informational RFC Done Extend the hitless restart mechanism to OSPFv3 and submit it to the IESG as a Proposed Standard Done Develop Traffic Engineering extensions for OSPFv3 and submit it to the IESG as a Proposed Standard. Done Submit to IESG a BCP advocating that OSPF Hellos be given preference over other OSPF control traffic. Done Update OSPFv2 MIB and submit to IESG as a Standard, replacing RFC 1850 Done Specify IPSEC usage with OSPFv3 and submit to IESG for consideration as a Proposed Standard July 2007 Develop OSPF for IPv6 MIB and submit to IESG for consideration as a Proposed Standard. Mar 2007 Develop an IPSec based authentication for OSPFv2 and submit to IESG for consideration as a Proposed Standard. Done Develop OSPFv2 Multiple Topology Routing (MTR) specification and submit to IESG for consideration as a Proposed Standard. Done Develop OSPF Capabilities Advertisement specification and submit to IESG for consideration as a Proposed Standard. Mar 2007 Develop a multiple instance OSPFv3 Multiple Topology Routing (MTR) specification and submit to IESG for consideration as a Proposed Standard. Mar 2007 Advance Link Local Signalling (LLS) from experimental status and submit to IESG for consideration as a Proposed Standard. July 2007 Develop a OSPFv2 Multiple Topology Routing (MTR) MIB specification and submit to IESG for consideration as a Proposed Standard. July 2007 Develop OSPFv3 protocol enhancements to reduce flooding overhead and adjacencies in a MANET environment for consideration as a Proposed Standard. Nov 2007 Develop OSPFv2 protocol enhancement for optionally associating additional attributes with routes/link and submit to IESG for consideration as a Proposed Standard. Mar 2008 Develop a single instance OSPFv3 Multiple Topology Routing (MTR) specification and submit to IESG for consideration as a Proposed Standard. Thanks, Acee and Rohit _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From postmaster@lists.ietf.org Thu Jun 22 05:30:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtLVn-00036r-Qb for ospf-archive@lists.ietf.org; Thu, 22 Jun 2006 05:30:07 -0400 Received: from imf19aec.mail.bellsouth.net ([205.152.59.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtLVm-0007ZZ-Ig for ospf-archive@lists.ietf.org; Thu, 22 Jun 2006 05:30:07 -0400 Received: from ibm65aec-qfe4 ([192.168.51.75]) by imf19aec.mail.bellsouth.net with ESMTP id <20060622093006.QDHZ5315.imf19aec.mail.bellsouth.net@ibm65aec-qfe4> for ; Thu, 22 Jun 2006 05:30:06 -0400 Received: from ibm65aec.bellsouth.net ([68.222.5.51]) by imf22aec.mail.bellsouth.net with ESMTP id <20060622092644.ZFTJ21800.imf22aec.mail.bellsouth.net@ibm65aec.bellsouth.net> for ; Thu, 22 Jun 2006 05:26:44 -0400 Received: from lists.ietf.org ([68.222.5.51]) by ibm65aec.bellsouth.net with ESMTP id <20060622092625.SDMX3156.ibm65aec.bellsouth.net@lists.ietf.org> for ; Thu, 22 Jun 2006 05:26:25 -0400 From: "Bounced mail" To: ospf-archive@lists.ietf.org Subject: RETURNED MAIL: SEE TRANSCRIPT FOR DETAILS Date: Thu, 22 Jun 2006 04:25:23 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20060622092625.SDMX3156.ibm65aec.bellsouth.net@lists.ietf.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VXYabcdeghijklnopqrsuvwxyz12345689ABCDEG" X-BLTSYMAVREINSERT: SR6/Y8CaxERV8IuB+mF4kpZyTFUA X-Spam-Score: 3.5 (+++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This is a multi-part message in MIME format. --VXYabcdeghijklnopqrsuvwxyz12345689ABCDEG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This message has been processed by Symantec AntiVirus. text.com was infected with the malicious virus W32.Mydoom!gen and has been deleted because the file cannot be cleaned. --VXYabcdeghijklnopqrsuvwxyz12345689ABCDEG Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ibm65aec.bellsouth.net ([68.222.5.51]) by imf22aec.mail.bellsouth.net with ESMTP id <20060622092644.ZFTJ21800.imf22aec.mail.bellsouth.net@ibm65aec.bellsouth.net> for ; Thu, 22 Jun 2006 05:26:44 -0400 Received: from lists.ietf.org ([68.222.5.51]) by ibm65aec.bellsouth.net with ESMTP id <20060622092625.SDMX3156.ibm65aec.bellsouth.net@lists.ietf.org> for ; Thu, 22 Jun 2006 05:26:25 -0400 From: "Bounced mail" To: ospf-archive@lists.ietf.org Subject: RETURNED MAIL: SEE TRANSCRIPT FOR DETAILS Date: Thu, 22 Jun 2006 04:25:23 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_A9B7B47B.E0DC90B6" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20060622092625.SDMX3156.ibm65aec.bellsouth.net@lists.ietf.org> This is a multi-part message in MIME format. ------=_NextPart_000_0002_A9B7B47B.E0DC90B6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The message was undeliverable due to the following reason(s): Your message could not be delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 7 days: Host 138.17.53.129 is not responding. The following recipients could not receive this message: Please reply to postmaster@lists.ietf.org if you feel this message to be in error. ------=_NextPart_000_0002_A9B7B47B.E0DC90B6 Content-Type: application/octet-stream; name="text.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="text.zip" UEsFBgAAAAAAAAAAAAAAAAAAAAAAAA== ------=_NextPart_000_0002_A9B7B47B.E0DC90B6-- --VXYabcdeghijklnopqrsuvwxyz12345689ABCDEG-- From ospf-bounces@ietf.org Thu Jun 22 06:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtMmr-0005er-FR; Thu, 22 Jun 2006 06:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtMmq-0005em-P8 for ospf@ietf.org; Thu, 22 Jun 2006 06:51:48 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtMmp-00037b-Ek for ospf@ietf.org; Thu, 22 Jun 2006 06:51:48 -0400 Received: from pc6 (1Cust206.tnt109.lnd4.gbr.da.uu.net [62.188.172.206]) by astro.systems.pipex.net (Postfix) with SMTP id 7B037E0003C1; Thu, 22 Jun 2006 11:51:44 +0100 (BST) Message-ID: <064801c695e0$ec78f200$0601a8c0@pc6> From: "Tom Petch" To: "Acee Lindem" , "Vivek Dubey" References: <20060621081211.18145.qmail@webmail36.rediffmail.com> <449985AA.1080402@cisco.com> Subject: Re: [OSPF] Hunt for the latest was Question: Intra-area Prefix Lsa Date: Thu, 22 Jun 2006 10:26:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org ----- Original Message ----- From: "Acee Lindem" To: "Vivek Dubey" Cc: Sent: Wednesday, June 21, 2006 7:45 PM Subject: Re: [OSPF] Question: Intra-area Prefix Lsa > Hi Vivek, > > Vivek Dubey wrote: > > >Hi Acee, > >Pls check tagged with > > > > > It would be easier if you used a mail client which quoted your > responses so I didn't have to hunt for the latest :^) > Nothing whatsoever to do with OSPF but I do agree; I waste ages trying to work out who is saying what in some exchanges. I find that for my e-mail client, the ubiquitous Windows, the key is the Content-Transfer-Encoding: which, when set to 'quoted-printable', suppresses the markers. I totally fail to see the logic in this, I cannot find any way to alter this behaviour, but when I really care, I edit the incoming e-mail to have a different Content-Transfer-Encoding - it is usually doing no more than including redundant carriage returns - before replying. (But then I am a perfectionist:-) Tom Petch /listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Jun 22 08:14:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtO4P-0003Dz-Fq; Thu, 22 Jun 2006 08:14:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtO4N-0003CQ-VT for ospf@ietf.org; Thu, 22 Jun 2006 08:13:59 -0400 Received: from [203.199.83.146] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtO4M-0007dg-5Z for ospf@ietf.org; Thu, 22 Jun 2006 08:13:59 -0400 Received: (qmail 21194 invoked by uid 510); 22 Jun 2006 11:59:34 -0000 Date: 22 Jun 2006 11:59:34 -0000 Message-ID: <20060622115934.21192.qmail@webmail24.rediffmail.com> Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 22 jun 2006 11:59:34 -0000 MIME-Version: 1.0 From: "Vivek Dubey" To: "Acee Lindem" X-Spam-Score: 0.9 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ospf@ietf.org Subject: [OSPF] Re:Question: Intra-area Prefix Lsa X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vivek Dubey List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: