From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May  2 11:51:07 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27587
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 2 May 2005 11:51:07 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0102FECC@cherry.ease.lsoft.com>; Mon, 2 May 2005 11:51:06 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          68984696 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 May 2005 11:51:03 -0400
Received: from 147.234.1.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Mon, 2 May 2005 11:50:22 -0400
X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999
X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.1|January
             21, 2004) at 05/02/2005 18:55:32
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Message-ID:  <OFED302955.9DC6DCBF-ONC2256FF5.00557268@ecitele.com>
Date:         Mon, 2 May 2005 18:50:40 +0300
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Ilan Bercovich <Ilan.Bercovich@ECITELE.COM>
Subject: DR election
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hello
If all routers accept the DR regardless of their Router Priority,
It means that actually the first active router on the LAN is the DR.
Isn't this makes the Router Priority parameter somewhat irrelevant?
(In RSTP for instance, when priority is changed - network is
re-calculated).
Ilan


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May  2 12:26:16 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01252
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 2 May 2005 12:26:16 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0102FDA2@cherry.ease.lsoft.com>; Mon, 2 May 2005 12:26:17 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          68988170 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 May 2005 12:26:14 -0400
Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Mon, 2 May 2005 12:15:38 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com
          (8.12.10+Sun/8.12.10) with ESMTP id j42GFcVg003995 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 2 May 2005 12:15:38 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
          (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA14975
          for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 2 May 2005 12:15:38 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2657.72) id <J70JTVT1>; Mon, 2 May 2005 12:15:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <313680C9A886D511A06000204840E1CF06DAD22A@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 2 May 2005 12:15:35 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Krishnan, Vijay G." <Vijay.G.Krishnan@MARCONI.COM>
Subject: Re: DR election
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

The first router does not become the DR immediately. It waits for its
configurable "wait timer" to expire, before electing the DR. Others routers
could come up during this time. Once the DR is elected, addition of new
routers would not change the DR. This will reduce the instability due to the
DR changes.

regards
Vijay



-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Ilan
Bercovich
Sent: Monday, May 02, 2005 11:51 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: DR election


Hello
If all routers accept the DR regardless of their Router Priority,
It means that actually the first active router on the LAN is the DR.
Isn't this makes the Router Priority parameter somewhat irrelevant?
(In RSTP for instance, when priority is changed - network is
re-calculated).
Ilan


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May  2 12:42:11 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02514
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 2 May 2005 12:42:11 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0102FF8B@cherry.ease.lsoft.com>; Mon, 2 May 2005 12:42:12 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          68990814 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 May 2005 12:42:09 -0400
Received: from 207.217.121.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Mon, 2 May 2005 12:41:31 -0400
Received: from h-68-164-88-190.snvacaid.dynamic.covad.net ([68.164.88.190]
          helo=earthlink.net) by pop-a065d19.pas.sa.earthlink.net with esmtp
          (Exim 3.36 #10) id 1DSdz9-000430-00 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 02 May 2005 09:41:31 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <313680C9A886D511A06000204840E1CF06DAD22A@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <42765745.9502E874@earthlink.net>
Date:         Mon, 2 May 2005 09:37:25 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: DR election
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Yes and no,

If a router "really wants to be the DR", the protocol does
allow this through a back door. The router must act like
it was already also elected as the DR. This can happen in
what was a split area. By coming up later, the later router
SHOULD know the other's priority and router-id. It can then
boost its broadcasted priority and/or its router-id to gurantee
re-election.

Mitchell Erblich
----------------------


"Krishnan, Vijay G." wrote:
> 
> The first router does not become the DR immediately. It waits for its
> configurable "wait timer" to expire, before electing the DR. Others routers
> could come up during this time. Once the DR is elected, addition of new
> routers would not change the DR. This will reduce the instability due to the
> DR changes.
> 
> regards
> Vijay
> 
> -----Original Message-----
> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Ilan
> Bercovich
> Sent: Monday, May 02, 2005 11:51 AM
> To: OSPF@PEACH.EASE.LSOFT.COM
> Subject: DR election
> 
> Hello
> If all routers accept the DR regardless of their Router Priority,
> It means that actually the first active router on the LAN is the DR.
> Isn't this makes the Router Priority parameter somewhat irrelevant?
> (In RSTP for instance, when priority is changed - network is
> re-calculated).
> Ilan


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May  2 20:59:58 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07789
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 2 May 2005 20:59:58 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0103097E@cherry.ease.lsoft.com>; Mon, 2 May 2005 20:59:57 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69027168 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 May 2005 20:59:56 -0400
Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Mon, 2 May 2005 20:59:54 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com
          with ESMTP; 02 May 2005 21:13:11 -0400
X-IronPort-AV: i="3.92,147,1112587200"; d="scan'208"; a="47044502:sNHT29518988"
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 j430xlRU021087 for <ospf@peach.ease.lsoft.com>; Mon, 2 May 2005
          20:59:52 -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); Mon,
          2 May 2005 20:59:47 -0400
Received: from [10.82.241.73] ([10.82.241.73]) by xfe-rtp-202.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 20:59:47 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 May 2005 00:59:47.0606 (UTC)
                       FILETIME=[66E93B60:01C54F7B]
Message-ID:  <4276CD03.5080401@cisco.com>
Date:         Mon, 2 May 2005 20:59:47 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Documents Close to WG Last Call
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Rohit and I feel the following documents are ready (or very close to
ready) for WG last call.

   Traffic Engineering Extensions to OSPF version 3 -
             draft-ietf-ospf-ospfv3-traffic-04.txt

   IANA Considerations for OSPF - draft-ietf-ospf-iana-00.txt

Any open issues or other opinions on the readiness?

Thanks,
Acee

 


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May  3 07:51:04 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07434
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 3 May 2005 07:51:04 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.01031413@cherry.ease.lsoft.com>; Tue, 3 May 2005 7:51:00 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69098272 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 May 2005 07:50:23 -0400
Received: from 220.225.34.211 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Tue, 3 May 2005 07:50:23 -0400
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Thread-Topic: DR election
Thread-Index: AcVPNgzq0MRhzGfTSreuUgYATWXcyQAn6dNw
Message-ID:  <7F17177AC9AC2F4CB4A1A33C936D038D7E2275@nevismail01.pune.nevisnetworks.com>
Date:         Tue, 3 May 2005 17:20:18 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Naresh Paliwal <naresh.paliwal@NEVISNETWORKS.COM>
Subject: Re: DR election
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

Erblich,

I didn't get your reply, can u please give the references of the idea.

I mean to ask, is it possible to enforce DR/BDR-election without
changing configuration of existing DR/BDR?

Regards
-Naresh


-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of
Erblichs
Sent: Monday, May 02, 2005 10:07 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: DR election

Yes and no,

If a router "really wants to be the DR", the protocol does
allow this through a back door. The router must act like
it was already also elected as the DR. This can happen in
what was a split area. By coming up later, the later router
SHOULD know the other's priority and router-id. It can then
boost its broadcasted priority and/or its router-id to gurantee
re-election.

Mitchell Erblich
----------------------


"Krishnan, Vijay G." wrote:
>=20
> The first router does not become the DR immediately. It waits for its
> configurable "wait timer" to expire, before electing the DR. Others
routers
> could come up during this time. Once the DR is elected, addition of
new
> routers would not change the DR. This will reduce the instability due
to the
> DR changes.
>=20
> regards
> Vijay
>=20
> -----Original Message-----
> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Ilan
> Bercovich
> Sent: Monday, May 02, 2005 11:51 AM
> To: OSPF@PEACH.EASE.LSOFT.COM
> Subject: DR election
>=20
> Hello
> If all routers accept the DR regardless of their Router Priority,
> It means that actually the first active router on the LAN is the DR.
> Isn't this makes the Router Priority parameter somewhat irrelevant?
> (In RSTP for instance, when priority is changed - network is
> re-calculated).
> Ilan


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May  3 08:54:29 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13007
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 3 May 2005 08:54:28 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0103163B@cherry.ease.lsoft.com>; Tue, 3 May 2005 8:54:28 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69107057 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 May 2005 08:54:27 -0400
Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Tue, 3 May 2005 08:54:27 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com
          with ESMTP; 03 May 2005 09:07:48 -0400
X-IronPort-AV: i="3.92,148,1112587200"; d="scan'208"; a="47182927:sNHT34116648"
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 j43CsMRS026740 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 3 May 2005
          08:54:24 -0400 (EDT)
Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by
          xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue,
          3 May 2005 08:54:22 -0400
Received: from [10.82.241.73] ([10.82.241.73]) by xfe-rtp-211.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 08:54:22 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <7F17177AC9AC2F4CB4A1A33C936D038D7E2275@nevismail01.pune.nevisnetworks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 May 2005 12:54:22.0198 (UTC)
                       FILETIME=[3A28C960:01C54FDF]
Message-ID:  <4277747D.5040101@cisco.com>
Date:         Tue, 3 May 2005 08:54:21 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: DR election
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <7F17177AC9AC2F4CB4A1A33C936D038D7E2275@nevismail01.pune.nevisnetworks.com>
Precedence: list
Content-Transfer-Encoding: 7bit

All,

This has been discussed before on this list and you could search
the archives to get all the gritty details. In summary:

   - The protocol attempts to avoid BDR/DR churn and the BDR/DR election
      gives the current BDR/DR precedence. The reason is obvious - you 
want to
     avoid the network overhead/convergence delay of bringing up
     adjacencies with the new BDR/DR as well as  the 
overhead/convergence delay
     of flooding and recalculating the intra-area route table with a new 
DR's
     network-LSA.
   - While it is not part of the protocol specification, an 
implementation could
      force a BDR/DR election by ignoring the fact that there is a 
BDR/DR and
     asserting themselves as BDR/DR. They would cause a NeighborChange
     event (Section 9.2, RFC 2328) causing RFC 2328 compliant 
implementations
     to perform a BDR/DR election.

Thanks,
Acee

Naresh Paliwal wrote:

>Erblich,
>
>I didn't get your reply, can u please give the references of the idea.
>
>I mean to ask, is it possible to enforce DR/BDR-election without
>changing configuration of existing DR/BDR?
>
>Regards
>-Naresh
>
>
>-----Original Message-----
>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of
>Erblichs
>Sent: Monday, May 02, 2005 10:07 PM
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: Re: DR election
>
>Yes and no,
>
>If a router "really wants to be the DR", the protocol does
>allow this through a back door. The router must act like
>it was already also elected as the DR. This can happen in
>what was a split area. By coming up later, the later router
>SHOULD know the other's priority and router-id. It can then
>boost its broadcasted priority and/or its router-id to gurantee
>re-election.
>
>Mitchell Erblich
>----------------------
>
>
>"Krishnan, Vijay G." wrote:
>  
>
>>The first router does not become the DR immediately. It waits for its
>>configurable "wait timer" to expire, before electing the DR. Others
>>    
>>
>routers
>  
>
>>could come up during this time. Once the DR is elected, addition of
>>    
>>
>new
>  
>
>>routers would not change the DR. This will reduce the instability due
>>    
>>
>to the
>  
>
>>DR changes.
>>
>>regards
>>Vijay
>>
>>-----Original Message-----
>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Ilan
>>Bercovich
>>Sent: Monday, May 02, 2005 11:51 AM
>>To: OSPF@PEACH.EASE.LSOFT.COM
>>Subject: DR election
>>
>>Hello
>>If all routers accept the DR regardless of their Router Priority,
>>It means that actually the first active router on the LAN is the DR.
>>Isn't this makes the Router Priority parameter somewhat irrelevant?
>>(In RSTP for instance, when priority is changed - network is
>>re-calculated).
>>Ilan
>>    
>>
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May  3 10:43:59 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25322
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 3 May 2005 10:43:59 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010317C4@cherry.ease.lsoft.com>; Tue, 3 May 2005 10:43:59 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69121290 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 May 2005 10:43:58 -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Tue, 3 May 2005 10:43:21 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com
          with ESMTP; 03 May 2005 10:43:21 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
          [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP
          id j43Eh3e1013134 for <ospf@peach.ease.lsoft.com>; Tue, 3 May 2005
          10:43:18 -0400 (EDT)
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); Tue,
          3 May 2005 10:43:09 -0400
Received: from [10.82.241.73] ([10.82.241.73]) by xfe-rtp-201.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 10:43:08 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 May 2005 14:43:08.0977 (UTC)
                       FILETIME=[6C6C3A10:01C54FEE]
Message-ID:  <42778DFC.4060107@cisco.com>
Date:         Tue, 3 May 2005 10:43:08 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: RFC 2370 Update and a Proposed Change to Stub Area Behavior
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

In the evolution of the OSPFv2 protocol specification
(RFC 1247->RFC 1583 -> RFC 2178 -> RFC 2328) numerous
bugs were fixed and some protocol behaviors were altered. Examples
include the metric cost for area ranges and the selection of the
ASBR for AS external route computation.

In the context of documenting the OSPFv3 NSSA differences I've
looked again at section 2.10 and I really think the idea of not flooding
unknown LSA types with the U-bit set to 1 is broken. I think it breaks
the whole idea of being able to introduce new LSA types in a backward
compatible fashion. Furthermore, it won't stop the leakage of these
unknown LSAs when some routers understand them and others do not -
it all depends on whether you have a spanning tree of routers that
understand them. Since the LSAs in question are area scoped or link
scoped, it implies that at least one router (the originator) understands 
the
new type and you will have a mixture. IMHO, this is broken. I've had
some discussions with others who agree. At this juncture,
we have 3 alternatives:

    1) Remove the restriction for that unknown LSAs with the U-bit
        set to 0 for stub areas.
    2) Extend the broken restriction to NSSAs in the update.
    3) Limit the damage to stub areas and only restrict AS scoped LSAs
        from NSSAs.

Of course, I'd vote for #1 or I wouldn't be sending this E-mail.

Thanks,
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May  3 17:39:00 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14254
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 3 May 2005 17:39:00 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0103210D@cherry.ease.lsoft.com>; Tue, 3 May 2005 17:38:59 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69162916 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 May 2005 17:38:57 -0400
Received: from 207.217.121.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Tue, 3 May 2005 17:38:57 -0400
Received: from h-68-164-88-190.snvacaid.dynamic.covad.net ([68.164.88.190]
          helo=earthlink.net) by pop-a065d19.pas.sa.earthlink.net with esmtp
          (Exim 3.36 #10) id 1DT56W-0002Yr-00 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 03 May 2005 14:38:56 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <7F17177AC9AC2F4CB4A1A33C936D038D7E2275@nevismail01.pune.nevisnetworks.com>
            <4277747D.5040101@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <4277F11C.91DCF5C6@earthlink.net>
Date:         Tue, 3 May 2005 14:46:04 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: DR election
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Acee,

	Thanks' I just don't have the RFCs memorized
	to what section says what and yes, trying to solve
	a few gray issues to satisfy customers so I don't
	monitor this discussion on a daily basis.

	HOWEVER, Sorry,, I have to say more..

	The resulting re-election of the DR SHOULD NOT
	cause a major "churn", yes a minor churn.

	The reason is that if the re-election is done,
	their is no gurantee of a change in the DR, unless
	my suggestion of a delayed hello.

	If a new DR is elected, the previous DR would more
	than likely become the BDR or the BDR would stay
	the same. Thus, at least 1/2 of the full adjs
	are expected to stay the same.

	If this was an actual area combining event
	then the re-synch of the LSDB is necessary,
	else most of the LSDB updates would be on a 1
	way basis and only with the 1st full neighbor
	LSDB exchange.

	Yes, a minor churn, but if the new router has
	significantly higher capabilities than the present
	DR, I would see little reason not to at least
	consider this as a feature.

	Mitchell Erblich
	----------------


Acee Lindem wrote:
> 
> All,
> 
> This has been discussed before on this list and you could search
> the archives to get all the gritty details. In summary:
> 
>    - The protocol attempts to avoid BDR/DR churn and the BDR/DR election
>       gives the current BDR/DR precedence. The reason is obvious - you
> want to
>      avoid the network overhead/convergence delay of bringing up
>      adjacencies with the new BDR/DR as well as  the
> overhead/convergence delay
>      of flooding and recalculating the intra-area route table with a new
> DR's
>      network-LSA.
>    - While it is not part of the protocol specification, an
> implementation could
>       force a BDR/DR election by ignoring the fact that there is a
> BDR/DR and
>      asserting themselves as BDR/DR. They would cause a NeighborChange
>      event (Section 9.2, RFC 2328) causing RFC 2328 compliant
> implementations
>      to perform a BDR/DR election.
> 
> Thanks,
> Acee
> 
> Naresh Paliwal wrote:
> 
> >Erblich,
> >
> >I didn't get your reply, can u please give the references of the idea.
> >
> >I mean to ask, is it possible to enforce DR/BDR-election without
> >changing configuration of existing DR/BDR?
> >
> >Regards
> >-Naresh
> >
> >
> >-----Original Message-----
> >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of
> >Erblichs
> >Sent: Monday, May 02, 2005 10:07 PM
> >To: OSPF@PEACH.EASE.LSOFT.COM
> >Subject: Re: DR election
> >
> >Yes and no,
> >
> >If a router "really wants to be the DR", the protocol does
> >allow this through a back door. The router must act like
> >it was already also elected as the DR. This can happen in
> >what was a split area. By coming up later, the later router
> >SHOULD know the other's priority and router-id. It can then
> >boost its broadcasted priority and/or its router-id to gurantee
> >re-election.
> >
> >Mitchell Erblich
> >----------------------
> >
> >
> >"Krishnan, Vijay G." wrote:
> >
> >
> >>The first router does not become the DR immediately. It waits for its
> >>configurable "wait timer" to expire, before electing the DR. Others
> >>
> >>
> >routers
> >
> >
> >>could come up during this time. Once the DR is elected, addition of
> >>
> >>
> >new
> >
> >
> >>routers would not change the DR. This will reduce the instability due
> >>
> >>
> >to the
> >
> >
> >>DR changes.
> >>
> >>regards
> >>Vijay
> >>
> >>-----Original Message-----
> >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Ilan
> >>Bercovich
> >>Sent: Monday, May 02, 2005 11:51 AM
> >>To: OSPF@PEACH.EASE.LSOFT.COM
> >>Subject: DR election
> >>
> >>Hello
> >>If all routers accept the DR regardless of their Router Priority,
> >>It means that actually the first active router on the LAN is the DR.
> >>Isn't this makes the Router Priority parameter somewhat irrelevant?
> >>(In RSTP for instance, when priority is changed - network is
> >>re-calculated).
> >>Ilan
> >>
> >>
> >
> >
> >


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May  4 08:37:28 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01228
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 May 2005 08:37:28 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010331A1@cherry.ease.lsoft.com>; Wed, 4 May 2005 8:37:27 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69249048 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 May 2005 08:37:26 -0400
Received: from 129.89.169.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Wed, 4 May 2005 08:27:26 -0400
Received: from mail04.imt.uwm.edu (mail04.imt.uwm.edu [129.89.7.46]) by
          batch3.csd.uwm.edu (8.12.10/8.12.6) with ESMTP id j44CRQt7030204 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 4 May 2005 07:27:26 -0500 (CDT)
Received: from localhost (pm03.imt.uwm.edu [129.89.7.63]) by mail04.imt.uwm.edu
          (8.12.10/8.12.5) with ESMTP id j44CRPqv028183; Wed, 4 May 2005
          07:27:25 -0500
Received: from adsl-68-249-0-56.dsl.milwwi.ameritech.net
          (adsl-68-249-0-56.dsl.milwwi.ameritech.net [68.249.0.56]) by
          panthermail.uwm.edu (IMP) with HTTP for <mukul@localhost>; Wed,  4
          May 2005 07:27:25 -0500
References: <7F17177AC9AC2F4CB4A1A33C936D038D7E2275@nevismail01.pune.nevisnetworks.com>           
            <4277747D.5040101@cisco.com> <4277F11C.91DCF5C6@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: PantherMail 3.2.8-cvs
X-Originating-IP: 68.249.0.56
X-Virus-Scanned: by amavisd-new
X-Spam-Status: No,
               hits=-48.661 required=5 tests=NO_REAL_NAME,UWM_DOMAIN_MESSAGE_1
X-Scanned-By: MIMEDefang 2.51 on 129.89.7.46
Message-ID:  <1115209645.4278bfad9c129@panthermail.uwm.edu>
Date:         Wed, 4 May 2005 07:27:25 -0500
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mukul Goyal <mukul@UWM.EDU>
Subject: A writeup on interface state machine (Re: DR election)
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <4277F11C.91DCF5C6@earthlink.net>
Precedence: list
Content-Transfer-Encoding: 8bit

We recently completed a writeup on OSPF interface state machine behavior over a
broadcast LAN.

http://www.cs.uwm.edu/~mukul/ospflan.pdf

The paper considers the DR/BDR settling time and the number of DR elections
performed as the routers on the broadcast LAN come up in a random fashion. We
consider the case where all the routers on the LAN have the same Router
Priority for election as DR/BDR.

I will appreciate receiving your feedback (preferably offline) so that I can
improve the paper and correct any mistakes. Also, I am looking for references
to any existing literature on the topic.

Thanks,
Mukul Goyal

Quoting Erblichs <erblichs@EARTHLINK.NET>:

> Acee,
>
> 	Thanks' I just don't have the RFCs memorized
> 	to what section says what and yes, trying to solve
> 	a few gray issues to satisfy customers so I don't
> 	monitor this discussion on a daily basis.
>
> 	HOWEVER, Sorry,, I have to say more..
>
> 	The resulting re-election of the DR SHOULD NOT
> 	cause a major "churn", yes a minor churn.
>
> 	The reason is that if the re-election is done,
> 	their is no gurantee of a change in the DR, unless
> 	my suggestion of a delayed hello.
>
> 	If a new DR is elected, the previous DR would more
> 	than likely become the BDR or the BDR would stay
> 	the same. Thus, at least 1/2 of the full adjs
> 	are expected to stay the same.
>
> 	If this was an actual area combining event
> 	then the re-synch of the LSDB is necessary,
> 	else most of the LSDB updates would be on a 1
> 	way basis and only with the 1st full neighbor
> 	LSDB exchange.
>
> 	Yes, a minor churn, but if the new router has
> 	significantly higher capabilities than the present
> 	DR, I would see little reason not to at least
> 	consider this as a feature.
>
> 	Mitchell Erblich
> 	----------------
>
>
> Acee Lindem wrote:
> >
> > All,
> >
> > This has been discussed before on this list and you could search
> > the archives to get all the gritty details. In summary:
> >
> >    - The protocol attempts to avoid BDR/DR churn and the BDR/DR election
> >       gives the current BDR/DR precedence. The reason is obvious - you
> > want to
> >      avoid the network overhead/convergence delay of bringing up
> >      adjacencies with the new BDR/DR as well as  the
> > overhead/convergence delay
> >      of flooding and recalculating the intra-area route table with a new
> > DR's
> >      network-LSA.
> >    - While it is not part of the protocol specification, an
> > implementation could
> >       force a BDR/DR election by ignoring the fact that there is a
> > BDR/DR and
> >      asserting themselves as BDR/DR. They would cause a NeighborChange
> >      event (Section 9.2, RFC 2328) causing RFC 2328 compliant
> > implementations
> >      to perform a BDR/DR election.
> >
> > Thanks,
> > Acee
> >
> > Naresh Paliwal wrote:
> >
> > >Erblich,
> > >
> > >I didn't get your reply, can u please give the references of the idea.
> > >
> > >I mean to ask, is it possible to enforce DR/BDR-election without
> > >changing configuration of existing DR/BDR?
> > >
> > >Regards
> > >-Naresh
> > >
> > >
> > >-----Original Message-----
> > >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of
> > >Erblichs
> > >Sent: Monday, May 02, 2005 10:07 PM
> > >To: OSPF@PEACH.EASE.LSOFT.COM
> > >Subject: Re: DR election
> > >
> > >Yes and no,
> > >
> > >If a router "really wants to be the DR", the protocol does
> > >allow this through a back door. The router must act like
> > >it was already also elected as the DR. This can happen in
> > >what was a split area. By coming up later, the later router
> > >SHOULD know the other's priority and router-id. It can then
> > >boost its broadcasted priority and/or its router-id to gurantee
> > >re-election.
> > >
> > >Mitchell Erblich
> > >----------------------
> > >
> > >
> > >"Krishnan, Vijay G." wrote:
> > >
> > >
> > >>The first router does not become the DR immediately. It waits for its
> > >>configurable "wait timer" to expire, before electing the DR. Others
> > >>
> > >>
> > >routers
> > >
> > >
> > >>could come up during this time. Once the DR is elected, addition of
> > >>
> > >>
> > >new
> > >
> > >
> > >>routers would not change the DR. This will reduce the instability due
> > >>
> > >>
> > >to the
> > >
> > >
> > >>DR changes.
> > >>
> > >>regards
> > >>Vijay
> > >>
> > >>-----Original Message-----
> > >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Ilan
> > >>Bercovich
> > >>Sent: Monday, May 02, 2005 11:51 AM
> > >>To: OSPF@PEACH.EASE.LSOFT.COM
> > >>Subject: DR election
> > >>
> > >>Hello
> > >>If all routers accept the DR regardless of their Router Priority,
> > >>It means that actually the first active router on the LAN is the DR.
> > >>Isn't this makes the Router Priority parameter somewhat irrelevant?
> > >>(In RSTP for instance, when priority is changed - network is
> > >>re-calculated).
> > >>Ilan
> > >>
> > >>
> > >
> > >
> > >
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May  4 10:07:12 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11241
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 May 2005 10:07:12 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.010332C2@cherry.ease.lsoft.com>; Wed, 4 May 2005 10:07:12 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69270091 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 May 2005 10:07:11 -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Wed, 4 May 2005 10:07:11 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com
          with ESMTP; 04 May 2005 10:07:11 -0400
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 j44E74RU028212 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 4 May 2005
          10:07:08 -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,
          4 May 2005 10:07:03 -0400
Received: from [10.82.241.73] ([10.82.241.73]) by xfe-rtp-201.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 10:07:03 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <7F17177AC9AC2F4CB4A1A33C936D038D7E2275@nevismail01.pune.nevisnetworks.com>           
            <4277747D.5040101@cisco.com> <4277F11C.91DCF5C6@earthlink.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 May 2005 14:07:03.0110 (UTC)
                       FILETIME=[8BE0E660:01C550B2]
Message-ID:  <4278D706.1040906@cisco.com>
Date:         Wed, 4 May 2005 10:07:02 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: DR election
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <4277F11C.91DCF5C6@earthlink.net>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Mitchell,
I don't see this as a strong requirement since one could always
configure a router priority of 0 on those routers which are not
able to hande the DR task. We've gotten along without this
DR preemption feature for this long and to the best of my knowledge
there aren't even any proprietary extensions to do this. This would
indicate to me that there is not a strong requirement.

As always, you are welcome to make such a proposal in
an individual draft for consideration by the WG.

Thanks,
Acee

Erblichs wrote:

>Acee,
>
>	Thanks' I just don't have the RFCs memorized
>	to what section says what and yes, trying to solve
>	a few gray issues to satisfy customers so I don't
>	monitor this discussion on a daily basis.
>
>	HOWEVER, Sorry,, I have to say more..
>
>	The resulting re-election of the DR SHOULD NOT
>	cause a major "churn", yes a minor churn.
>
>	The reason is that if the re-election is done,
>	their is no gurantee of a change in the DR, unless
>	my suggestion of a delayed hello.
>
>	If a new DR is elected, the previous DR would more
>	than likely become the BDR or the BDR would stay
>	the same. Thus, at least 1/2 of the full adjs
>	are expected to stay the same.
>
>	If this was an actual area combining event
>	then the re-synch of the LSDB is necessary,
>	else most of the LSDB updates would be on a 1
>	way basis and only with the 1st full neighbor
>	LSDB exchange.
>
>	Yes, a minor churn, but if the new router has
>	significantly higher capabilities than the present
>	DR, I would see little reason not to at least
>	consider this as a feature.
>
>	Mitchell Erblich
>	----------------
>
>
>Acee Lindem wrote:
>  
>
>>All,
>>
>>This has been discussed before on this list and you could search
>>the archives to get all the gritty details. In summary:
>>
>>   - The protocol attempts to avoid BDR/DR churn and the BDR/DR election
>>      gives the current BDR/DR precedence. The reason is obvious - you
>>want to
>>     avoid the network overhead/convergence delay of bringing up
>>     adjacencies with the new BDR/DR as well as  the
>>overhead/convergence delay
>>     of flooding and recalculating the intra-area route table with a new
>>DR's
>>     network-LSA.
>>   - While it is not part of the protocol specification, an
>>implementation could
>>      force a BDR/DR election by ignoring the fact that there is a
>>BDR/DR and
>>     asserting themselves as BDR/DR. They would cause a NeighborChange
>>     event (Section 9.2, RFC 2328) causing RFC 2328 compliant
>>implementations
>>     to perform a BDR/DR election.
>>
>>Thanks,
>>Acee
>>
>>Naresh Paliwal wrote:
>>
>>    
>>
>>>Erblich,
>>>
>>>I didn't get your reply, can u please give the references of the idea.
>>>
>>>I mean to ask, is it possible to enforce DR/BDR-election without
>>>changing configuration of existing DR/BDR?
>>>
>>>Regards
>>>-Naresh
>>>
>>>
>>>-----Original Message-----
>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of
>>>Erblichs
>>>Sent: Monday, May 02, 2005 10:07 PM
>>>To: OSPF@PEACH.EASE.LSOFT.COM
>>>Subject: Re: DR election
>>>
>>>Yes and no,
>>>
>>>If a router "really wants to be the DR", the protocol does
>>>allow this through a back door. The router must act like
>>>it was already also elected as the DR. This can happen in
>>>what was a split area. By coming up later, the later router
>>>SHOULD know the other's priority and router-id. It can then
>>>boost its broadcasted priority and/or its router-id to gurantee
>>>re-election.
>>>
>>>Mitchell Erblich
>>>----------------------
>>>
>>>
>>>"Krishnan, Vijay G." wrote:
>>>
>>>
>>>      
>>>
>>>>The first router does not become the DR immediately. It waits for its
>>>>configurable "wait timer" to expire, before electing the DR. Others
>>>>
>>>>
>>>>        
>>>>
>>>routers
>>>
>>>
>>>      
>>>
>>>>could come up during this time. Once the DR is elected, addition of
>>>>
>>>>
>>>>        
>>>>
>>>new
>>>
>>>
>>>      
>>>
>>>>routers would not change the DR. This will reduce the instability due
>>>>
>>>>
>>>>        
>>>>
>>>to the
>>>
>>>
>>>      
>>>
>>>>DR changes.
>>>>
>>>>regards
>>>>Vijay
>>>>
>>>>-----Original Message-----
>>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Ilan
>>>>Bercovich
>>>>Sent: Monday, May 02, 2005 11:51 AM
>>>>To: OSPF@PEACH.EASE.LSOFT.COM
>>>>Subject: DR election
>>>>
>>>>Hello
>>>>If all routers accept the DR regardless of their Router Priority,
>>>>It means that actually the first active router on the LAN is the DR.
>>>>Isn't this makes the Router Priority parameter somewhat irrelevant?
>>>>(In RSTP for instance, when priority is changed - network is
>>>>re-calculated).
>>>>Ilan
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May  4 10:08:06 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11410
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 May 2005 10:08:06 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.01033451@cherry.ease.lsoft.com>; Wed, 4 May 2005 10:08:07 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69262404 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 May 2005 10:08:06 -0400
Received: from 217.9.74.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Wed, 4 May 2005 09:57:14 -0400
Received: from localhost (localhost [127.0.0.1]) by brunello.labnet.cnit.it
          (Postfix) with ESMTP id AF4544E5D5 for <OSPF@PEACH.EASE.LSOFT.COM>;
          Wed,  4 May 2005 15:57:12 +0200 (CEST)
Received: from brunello.labnet.cnit.it ([127.0.0.1]) by localhost (brunello
          [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13109-01-5 for 
          <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 4 May 2005 15:56:54 +0200 (CEST)
Received: from novello.labnet.cnit.it (ns.cnit.it [217.9.64.3]) by
          brunello.labnet.cnit.it (Postfix) with ESMTP id DB80A4E57A for
          <OSPF@PEACH.EASE.LSOFT.COM>; Wed,  4 May 2005 15:56:54 +0200 (CEST)
Received: from Platini (unknown [217.9.70.82]) by novello.labnet.cnit.it
          (Postfix) with ESMTP id A9FBE3B5BE for <OSPF@PEACH.EASE.LSOFT.COM>;
          Wed,  4 May 2005 15:56:54 +0200 (CEST)
References: <7F17177AC9AC2F4CB4A1A33C936D038D7E2275@nevismail01.pune.nevisnetworks.com>                      
            <4277747D.5040101@cisco.com> <4277F11C.91DCF5C6@earthlink.net> 
            <1115209645.4278bfad9c129@panthermail.uwm.edu>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
              reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cnit.it
Message-ID:  <094901c550b1$1b357990$524609d9@Platini>
Date:         Wed, 4 May 2005 15:56:44 +0200
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Filippo Cugini <filippo.cugini@CNIT.IT>
Subject: Re: A writeup on interface state machine (Re: DR election)
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Just to add something about DR election.
I suggest to include in OSPF router implementations a "point-to-point" 
statement even for Ethernet Networks.
We have point-to-point optical Ethernet connections between routers running 
OSPF and we don't want to waste 40sec for the DR-BDR election every time a 
new connection is established. There is no need to consider Ethernet a 
broadcast network in such conditions

Best regards
  Filippo


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May  4 23:59:14 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19856
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 May 2005 23:59:14 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0103467D@cherry.ease.lsoft.com>; Wed, 4 May 2005 23:59:12 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69344177 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 May 2005 23:59:11 -0400
Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Wed, 4 May 2005 23:59:10 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Thread-Topic: A writeup on interface state machine (Re: DR election)
Thread-Index: AcVQsrLfYveAl/rXRoeYRl4erLeItAAdXhfg
Message-ID:  <BB6D74C75CC76A419B6D6FA7C38317B27A856D@sinett-sbs.SiNett.LAN>
Date:         Wed, 4 May 2005 20:59:10 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vishwas Manral <Vishwas@SINETT.COM>
Subject: Re: A writeup on interface state machine (Re: DR election)
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

Filippo,

There is no reason you should configure Full-Duplex Ethernet link as
broadcast.=20

The OSPF MIB already allows the configuration of link type.

Thanks,
Vishwas
-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of
Filippo Cugini
Sent: Wednesday, May 04, 2005 7:27 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: A writeup on interface state machine (Re: DR election)

Just to add something about DR election.
I suggest to include in OSPF router implementations a "point-to-point"=20
statement even for Ethernet Networks.
We have point-to-point optical Ethernet connections between routers
running=20
OSPF and we don't want to waste 40sec for the DR-BDR election every time
a=20
new connection is established. There is no need to consider Ethernet a=20
broadcast network in such conditions

Best regards
  Filippo


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May  5 13:37:46 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22349
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 May 2005 13:37:45 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.01035DB2@cherry.ease.lsoft.com>; Thu, 5 May 2005 13:37:47 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69441782 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 5 May 2005 13:37:42 -0400
Received: from 217.9.74.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Thu, 5 May 2005 13:37:42 -0400
Received: from localhost (localhost [127.0.0.1]) by brunello.labnet.cnit.it
          (Postfix) with ESMTP id 60E494E592 for <OSPF@PEACH.EASE.LSOFT.COM>;
          Thu,  5 May 2005 19:37:41 +0200 (CEST)
Received: from brunello.labnet.cnit.it ([127.0.0.1]) by localhost (brunello
          [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17915-02-3 for 
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 5 May 2005 19:37:23 +0200 (CEST)
Received: from novello.labnet.cnit.it (ns.cnit.it [217.9.64.3]) by
          brunello.labnet.cnit.it (Postfix) with ESMTP id 61F024E589 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu,  5 May 2005 19:37:23 +0200 (CEST)
Received: from Platini (unknown [217.9.70.82]) by novello.labnet.cnit.it
          (Postfix) with ESMTP id 3BF533BD98 for <OSPF@PEACH.EASE.LSOFT.COM>;
          Thu,  5 May 2005 19:37:22 +0200 (CEST)
References:  <BB6D74C75CC76A419B6D6FA7C38317B27A856D@sinett-sbs.SiNett.LAN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
              reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cnit.it
Message-ID:  <005a01c55199$10e5f800$524609d9@Platini>
Date:         Thu, 5 May 2005 19:37:10 +0200
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Filippo Cugini <filippo.cugini@CNIT.IT>
Subject: Re: A writeup on interface state machine (Re: DR election)
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Vishwas,
I agree, the 'problem' is in OSPF implementations not in OSPF RFCs
Thanks,
  Filippo


----- Original Message ----- 
From: "Vishwas Manral" <Vishwas@SINETT.COM>
To: <OSPF@PEACH.EASE.LSOFT.COM>
Sent: Thursday, May 05, 2005 5:59 AM
Subject: Re: A writeup on interface state machine (Re: DR election)


Filippo,

There is no reason you should configure Full-Duplex Ethernet link as
broadcast. 

The OSPF MIB already allows the configuration of link type.

Thanks,
Vishwas
-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of
Filippo Cugini
Sent: Wednesday, May 04, 2005 7:27 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: A writeup on interface state machine (Re: DR election)

Just to add something about DR election.
I suggest to include in OSPF router implementations a "point-to-point" 
statement even for Ethernet Networks.
We have point-to-point optical Ethernet connections between routers
running 
OSPF and we don't want to waste 40sec for the DR-BDR election every time
a 
new connection is established. There is no need to consider Ethernet a 
broadcast network in such conditions

Best regards
  Filippo


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May  9 02:42:54 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06012
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 May 2005 02:42:53 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0103C3AD@cherry.ease.lsoft.com>; Mon, 9 May 2005 2:42:51 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69877241 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 May 2005 02:42:49 -0400
Received: from 203.197.124.190 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Mon, 9 May 2005 02:42:47 -0400
Received: from DEBOPAMLAPTOP ([192.168.10.222]) by alumnux.com (8.9.3/8.9.3)
          with SMTP id MAA02277 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 9 May
          2005 12:29:34 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_01CB_01C55490.5F7ABBF0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Message-ID:  <01ce01c55462$4b2b1510$de0aa8c0@DEBOPAMLAPTOP>
Date:         Mon, 9 May 2005 12:12:30 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Debopam Bandyopadhyay <debopam@ALUMNUX.COM>
Organization: Alumnus Software Ltd
Subject: Reestablish adjacencies after Graceful-Restart
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

This is a multi-part message in MIME format.

------=_NextPart_000_01CB_01C55490.5F7ABBF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This question is a bit long, backdated and maybe, queer. But it is a bit =
critical for me.
It is regarding RFC 3623 (Graceful OSPF Restart), Section 2.2. "When to =
Exit Graceful Restart", Point 1 "Router X has reestablished all its =
adjacencies".

I am trying to identify the corresponding event from RFC 2328 for Router =
X. Is it one of the following:
a> Upon installation of an LSA in the database [RFC2328, Sec 13.2] [and =
thereby tracing the database for all the relevant LSAs which indicate =
the previous adjacencies],
     or
b> State of neighbor Y changing to Full; [and thereby tracing the =
database ...]
     or
c> Implementation specific

Let me explain this with a simplified example:

            X ----- lan ----- Y

In the topology, we have two routers, X and Y; and Y happens to be the =
DR in the network segment.

Now Router X restarts. After 'T' seconds, Router X becomes fully =
adjacent with Router Y.

At this point, three scenarios are possible:
1> X had received all the relevant LSAs (i.e. router-LSAs of X, Y and =
Network-LSA of Y) BEFORE becoming fully adjacent with Y.
     Hence, the graceful-restart exit event has already been fired =
BEFORE X became fully adjacent with Y.
2> X had received all the relevant LSAs BEFORE becoming fully adjacent =
with Y;
     but graceful-restart exit event gets fired EXACTLY when X became =
fully adjacent with Y.
3> X had completed receiving all the relevant LSAs AFTER becoming fully =
adjacent with Y;
     Hence, the graceful-restart exit event gets fired sometime AFTER X =
became fully adjacent with Y.

Thanks,
Debopam
------=_NextPart_000_01CB_01C55490.5F7ABBF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>This question is a bit long, backdated =
and maybe,=20
queer. But it is a bit&nbsp;critical for me.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>It&nbsp;is regarding RFC 3623 (Graceful =
OSPF=20
Restart), Section 2.2. "When to Exit Graceful Restart", Point 1 "Router =
X has=20
reestablished all its adjacencies".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I&nbsp;am trying&nbsp;to =
identify&nbsp;the=20
corresponding event&nbsp;from RFC 2328&nbsp;for Router X. Is it one of =
the=20
following:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>a&gt; Upon&nbsp;installation of&nbsp;an =
LSA in the=20
database [RFC2328, Sec 13.2]&nbsp;[and thereby tracing the database for =
all the=20
relevant LSAs which indicate the previous adjacencies],</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;or</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>b&gt; State of neighbor Y changing to =
Full; [and=20
thereby&nbsp;tracing the database ...]</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
or</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>c&gt; Implementation =
specific</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Let me explain this with a simplified=20
example:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; X=20
----- lan ----- Y</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In the topology, we have two routers, X =
and Y; and=20
Y&nbsp;happens to be&nbsp;the DR in the network segment.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Now&nbsp;Router X restarts.&nbsp;After =
'T'=20
seconds,&nbsp;Router X becomes fully adjacent with Router =
Y.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>At this point,&nbsp;three scenarios are =

possible:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>1&gt; X&nbsp;had received&nbsp;all the =
relevant=20
LSAs (i.e. router-LSAs of X, Y and Network-LSA of Y)&nbsp;BEFORE =
becoming fully=20
adjacent with Y.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; Hence, the=20
graceful-restart exit event&nbsp;has already been fired&nbsp;BEFORE X =
became=20
fully adjacent with Y.</FONT></DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>2&gt; X&nbsp;had received&nbsp;all the =
relevant=20
LSAs BEFORE becoming fully adjacent with Y;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;but =
graceful-restart=20
exit event gets fired EXACTLY when X became fully adjacent with =
Y.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>3&gt; X&nbsp;had completed receiving =
all the=20
relevant LSAs AFTER becoming fully adjacent with Y;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; Hence, the=20
graceful-restart exit event&nbsp;gets fired sometime AFTER X became =
fully=20
adjacent with Y.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>Debopam</FONT></DIV></DIV></BODY></HTML>

------=_NextPart_000_01CB_01C55490.5F7ABBF0--


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May  9 06:18:45 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24177
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 May 2005 06:18:45 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0103C6E2@cherry.ease.lsoft.com>; Mon, 9 May 2005 6:18:45 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69890702 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 May 2005 06:18:06 -0400
Received: from 209.119.0.160 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Mon, 9 May 2005 06:07:24 -0400
Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <11.0089D2D2@almond.ease.lsoft.com>; Mon, 9 May 2005 6:07:20 -0400
Message-ID:  <LISTSERV%200505090607199500.31E6@PEACH.EASE.LSOFT.COM>
Date:         Mon, 9 May 2005 06:07:19 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Srinivasa J Ragavan <srinivasarj@HCLTECH.COM>
Subject: Doubt on sending hello packets on NBMA networks
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

hi All,

I am a newbie to OSPF.
can anyone help me out.
this is with reference to the rfc 2328 sec. 9.5.1 whcih says
"  If the router is eligible to become Designated Router, it
            must periodically send Hello Packets to all neighbors that
            are also eligible."

but immediately in the next paragraph it says

" It must also send an Hello Packet in reply to an
            Hello Packet received from any eligible neighbor (other than
            the current Designated Router and Backup Designated Router)"

how can a non eligible router get a hello from a eligibe router if the
eligible router is not going to send(tatz what the first argument says)

Am i missing something here??

thanks
Srini


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May  9 08:25:44 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05292
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 May 2005 08:25:43 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0103C84A@cherry.ease.lsoft.com>; Mon, 9 May 2005 8:21:08 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69941219 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 May 2005 08:21:07 -0400
Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Mon, 9 May 2005 08:21:01 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com
          with ESMTP; 09 May 2005 08:35:24 -0400
X-IronPort-AV: i="3.92,168,1112587200"; d="scan'208"; a="48364324:sNHT26616700"
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 j49CKEea020107 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 9 May 2005
          08:20:54 -0400 (EDT)
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); Mon,
          9 May 2005 08:20:46 -0400
Received: from [10.82.216.165] ([10.82.216.165]) by xfe-rtp-202.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 08:20:46 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <01ce01c55462$4b2b1510$de0aa8c0@DEBOPAMLAPTOP>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 May 2005 12:20:46.0318 (UTC)
                       FILETIME=[871468E0:01C55491]
Message-ID:  <427F559D.308@cisco.com>
Date:         Mon, 9 May 2005 08:20:45 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: Reestablish adjacencies after Graceful-Restart
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <01ce01c55462$4b2b1510$de0aa8c0@DEBOPAMLAPTOP>
Precedence: list
Content-Transfer-Encoding: 7bit

Debopam Bandyopadhyay wrote:

>This question is a bit long, backdated and maybe, queer. But it is a bit critical for me.
>It is regarding RFC 3623 (Graceful OSPF Restart), Section 2.2. "When to Exit Graceful Restart", Point 1 "Router X has reestablished all its adjacencies".
>
>I am trying to identify the corresponding event from RFC 2328 for Router X. Is it one of the following:
>a> Upon installation of an LSA in the database [RFC2328, Sec 13.2] [and thereby tracing the database for all the relevant LSAs which indicate the previous adjacencies],
>     or
>b> State of neighbor Y changing to Full; [and thereby tracing the database ...]
>     or
>c> Implementation specific
>
>Let me explain this with a simplified example:
>
>            X ----- lan ----- Y
>
>In the topology, we have two routers, X and Y; and Y happens to be the DR in the network segment.
>
>Now Router X restarts. After 'T' seconds, Router X becomes fully adjacent with Router Y.
>
>At this point, three scenarios are possible:
>1> X had received all the relevant LSAs (i.e. router-LSAs of X, Y and Network-LSA of Y) BEFORE becoming fully adjacent with Y.
>     Hence, the graceful-restart exit event has already been fired BEFORE X became fully adjacent with Y.
>2> X had received all the relevant LSAs BEFORE becoming fully adjacent with Y;
>     but graceful-restart exit event gets fired EXACTLY when X became fully adjacent with Y.
>3> X had completed receiving all the relevant LSAs AFTER becoming fully adjacent with Y;
>     Hence, the graceful-restart exit event gets fired sometime AFTER X became fully adjacent with Y.
>  
>
Hi Depopam,

As stated in RFC 3623 section 2.2, a restarting router uses its 
pre-restart router
LSA to determine whether or not it has re-established all its 
pre-restart adjacencies.
Adjacency formation implies database synchronization and reception of 
all LSAs within
the flooding domain of the router with whom the adjacency is being 
formed. Hence,
 #2 above is the only scenario which makes sense.

Hope this helps,
Acee


>Thanks,
>Debopam
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May  9 09:10:39 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09737
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 May 2005 09:10:39 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0103CA12@cherry.ease.lsoft.com>; Mon, 9 May 2005 9:10:39 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69949240 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 May 2005 09:10:38 -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Mon, 9 May 2005 09:10:38 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com
          with ESMTP; 09 May 2005 09:10:39 -0400
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 j49D9sni011920 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 9 May 2005
          09:10:36 -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); Mon,
          9 May 2005 09:10:26 -0400
Received: from [10.82.216.165] ([10.82.216.165]) by xfe-rtp-201.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 09:10:26 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <LISTSERV%200505090607199500.31E6@PEACH.EASE.LSOFT.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 May 2005 13:10:26.0331 (UTC)
                       FILETIME=[774E4EB0:01C55498]
Message-ID:  <427F6141.9070508@cisco.com>
Date:         Mon, 9 May 2005 09:10:25 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: Doubt on sending hello packets on NBMA networks
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <LISTSERV%200505090607199500.31E6@PEACH.EASE.LSOFT.COM>
Precedence: list
Content-Transfer-Encoding: 7bit

Srinivasa J Ragavan wrote:

>hi All,
>
>I am a newbie to OSPF.
>can anyone help me out.
>this is with reference to the rfc 2328 sec. 9.5.1 whcih says
>"  If the router is eligible to become Designated Router, it
>            must periodically send Hello Packets to all neighbors that
>            are also eligible."
>
>but immediately in the next paragraph it says
>
>" It must also send an Hello Packet in reply to an
>            Hello Packet received from any eligible neighbor (other than
>            the current Designated Router and Backup Designated Router)"
>
>how can a non eligible router get a hello from a eligibe router if the
>eligible router is not going to send(tatz what the first argument says)
>  
>
Srini,
In the NBMA case (which is described in section 9.5.1), a non-eligible 
router
needs to reply to any eligible neighbor since it may not know the current
DR/BDR. There are a number of scenarios where this can happen including
the case where the non-eligible neighbor first comes up and receives a 
hello poll
from the current DR/DBR. The non-eligible neighbor needs to establish
bi-directional connectivity with the potential DR/BDR in order for its
local DR/BDR election to work.

Hope this helps,
Acee


>Am i missing something here??
>
>thanks
>Srini
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May  9 10:14:11 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17012
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 May 2005 10:14:11 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0103CAEB@cherry.ease.lsoft.com>; Mon, 9 May 2005 10:14:09 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69954513 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 May 2005 10:14:04 -0400
Received: from 202.54.64.23 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Mon, 9 May 2005 10:14:00 -0400
Content-Class: urn:content-classes:message
X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited]
Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com
          with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 May 2005 19:43:57 +0530
Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id
          <K1PV620A>; Mon, 9 May 2005 19:43:57 +0530
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 09 May 2005 14:13:57.0657 (UTC)
                       FILETIME=[57088090:01C554A1]
Message-ID:  <68C9DA8F50019B4E8622C53811BEE1D602DA7D54@kavithai.ctd.hcltech.com>
Date:         Mon, 9 May 2005 19:43:45 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Srinivasaragavan Jayaraman - CTD, Chennai"              <srinivasarj@HCLTECH.COM>
Subject: Re: Doubt on sending hello packets on NBMA networks
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

hi Acee,

	yeah i got it. but just for the sake of curiosity. can you give me
some more scenarious where this can happen?

Thanks
Srini

-----Original Message-----
From: Acee Lindem [mailto:acee@CISCO.COM]
Sent: Monday, May 09, 2005 6:40 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Doubt on sending hello packets on NBMA networks


Srinivasa J Ragavan wrote:

>hi All,
>
>I am a newbie to OSPF.
>can anyone help me out.
>this is with reference to the rfc 2328 sec. 9.5.1 whcih says
>"  If the router is eligible to become Designated Router, it
>            must periodically send Hello Packets to all neighbors that
>            are also eligible."
>
>but immediately in the next paragraph it says
>
>" It must also send an Hello Packet in reply to an
>            Hello Packet received from any eligible neighbor (other =
than
>            the current Designated Router and Backup Designated =
Router)"
>
>how can a non eligible router get a hello from a eligibe router if the
>eligible router is not going to send(tatz what the first argument says)
> =20
>
Srini,
In the NBMA case (which is described in section 9.5.1), a non-eligible=20
router
needs to reply to any eligible neighbor since it may not know the =
current
DR/BDR. There are a number of scenarios where this can happen including
the case where the non-eligible neighbor first comes up and receives a=20
hello poll
from the current DR/DBR. The non-eligible neighbor needs to establish
bi-directional connectivity with the potential DR/BDR in order for its
local DR/BDR election to work.

Hope this helps,
Acee


>Am i missing something here??
>
>thanks
>Srini
>
> =20
>
DISCLAIMER=20
This message and any attachment(s) contained here are information that =
is confidential, proprietary to HCL Technologies=20
and its customers. Contents may be privileged or otherwise protected by =
law. The information is solely intended for the=20
individual or the entity it is addressed to. If you are not the intended =
recipient of this message, you are not authorized to=20
read, forward, print, retain, copy or disseminate this message or any =
part of it. If you have received this e-mail in error,=20
please notify the sender immediately by return e-mail and delete it from =
your computer


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May  9 13:07:28 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06703
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 May 2005 13:07:28 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0103CDB6@cherry.ease.lsoft.com>; Mon, 9 May 2005 13:07:29 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69973895 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 May 2005 13:07:27 -0400
Received: from 208.8.0.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Mon, 9 May 2005 12:57:24 -0400
Received: from mailhub2.ind.alcatel.com (mailhub2.ind.alcatel.com
          [198.206.181.70]) by ind.alcatel.com (8.12.9/8.12.9/(postal 2.0
          [OUT])) with ESMTP id j49GvNwQ007939 for <OSPF@peach.ease.lsoft.com>;
          Mon, 9 May 2005 09:57:23 -0700 (PDT)
X-InterScan: Passed
Received: from mailhub2.ind.alcatel.com (localhost [127.0.0.1]) by
          mailhub2.ind.alcatel.com (8.12.10/8.12.10/(mailhub2 4.1.4 [HUB2]))
          with ESMTP id j49GvJv8029680 for <OSPF@peach.ease.lsoft.com>; Mon, 9
          May 2005 09:57:22 -0700 (PDT)
Received: from omni.ind.alcatel.com ([198.206.181.20]) by
          mailhub2.ind.alcatel.com (MailFrontier 3.1.2.2789) with ESMTP; Mon,
          09 May 2005 09:57:22 -0700
Received: from Kishorepc ([128.251.40.163]) by omni.ind.alcatel.com
          (8.9.3+Sun/8.9.1 (omni 3.0 [engr-SPOOL])) with SMTP id JAA29414 for
          <OSPF@peach.ease.lsoft.com>; Mon, 9 May 2005 09:57:19 -0700 (PDT)
References:  <68C9DA8F50019B4E8622C53811BEE1D602DA7D54@kavithai.ctd.hcltech.com>
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.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mlf-Reason: list:addrbk:domain
Message-ID:  <0be001c554b8$41353990$a328fb80@Kishorepc>
Date:         Mon, 9 May 2005 10:57:57 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Kishore Rao <kishore@IND.ALCATEL.COM>
Subject: Re: Doubt on sending hello packets on NBMA networks
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Possible scenarios ?

- Timing difference between dynamically changing the eligibility
configuration/setting interface priority Vs sending of a Hello.
- Mismatch in configuration between interface priority of a router and its
eligibility configuration on other routers.

Kishore


> hi Acee,
>
> yeah i got it. but just for the sake of curiosity. can you give me
> some more scenarious where this can happen?
>
> Thanks
> Srini
>
> -----Original Message-----
> From: Acee Lindem [mailto:acee@CISCO.COM]
> Sent: Monday, May 09, 2005 6:40 PM
> To: OSPF@PEACH.EASE.LSOFT.COM
> Subject: Re: Doubt on sending hello packets on NBMA networks
>
>
> Srinivasa J Ragavan wrote:
>
> >hi All,
> >
> >I am a newbie to OSPF.
> >can anyone help me out.
> >this is with reference to the rfc 2328 sec. 9.5.1 whcih says
> >"  If the router is eligible to become Designated Router, it
> >            must periodically send Hello Packets to all neighbors that
> >            are also eligible."
> >
> >but immediately in the next paragraph it says
> >
> >" It must also send an Hello Packet in reply to an
> >            Hello Packet received from any eligible neighbor (other than
> >            the current Designated Router and Backup Designated Router)"
> >
> >how can a non eligible router get a hello from a eligibe router if the
> >eligible router is not going to send(tatz what the first argument says)
> >
> >
> Srini,
> In the NBMA case (which is described in section 9.5.1), a non-eligible
> router
> needs to reply to any eligible neighbor since it may not know the current
> DR/BDR. There are a number of scenarios where this can happen including
> the case where the non-eligible neighbor first comes up and receives a
> hello poll
> from the current DR/DBR. The non-eligible neighbor needs to establish
> bi-directional connectivity with the potential DR/BDR in order for its
> local DR/BDR election to work.
>
> Hope this helps,
> Acee
>
>
> >Am i missing something here??
> >
> >thanks
> >Srini
> >
> >
> >
> DISCLAIMER
> This message and any attachment(s) contained here are information that is
confidential, proprietary to HCL Technologies
> and its customers. Contents may be privileged or otherwise protected by
law. The information is solely intended for the
> individual or the entity it is addressed to. If you are not the intended
recipient of this message, you are not authorized to
> read, forward, print, retain, copy or disseminate this message or any part
of it. If you have received this e-mail in error,
> please notify the sender immediately by return e-mail and delete it from
your computer


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May  9 17:17:03 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12531
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 May 2005 17:17:03 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0103D1DC@cherry.ease.lsoft.com>; Mon, 9 May 2005 17:17:03 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          69999696 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 May 2005 17:16:51 -0400
Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Mon, 9 May 2005 17:16:51 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com
          with ESMTP; 09 May 2005 17:31:22 -0400
X-IronPort-AV: i="3.92,170,1112587200"; d="scan'208"; a="48479499:sNHT29511576"
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 j49LG8ea024670 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 9 May 2005
          17:16:49 -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); Mon,
          9 May 2005 17:16:24 -0400
Received: from [10.82.216.165] ([10.82.216.165]) by xfe-rtp-201.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 17:16:23 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <68C9DA8F50019B4E8622C53811BEE1D602DA7D54@kavithai.ctd.hcltech.com>
            <0be001c554b8$41353990$a328fb80@Kishorepc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 May 2005 21:16:23.0455 (UTC)
                       FILETIME=[5A4E5AF0:01C554DC]
Message-ID:  <427FD326.9020404@cisco.com>
Date:         Mon, 9 May 2005 17:16:22 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: Doubt on sending hello packets on NBMA networks
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <0be001c554b8$41353990$a328fb80@Kishorepc>
Precedence: list
Content-Transfer-Encoding: 7bit

Kishore Rao wrote:

>Possible scenarios 
>  
>
>- Timing difference between dynamically changing the eligibility
>configuration/setting interface priority Vs sending of a Hello.
>  
>
Yup - You don't really even need timing differences - any event which 
causes a new DR/BDR to
be elected would cause the new DR/BDR to start polling non-eligible 
neighbors that
hadn't heard from them before.

>- Mismatch in configuration between interface priority of a router and its
>eligibility configuration on other routers.
>  
>
Yes.

>Kishore
>
>
>  
>
>>hi Acee,
>>
>>yeah i got it. but just for the sake of curiosity. can you give me
>>some more scenarious where this can happen?
>>
>>Thanks
>>Srini
>>
>>-----Original Message-----
>>From: Acee Lindem [mailto:acee@CISCO.COM]
>>Sent: Monday, May 09, 2005 6:40 PM
>>To: OSPF@PEACH.EASE.LSOFT.COM
>>Subject: Re: Doubt on sending hello packets on NBMA networks
>>
>>
>>Srinivasa J Ragavan wrote:
>>
>>    
>>
>>>hi All,
>>>
>>>I am a newbie to OSPF.
>>>can anyone help me out.
>>>this is with reference to the rfc 2328 sec. 9.5.1 whcih says
>>>"  If the router is eligible to become Designated Router, it
>>>           must periodically send Hello Packets to all neighbors that
>>>           are also eligible."
>>>
>>>but immediately in the next paragraph it says
>>>
>>>" It must also send an Hello Packet in reply to an
>>>           Hello Packet received from any eligible neighbor (other than
>>>           the current Designated Router and Backup Designated Router)"
>>>
>>>how can a non eligible router get a hello from a eligibe router if the
>>>eligible router is not going to send(tatz what the first argument says)
>>>
>>>
>>>      
>>>
>>Srini,
>>In the NBMA case (which is described in section 9.5.1), a non-eligible
>>router
>>needs to reply to any eligible neighbor since it may not know the current
>>DR/BDR. There are a number of scenarios where this can happen including
>>the case where the non-eligible neighbor first comes up and receives a
>>hello poll
>>from the current DR/DBR. The non-eligible neighbor needs to establish
>>bi-directional connectivity with the potential DR/BDR in order for its
>>local DR/BDR election to work.
>>
>>Hope this helps,
>>Acee
>>
>>
>>    
>>
>>>Am i missing something here??
>>>
>>>thanks
>>>Srini
>>>
>>>
>>>
>>>      
>>>
>>DISCLAIMER
>>This message and any attachment(s) contained here are information that is
>>    
>>
>confidential, proprietary to HCL Technologies
>  
>
>>and its customers. Contents may be privileged or otherwise protected by
>>    
>>
>law. The information is solely intended for the
>  
>
>>individual or the entity it is addressed to. If you are not the intended
>>    
>>
>recipient of this message, you are not authorized to
>  
>
>>read, forward, print, retain, copy or disseminate this message or any part
>>    
>>
>of it. If you have received this e-mail in error,
>  
>
>>please notify the sender immediately by return e-mail and delete it from
>>    
>>
>your computer
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May 10 00:59:57 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18740
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 May 2005 00:59:57 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0103DC07@cherry.ease.lsoft.com>; Tue, 10 May 2005 0:59:58 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          70034279 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 May 2005 00:59:44
          -0400
Received: from 203.197.124.190 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Tue, 10 May 2005 00:59:40 -0400
Received: from DEBOPAMLAPTOP ([192.168.10.222]) by alumnux.com (8.9.3/8.9.3)
          with SMTP id KAA22152 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 10 May
          2005 10:45:54 +0530
References: <01ce01c55462$4b2b1510$de0aa8c0@DEBOPAMLAPTOP> 
            <427F559D.308@cisco.com>
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Message-ID:  <006601c5551c$fa8ff1f0$de0aa8c0@DEBOPAMLAPTOP>
Date:         Tue, 10 May 2005 10:28:59 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Debopam Bandyopadhyay <debopam@ALUMNUX.COM>
Organization: Alumnus Software Ltd
Subject: Re: Reestablish adjacencies after Graceful-Restart
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Thanks a lot for the help, Acee. It has cleared a major chunk of my design
requirements.
Finally, I have one question related to a hypothetical case (which may be
required for interoperability).

I will go back to the previous example:

            X ----- lan ----- Y

In the topology, we have two routers, X and Y; and Y happens to be the DR in
the network segment.

Now Router X restarts. After 'T' seconds, Router X becomes fully adjacent
with Router Y.  'T is very much less than X's Grace Period.
Let's say, X is unable to trace its pre-restart Router-LSA in its database
(because Y had not sent it during the DD-exchange). So my question is:
1> Would X now exit Graceful-restart at this point, or
2> Would X wait for its pre-restart Router-LSA to be received from Y (in the
form of LS-Updates), until grace period expires; or
3> Would it be implementation dependent?

Thanks,
Debopam

----- Original Message ----- 
From: "Acee Lindem" <acee@CISCO.COM>
To: <OSPF@PEACH.EASE.LSOFT.COM>
Sent: Monday, May 09, 2005 5:50 PM
Subject: Re: Reestablish adjacencies after Graceful-Restart


Debopam Bandyopadhyay wrote:

>This question is a bit long, backdated and maybe, queer. But it is a bit
critical for me.
>It is regarding RFC 3623 (Graceful OSPF Restart), Section 2.2. "When to
Exit Graceful Restart", Point 1 "Router X has reestablished all its
adjacencies".
>
>I am trying to identify the corresponding event from RFC 2328 for Router X.
Is it one of the following:
>a> Upon installation of an LSA in the database [RFC2328, Sec 13.2] [and
thereby tracing the database for all the relevant LSAs which indicate the
previous adjacencies],
>     or
>b> State of neighbor Y changing to Full; [and thereby tracing the database
...]
>     or
>c> Implementation specific
>
>Let me explain this with a simplified example:
>
>            X ----- lan ----- Y
>
>In the topology, we have two routers, X and Y; and Y happens to be the DR
in the network segment.
>
>Now Router X restarts. After 'T' seconds, Router X becomes fully adjacent
with Router Y.
>
>At this point, three scenarios are possible:
>1> X had received all the relevant LSAs (i.e. router-LSAs of X, Y and
Network-LSA of Y) BEFORE becoming fully adjacent with Y.
>     Hence, the graceful-restart exit event has already been fired BEFORE X
became fully adjacent with Y.
>2> X had received all the relevant LSAs BEFORE becoming fully adjacent with
Y;
>     but graceful-restart exit event gets fired EXACTLY when X became fully
adjacent with Y.
>3> X had completed receiving all the relevant LSAs AFTER becoming fully
adjacent with Y;
>     Hence, the graceful-restart exit event gets fired sometime AFTER X
became fully adjacent with Y.
>
>
Hi Depopam,

As stated in RFC 3623 section 2.2, a restarting router uses its
pre-restart router
LSA to determine whether or not it has re-established all its
pre-restart adjacencies.
Adjacency formation implies database synchronization and reception of
all LSAs within
the flooding domain of the router with whom the adjacency is being
formed. Hence,
 #2 above is the only scenario which makes sense.

Hope this helps,
Acee


>Thanks,
>Debopam
>
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May 10 03:23:24 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23517
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 May 2005 03:23:23 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0103DD14@cherry.ease.lsoft.com>; Tue, 10 May 2005 3:23:20 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          70039993 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 May 2005 03:23:19
          -0400
Received: from 207.17.137.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Tue, 10 May 2005 03:13:19 -0400
Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by
          kremlin.juniper.net with ESMTP; 10 May 2005 00:13:18 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.92,170,1112598000"; d="scan'208"; a="295980897:sNHT20092912"
Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with
          Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 00:13:18 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Thread-Topic: Indication LSA impact
Thread-Index: AcVVHSLwexLJX/GyQKeKdmv74xhbsgAA5QCw
X-OriginalArrivalTime: 10 May 2005 07:13:18.0399 (UTC)
                       FILETIME=[BDAD1CF0:01C5552F]
Message-ID:  <062B922B6EC55149B5A267ECE78E5D4406A5C8A9@photon.jnpr.net>
Date:         Tue, 10 May 2005 00:13:17 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Kalyan Bade <kalyan@JUNIPER.NET>
Subject: Indication LSA impact
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

Folks,

I was going through rfc 1793 (demand circuit extensions for OSPF) and
have a question regarding the generation of indication LSAs and its
impact on the LSAs created/flooded.

Suppose if we have three routers as shown in the setup below.

R0 ------ R1 ------ R2
   Area X    Area Y=20

Say if R0 is a DC uncapable router, the area X is considered DC
uncapable. Which means that none of the routers in area X can generate
an area scope/AS scope LSAs with DoNotAge bit set.=20

And as per the spec, an indication LSA is generated in area Y and this
makes the area Y also as DC uncapable. So, my question is what is the
rationale behind making area Y as DC uncapable? I understand that any
router in area Y shouldn't generate an AS scope LSA with DoNotAge bit
set, but why should that hold to area scope LSA's?

Thanks,
Kalyan.=20


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May 10 07:08:10 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13223
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 May 2005 07:08:10 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0103E267@cherry.ease.lsoft.com>; Tue, 10 May 2005 7:08:10 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          70081911 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 May 2005 07:08:08
          -0400
Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Tue, 10 May 2005 07:08:08 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com
          with ESMTP; 10 May 2005 07:22:45 -0400
X-IronPort-AV: i="3.92,171,1112587200"; d="scan'208"; a="48556683:sNHT28803240"
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 j4AB86nI029455 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 10 May 2005
          07:08:06 -0400 (EDT)
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); Tue,
          10 May 2005 07:08:05 -0400
Received: from [10.82.216.165] ([10.82.216.165]) by xfe-rtp-201.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 07:08:11 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <01ce01c55462$4b2b1510$de0aa8c0@DEBOPAMLAPTOP>            
            <427F559D.308@cisco.com>
            <006601c5551c$fa8ff1f0$de0aa8c0@DEBOPAMLAPTOP>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 May 2005 11:08:11.0994 (UTC)
                       FILETIME=[8E1D0BA0:01C55550]
Message-ID:  <42809615.6090707@cisco.com>
Date:         Tue, 10 May 2005 07:08:05 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: Reestablish adjacencies after Graceful-Restart
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <006601c5551c$fa8ff1f0$de0aa8c0@DEBOPAMLAPTOP>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Debopam,

Debopam Bandyopadhyay wrote:

>Thanks a lot for the help, Acee. It has cleared a major chunk of my design
>requirements.
>Finally, I have one question related to a hypothetical case (which may be
>required for interoperability).
>
>I will go back to the previous example:
>
>            X ----- lan ----- Y
>
>In the topology, we have two routers, X and Y; and Y happens to be the DR in
>the network segment.
>
>Now Router X restarts. After 'T' seconds, Router X becomes fully adjacent
>with Router Y.  'T is very much less than X's Grace Period.
>Let's say, X is unable to trace its pre-restart Router-LSA in its database
>(because Y had not sent it during the DD-exchange). So my question is:
>1> Would X now exit Graceful-restart at this point, or
>2> Would X wait for its pre-restart Router-LSA to be received from Y (in the
>form of LS-Updates), until grace period expires; or
>3> Would it be implementation dependent?
>  
>
While not every scenario is not explicitly documented,  not having a 
pre-restart LSAs and
a full neighbor would be fall into the category of an inconsistent LSA. 
Hence, you should
terminate graceful restart as specified by 2) in section 2.2 of RFC 
3623. Keep in mind,
that a full adjacency implies a complete database exchange.

Hope this helps,
Acee


>Thanks,
>Debopam
>
>----- Original Message ----- 
>From: "Acee Lindem" <acee@CISCO.COM>
>To: <OSPF@PEACH.EASE.LSOFT.COM>
>Sent: Monday, May 09, 2005 5:50 PM
>Subject: Re: Reestablish adjacencies after Graceful-Restart
>
>
>Debopam Bandyopadhyay wrote:
>
>  
>
>>This question is a bit long, backdated and maybe, queer. But it is a bit
>>    
>>
>critical for me.
>  
>
>>It is regarding RFC 3623 (Graceful OSPF Restart), Section 2.2. "When to
>>    
>>
>Exit Graceful Restart", Point 1 "Router X has reestablished all its
>adjacencies".
>  
>
>>I am trying to identify the corresponding event from RFC 2328 for Router X.
>>    
>>
>Is it one of the following:
>  
>
>>a> Upon installation of an LSA in the database [RFC2328, Sec 13.2] [and
>>    
>>
>thereby tracing the database for all the relevant LSAs which indicate the
>previous adjacencies],
>  
>
>>    or
>>b> State of neighbor Y changing to Full; [and thereby tracing the database
>>    
>>
>...]
>  
>
>>    or
>>c> Implementation specific
>>
>>Let me explain this with a simplified example:
>>
>>           X ----- lan ----- Y
>>
>>In the topology, we have two routers, X and Y; and Y happens to be the DR
>>    
>>
>in the network segment.
>  
>
>>Now Router X restarts. After 'T' seconds, Router X becomes fully adjacent
>>    
>>
>with Router Y.
>  
>
>>At this point, three scenarios are possible:
>>1> X had received all the relevant LSAs (i.e. router-LSAs of X, Y and
>>    
>>
>Network-LSA of Y) BEFORE becoming fully adjacent with Y.
>  
>
>>    Hence, the graceful-restart exit event has already been fired BEFORE X
>>    
>>
>became fully adjacent with Y.
>  
>
>>2> X had received all the relevant LSAs BEFORE becoming fully adjacent with
>>    
>>
>Y;
>  
>
>>    but graceful-restart exit event gets fired EXACTLY when X became fully
>>    
>>
>adjacent with Y.
>  
>
>>3> X had completed receiving all the relevant LSAs AFTER becoming fully
>>    
>>
>adjacent with Y;
>  
>
>>    Hence, the graceful-restart exit event gets fired sometime AFTER X
>>    
>>
>became fully adjacent with Y.
>  
>
>>    
>>
>Hi Depopam,
>
>As stated in RFC 3623 section 2.2, a restarting router uses its
>pre-restart router
>LSA to determine whether or not it has re-established all its
>pre-restart adjacencies.
>Adjacency formation implies database synchronization and reception of
>all LSAs within
>the flooding domain of the router with whom the adjacency is being
>formed. Hence,
> #2 above is the only scenario which makes sense.
>
>Hope this helps,
>Acee
>
>
>  
>
>>Thanks,
>>Debopam
>>
>>
>>    
>>
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May 10 07:16:13 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13885
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 May 2005 07:16:13 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0103E1DF@cherry.ease.lsoft.com>; Tue, 10 May 2005 7:16:14 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          70082601 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 May 2005 07:16:13
          -0400
Received: from 203.197.124.190 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Tue, 10 May 2005 07:16:12 -0400
Received: from DEBOPAMLAPTOP ([192.168.10.222]) by alumnux.com (8.9.3/8.9.3)
          with SMTP id RAA28208 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 10 May
          2005 17:02:51 +0530
References: <01ce01c55462$4b2b1510$de0aa8c0@DEBOPAMLAPTOP>                     
            <427F559D.308@cisco.com>           
            <006601c5551c$fa8ff1f0$de0aa8c0@DEBOPAMLAPTOP> 
            <42809615.6090707@cisco.com>
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Message-ID:  <00bb01c55551$a8419770$de0aa8c0@DEBOPAMLAPTOP>
Date:         Tue, 10 May 2005 16:46:00 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Debopam Bandyopadhyay <debopam@ALUMNUX.COM>
Organization: Alumnus Software Ltd
Subject: Re: Reestablish adjacencies after Graceful-Restart
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Acee,

Thanks a lot for the help.

Regards,
Debopam

>Hi Debopam,
>
>Debopam Bandyopadhyay wrote:
>
>>Thanks a lot for the help, Acee. It has cleared a major chunk of my design
>>requirements.
>>Finally, I have one question related to a hypothetical case (which may be
>>required for interoperability).
>>
>>I will go back to the previous example:
>>
>>            X ----- lan ----- Y
>>
>>In the topology, we have two routers, X and Y; and Y happens to be the DR
in
>>the network segment.
>>
>>Now Router X restarts. After 'T' seconds, Router X becomes fully adjacent
>>with Router Y.  'T is very much less than X's Grace Period.
>>Let's say, X is unable to trace its pre-restart Router-LSA in its database
>>(because Y had not sent it during the DD-exchange). So my question is:
>>1> Would X now exit Graceful-restart at this point, or
>>2> Would X wait for its pre-restart Router-LSA to be received from Y (in
the
>>form of LS-Updates), until grace period expires; or
>>3> Would it be implementation dependent?
>>
>>
>While not every scenario is not explicitly documented,  not having a
>pre-restart LSAs and
>a full neighbor would be fall into the category of an inconsistent LSA.
>Hence, you should
>terminate graceful restart as specified by 2) in section 2.2 of RFC
>3623. Keep in mind,
>that a full adjacency implies a complete database exchange.
>
>Hope this helps,
>Acee
>
>
>>Thanks,
>>Debopam
>>
>>----- Original Message ----- 
>>From: "Acee Lindem" <acee@CISCO.COM>
>>To: <OSPF@PEACH.EASE.LSOFT.COM>
>>Sent: Monday, May 09, 2005 5:50 PM
>>Subject: Re: Reestablish adjacencies after Graceful-Restart
>>
>>
>>Debopam Bandyopadhyay wrote:
>>
>>
>>
>>>This question is a bit long, backdated and maybe, queer. But it is a bit
>>>
>>>
>>critical for me.
>>
>>
>>>It is regarding RFC 3623 (Graceful OSPF Restart), Section 2.2. "When to
>>>
>>>
>>Exit Graceful Restart", Point 1 "Router X has reestablished all its
>>adjacencies".
>>
>>
>>>I am trying to identify the corresponding event from RFC 2328 for Router
X.
>>>
>>>
>>Is it one of the following:
>>
>>
>>>a> Upon installation of an LSA in the database [RFC2328, Sec 13.2] [and
>>>
>>>
>>thereby tracing the database for all the relevant LSAs which indicate the
>>previous adjacencies],
>>
>>
>>>    or
>>>b> State of neighbor Y changing to Full; [and thereby tracing the
database
>>>
>>>
>>...]
>>
>>
>>>    or
>>>c> Implementation specific
>>>
>>>Let me explain this with a simplified example:
>>>
>>>           X ----- lan ----- Y
>>>
>>>In the topology, we have two routers, X and Y; and Y happens to be the DR
>>>
>>>
>>in the network segment.
>>
>>
>>>Now Router X restarts. After 'T' seconds, Router X becomes fully adjacent
>>>
>>>
>>with Router Y.
>>
>>
>>>At this point, three scenarios are possible:
>>>1> X had received all the relevant LSAs (i.e. router-LSAs of X, Y and
>>>
>>>
>>Network-LSA of Y) BEFORE becoming fully adjacent with Y.
>>
>>
>>>    Hence, the graceful-restart exit event has already been fired BEFORE
X
>>>
>>>
>>became fully adjacent with Y.
>>
>>
>>>2> X had received all the relevant LSAs BEFORE becoming fully adjacent
with
>>>
>>>
>>Y;
>>
>>
>>>    but graceful-restart exit event gets fired EXACTLY when X became
fully
>>>
>>>
>>adjacent with Y.
>>
>>
>>>3> X had completed receiving all the relevant LSAs AFTER becoming fully
>>>
>>>
>>adjacent with Y;
>>
>>
>>>    Hence, the graceful-restart exit event gets fired sometime AFTER X
>>>
>>>
>>became fully adjacent with Y.
>>
>>
>>>
>>>
>>Hi Depopam,
>>
>>As stated in RFC 3623 section 2.2, a restarting router uses its
>>pre-restart router
>>LSA to determine whether or not it has re-established all its
>>pre-restart adjacencies.
>>Adjacency formation implies database synchronization and reception of
>>all LSAs within
>>the flooding domain of the router with whom the adjacency is being
>>formed. Hence,
>> #2 above is the only scenario which makes sense.
>>
>>Hope this helps,
>>Acee
>>
>>
>>
>>
>>>Thanks,
>>>Debopam
>>>
>>>
>>>
>>>
>>
>>
>>


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May 10 08:15:39 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19995
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 May 2005 08:15:39 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0103E4DF@cherry.ease.lsoft.com>; Tue, 10 May 2005 8:11:24 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          70088627 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 May 2005 08:11:22
          -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Tue, 10 May 2005 08:11:19 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com
          with ESMTP; 10 May 2005 08:11:20 -0400
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 j4ACB0nU011028 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 10 May 2005
          08:11:17 -0400 (EDT)
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,
          10 May 2005 08:11:09 -0400
Received: from [10.82.216.165] ([10.82.216.165]) by xfe-rtp-202.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 08:11:08 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <062B922B6EC55149B5A267ECE78E5D4406A5C8A9@photon.jnpr.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 May 2005 12:11:08.0863 (UTC)
                       FILETIME=[594D84F0:01C55559]
Message-ID:  <4280A4DC.2090001@cisco.com>
Date:         Tue, 10 May 2005 08:11:08 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: Indication LSA impact
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <062B922B6EC55149B5A267ECE78E5D4406A5C8A9@photon.jnpr.net>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Kaylan,

Kalyan Bade wrote:

>Folks,
>
>I was going through rfc 1793 (demand circuit extensions for OSPF) and
>have a question regarding the generation of indication LSAs and its
>impact on the LSAs created/flooded.
>
>Suppose if we have three routers as shown in the setup below.
>
>R0 ------ R1 ------ R2
>   Area X    Area Y 
>
>Say if R0 is a DC uncapable router, the area X is considered DC
>uncapable. Which means that none of the routers in area X can generate
>an area scope/AS scope LSAs with DoNotAge bit set. 
>
>And as per the spec, an indication LSA is generated in area Y and this
>makes the area Y also as DC uncapable. So, my question is what is the
>rationale behind making area Y as DC uncapable? I understand that any
>router in area Y shouldn't generate an AS scope LSA with DoNotAge bit
>set, but why should that hold to area scope LSA's?
>  
>

I don't recall all the discussions surrounding this draft. However, I 
suspect it was a design
choice to simplify the backward compatibility mechanism. On the surface, 
I see no
reason why what you are suggesting could not have been done with some 
additional
protocol specification and state.

Thanks,
Acee

>Thanks,
>Kalyan. 
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May 10 15:24:50 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05534
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 May 2005 15:24:50 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0103F1AC@cherry.ease.lsoft.com>; Tue, 10 May 2005 15:24:49 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          70137164 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 May 2005 15:24:48
          -0400
Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Tue, 10 May 2005 15:24:48 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com
          with ESMTP; 10 May 2005 15:39:28 -0400
X-IronPort-AV: i="3.92,172,1112587200"; d="scan'208"; a="48657805:sNHT187713572"
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 j4AJObnQ017380 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 10 May 2005
          15:24:45 -0400 (EDT)
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,
          10 May 2005 15:24:40 -0400
Received: from [64.102.199.144] ([64.102.199.144]) by
          xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue,
          10 May 2005 15:24:41 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <42778DFC.4060107@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 May 2005 19:24:41.0077 (UTC)
                       FILETIME=[E9CA6250:01C55595]
Message-ID:  <42810A78.9060404@cisco.com>
Date:         Tue, 10 May 2005 15:24:40 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <42778DFC.4060107@cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Any other views on this?

Acee Lindem wrote:

> In the evolution of the OSPFv2 protocol specification
> (RFC 1247->RFC 1583 -> RFC 2178 -> RFC 2328) numerous
> bugs were fixed and some protocol behaviors were altered. Examples
> include the metric cost for area ranges and the selection of the
> ASBR for AS external route computation.
>
> In the context of documenting the OSPFv3 NSSA differences I've
> looked again at section 2.10 and I really think the idea of not flooding
> unknown LSA types with the U-bit set to 1 is broken. I think it breaks
> the whole idea of being able to introduce new LSA types in a backward
> compatible fashion. Furthermore, it won't stop the leakage of these
> unknown LSAs when some routers understand them and others do not -
> it all depends on whether you have a spanning tree of routers that
> understand them. Since the LSAs in question are area scoped or link
> scoped, it implies that at least one router (the originator) 
> understands the
> new type and you will have a mixture. IMHO, this is broken. I've had
> some discussions with others who agree. At this juncture,
> we have 3 alternatives:
>
>    1) Remove the restriction for that unknown LSAs with the U-bit
>        set to 0 for stub areas.
>    2) Extend the broken restriction to NSSAs in the update.
>    3) Limit the damage to stub areas and only restrict AS scoped LSAs
>        from NSSAs.
>
> Of course, I'd vote for #1 or I wouldn't be sending this E-mail.
>
> Thanks,
> Acee
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri May 13 15:59:40 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25392
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 May 2005 15:59:37 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.01045AF1@cherry.ease.lsoft.com>; Fri, 13 May 2005 15:59:35 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          70554782 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 May 2005 15:59:33
          -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Fri, 13 May 2005 15:49:33 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id PAA22072; Fri, 13 May 2005 15:49:30
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200505131949.PAA22072@ietf.org>
Date:         Fri, 13 May 2005 15:49:30 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ospf-ospfv3-mib-09.txt
Comments: To: i-d-announce@ietf.org
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.

	Title		: Management Information Base for OSPFv3
	Author(s)	: D. Joyal, V. Manral
	Filename	: draft-ietf-ospf-ospfv3-mib-09.txt
	Pages		: 67
	Date		: 2005-5-13
	
This memo defines a portion of the Management Information Base (MIB) 
   for use with network management protocols in IPv6-based internets. 
   In particular, it defines objects for managing the Open Shortest Path 
   First Routing Protocol for IPv6. 
    
   Please send comments to ospf@peach.ease.lsoft.com.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-mib-09.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ospf-ospfv3-mib-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ospf-ospfv3-mib-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2005-5-13160018.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-ospfv3-mib-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ospf-ospfv3-mib-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2005-5-13160018.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@PEACH.EASE.LSOFT.COM  Sat May 14 11:11:51 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10204
	for <ospf-archive@LISTS.IETF.ORG>; Sat, 14 May 2005 11:11:51 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.01047059@cherry.ease.lsoft.com>; Sat, 14 May 2005 11:11:49 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          70649500 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 14 May 2005 11:11:48
          -0400
Received: from 64.233.184.199 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Sat, 14 May 2005 11:11:48 -0400
Received: by wproxy.gmail.com with SMTP id 71so1384364wri for
          <OSPF@peach.ease.lsoft.com>; Sat, 14 May 2005 08:11:48 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
                     h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
                     b=H/3XR9akeFHE2cN+6pI0jY4zYtHztetnkajgwxRd2DL8LyrTBLBchLdkb+pMD8WGmTv3s0nZRWZ0+1avKz7FntWcjs4ciaSRuRyhNcx09xEQIMX0CIHcJKIGu2jb3GEge/Cmk+Pq+2jhojZ8Gh4lt3Zrd7ol44LFnxLZwR43KOA=
Received: by 10.54.26.2 with SMTP id 2mr2466655wrz; Sat, 14 May 2005 08:10:58
          -0700 (PDT)
Received: by 10.54.13.19 with HTTP; Sat, 14 May 2005 08:10:58 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-ID:  <c4bf85a2050514081066c7ef0a@mail.gmail.com>
Date:         Sat, 14 May 2005 20:40:58 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Santosh Esale <s.esale@GMAIL.COM>
Subject: Type-7 to Type-5 translation issue
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

Hi guys,
           Mine topology is as below-

R1----Area 1 ------R2--------Backbone Area------R3

Initially Area 1 was type-5 capabale area and i was redistributing RIP
routes into area 1 on R1, so R2 and R3 have type-5 LSAs for all the
RIP routes.Now i changed
Area 1 to NSSA , So R1 is now orginating type-7 LSAs for all the RIP
routes into area 1 with P-bit set.

Now mine question is should R2 -

 1.     Prefer type 7 LSA over type-5 .
Convert type-7 LSA into type-5 LSA  and flood into backbone, which
aleardy have  type-5 LSAs for the same netwroks earlier orginated by
R1(not yet flushed as it will remain in backbone for MAX AGE)
(According to RFC 3101. section 2.5 stp 6 (e) ).

Disadvantage: The LSP database size will be doubled till MAX AGE time.
Advantage : simplicity

2. Prefer type-5 over type-7 .
Use type-5 LSA for calculating external routes till type-5 LSAs
advertised by R1 exists in backbone(MAX Age) , and once type is
flushed because of MAX age , USE type -7 now to calculate external
routes , and translate at this point from type-7 to type-5(RFC 1587
3.5 step 5)

Advantage : LSP database size is small.
Disadvantage: bit complex,but not much.

3. or its Implementations Specific.

Thanks in Advance


--=20
Santosh Esale

Member - Technical Staff

Riverstone Networks India Pvt. Ltd.

Email: sesale@riverstonenet.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May 16 06:06:08 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19078
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 May 2005 06:06:07 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0104963E@cherry.ease.lsoft.com>; Mon, 16 May 2005 6:06:07 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          70865059 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 May 2005 06:05:59
          -0400
Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Mon, 16 May 2005 06:03:28 -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 <0IGK0058JUT5CU@szxga02-in.huawei.com> for
          OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 May 2005 18:07:53 +0800 (CST)
Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet
          Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id
          <0IGK0042FUT1Y5@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 16 May 2005 18:07:53 +0800 (CST)
Received: from dell60 ([10.18.4.202]) by szxml02-in.huawei.com (iPlanet
          Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id
          <0IGK00LOGUSXUV@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 16 May 2005 18:07:46 +0800 (CST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook, Build 10.0.4024
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Message-ID:  <000001c559fe$848ac7a0$ca04120a@china.huawei.com>
Date:         Mon, 16 May 2005 15:33:31 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: sujay <sujayg@HUAWEI.COM>
Subject: Re: Type-7 to Type-5 translation issue
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <c4bf85a2050514081066c7ef0a@mail.gmail.com>
Precedence: list
Content-Transfer-Encoding: 7BIT

I guess the point is whether to defer the Type-7 to 5 conversion until
Type 5 expires, to save database size.

In case if the Type-7 carries a forwarding address, it should be
converted into the correct Type-5 without delay.

Best regds,
~Sujay

-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of
Santosh Esale
Sent: Saturday, May 14, 2005 8:41 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Type-7 to Type-5 translation issue


Hi guys,
           Mine topology is as below-

R1----Area 1 ------R2--------Backbone Area------R3

Initially Area 1 was type-5 capabale area and i was redistributing RIP
routes into area 1 on R1, so R2 and R3 have type-5 LSAs for all the RIP
routes.Now i changed Area 1 to NSSA , So R1 is now orginating type-7
LSAs for all the RIP routes into area 1 with P-bit set.

Now mine question is should R2 -

 1.     Prefer type 7 LSA over type-5 .
Convert type-7 LSA into type-5 LSA  and flood into backbone, which
aleardy have  type-5 LSAs for the same netwroks earlier orginated by
R1(not yet flushed as it will remain in backbone for MAX AGE) (According
to RFC 3101. section 2.5 stp 6 (e) ).

Disadvantage: The LSP database size will be doubled till MAX AGE time.
Advantage : simplicity

2. Prefer type-5 over type-7 .
Use type-5 LSA for calculating external routes till type-5 LSAs
advertised by R1 exists in backbone(MAX Age) , and once type is flushed
because of MAX age , USE type -7 now to calculate external routes , and
translate at this point from type-7 to type-5(RFC 1587 3.5 step 5)

Advantage : LSP database size is small.
Disadvantage: bit complex,but not much.

3. or its Implementations Specific.

Thanks in Advance


-- 
Santosh Esale

Member - Technical Staff

Riverstone Networks India Pvt. Ltd.

Email: sesale@riverstonenet.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May 16 06:24:41 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20666
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 May 2005 06:24:38 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010496D0@cherry.ease.lsoft.com>; Mon, 16 May 2005 6:24:40 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          70887407 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 May 2005 06:24:39
          -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Mon, 16 May 2005 06:24:39 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com
          with ESMTP; 16 May 2005 06:24:39 -0400
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 j4GAOanI010743 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 16 May 2005
          06:24:36 -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); Mon,
          16 May 2005 06:24:36 -0400
Received: from [10.82.225.188] ([10.82.225.188]) by xfe-rtp-201.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 06:24:36 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <c4bf85a2050514081066c7ef0a@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 May 2005 10:24:36.0141 (UTC)
                       FILETIME=[756C0DD0:01C55A01]
Message-ID:  <428874E3.1020408@cisco.com>
Date:         Mon, 16 May 2005 06:24:35 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: Type-7 to Type-5 translation issue
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <c4bf85a2050514081066c7ef0a@mail.gmail.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Santosh,

Whether or not R1 purges its AS-external-LSAs prior to area 1 being
coverted from a regular area to an NSSA is implementation specific. 
However, the
timing of the conversion may be such that R1 is unable to purge them 
from the
OSPF routing domain. In all cases, R1 should immediately originate 
NSSA-LSAs
(type-7s) for redistributed routes. When R2 computes its external/NSSA 
routes
it should not use R1's AS-external-LSA since its path to the ASBR is not 
through
a regular area (see section 2.5 in RFC 3101).

Hope this helps,
Acee

Santosh Esale wrote:

>Hi guys,
>           Mine topology is as below-
>
>R1----Area 1 ------R2--------Backbone Area------R3
>
>Initially Area 1 was type-5 capabale area and i was redistributing RIP
>routes into area 1 on R1, so R2 and R3 have type-5 LSAs for all the
>RIP routes.Now i changed
>Area 1 to NSSA , So R1 is now orginating type-7 LSAs for all the RIP
>routes into area 1 with P-bit set.
>
>Now mine question is should R2 -
>
> 1.     Prefer type 7 LSA over type-5 .
>Convert type-7 LSA into type-5 LSA  and flood into backbone, which
>aleardy have  type-5 LSAs for the same netwroks earlier orginated by
>R1(not yet flushed as it will remain in backbone for MAX AGE)
>(According to RFC 3101. section 2.5 stp 6 (e) ).
>
>Disadvantage: The LSP database size will be doubled till MAX AGE time.
>Advantage : simplicity
>
>2. Prefer type-5 over type-7 .
>Use type-5 LSA for calculating external routes till type-5 LSAs
>advertised by R1 exists in backbone(MAX Age) , and once type is
>flushed because of MAX age , USE type -7 now to calculate external
>routes , and translate at this point from type-7 to type-5(RFC 1587
>3.5 step 5)
>
>Advantage : LSP database size is small.
>Disadvantage: bit complex,but not much.
>
>3. or its Implementations Specific.
>
>Thanks in Advance
>
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May 16 06:43:24 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23099
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 May 2005 06:43:23 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010495D4@cherry.ease.lsoft.com>; Mon, 16 May 2005 6:43:25 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          70891796 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 May 2005 06:43:24
          -0400
Received: from 64.233.184.192 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Mon, 16 May 2005 06:43:24 -0400
Received: by wproxy.gmail.com with SMTP id 71so1841243wri for
          <OSPF@peach.ease.lsoft.com>; Mon, 16 May 2005 03:43:23 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
                     h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
                     b=dL1aD9GdwzArK1w72TwxezTcj74yX4CJ1upXp/YHvcKVSyUecFW/zo+krxm1eajhZZz4u9zmPK68y9SKWnzPKiwGQ11uxm92YMpOhdN+RTFOTcoSLnqcjwx7osA2vl0wM0D0L1gJduImMDPYTdHw43HimYrL746qsjTstnMqWew=
Received: by 10.54.24.48 with SMTP id 48mr3610588wrx; Mon, 16 May 2005 03:43:23
          -0700 (PDT)
Received: by 10.54.13.19 with HTTP; Mon, 16 May 2005 03:43:23 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <c4bf85a2050514081066c7ef0a@mail.gmail.com>
            <428874E3.1020408@cisco.com>
Message-ID:  <c4bf85a20505160343ab75063@mail.gmail.com>
Date:         Mon, 16 May 2005 16:13:23 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Santosh Esale <s.esale@GMAIL.COM>
Subject: Re: Type-7 to Type-5 translation issue
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <428874E3.1020408@cisco.com>
Precedence: list
Content-Transfer-Encoding: quoted-printable

Hi Acee,
            U mean i should check whether the ASBR path is via type-5
capable area, and if its not USE NSSA external lsa for calculation and
do the type-7 to type-5 conversion immediately.

I do agree with this...but we are doubling the LSP database size, how
to slove it?

Thanks
Santosh

On 5/16/05, Acee Lindem <acee@cisco.com> wrote:
> Hi Santosh,
>=20
> Whether or not R1 purges its AS-external-LSAs prior to area 1 being
> coverted from a regular area to an NSSA is implementation specific.
> However, the
> timing of the conversion may be such that R1 is unable to purge them
> from the
> OSPF routing domain. In all cases, R1 should immediately originate
> NSSA-LSAs
> (type-7s) for redistributed routes. When R2 computes its external/NSSA
> routes
> it should not use R1's AS-external-LSA since its path to the ASBR is not
> through
> a regular area (see section 2.5 in RFC 3101).
>=20
> Hope this helps,
> Acee
>=20
> Santosh Esale wrote:
>=20
> >Hi guys,
> >           Mine topology is as below-
> >
> >R1----Area 1 ------R2--------Backbone Area------R3
> >
> >Initially Area 1 was type-5 capabale area and i was redistributing RIP
> >routes into area 1 on R1, so R2 and R3 have type-5 LSAs for all the
> >RIP routes.Now i changed
> >Area 1 to NSSA , So R1 is now orginating type-7 LSAs for all the RIP
> >routes into area 1 with P-bit set.
> >
> >Now mine question is should R2 -
> >
> > 1.     Prefer type 7 LSA over type-5 .
> >Convert type-7 LSA into type-5 LSA  and flood into backbone, which
> >aleardy have  type-5 LSAs for the same netwroks earlier orginated by
> >R1(not yet flushed as it will remain in backbone for MAX AGE)
> >(According to RFC 3101. section 2.5 stp 6 (e) ).
> >
> >Disadvantage: The LSP database size will be doubled till MAX AGE time.
> >Advantage : simplicity
> >
> >2. Prefer type-5 over type-7 .
> >Use type-5 LSA for calculating external routes till type-5 LSAs
> >advertised by R1 exists in backbone(MAX Age) , and once type is
> >flushed because of MAX age , USE type -7 now to calculate external
> >routes , and translate at this point from type-7 to type-5(RFC 1587
> >3.5 step 5)
> >
> >Advantage : LSP database size is small.
> >Disadvantage: bit complex,but not much.
> >
> >3. or its Implementations Specific.
> >
> >Thanks in Advance
> >
> >
> >
> >
>=20


--=20
Santosh Esale

Member - Technical Staff

Riverstone Networks India Pvt. Ltd.

Email: sesale@riverstonenet.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May 16 10:21:06 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17450
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 May 2005 10:21:06 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010498AD@cherry.ease.lsoft.com>; Mon, 16 May 2005 10:21:05 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71003122 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 May 2005 10:20:57
          -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Mon, 16 May 2005 10:20:56 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com
          with ESMTP; 16 May 2005 10:20:57 -0400
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 j4GEKne2025049 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 16 May 2005
          10:20:55 -0400 (EDT)
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); Mon,
          16 May 2005 10:20:49 -0400
Received: from [10.82.225.188] ([10.82.225.188]) by xfe-rtp-202.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 10:20:49 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <c4bf85a2050514081066c7ef0a@mail.gmail.com>           
            <428874E3.1020408@cisco.com>
            <c4bf85a20505160343ab75063@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 May 2005 14:20:49.0849 (UTC)
                       FILETIME=[759C4290:01C55A22]
Message-ID:  <4288AC41.4060309@cisco.com>
Date:         Mon, 16 May 2005 10:20:49 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: Type-7 to Type-5 translation issue
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <c4bf85a20505160343ab75063@mail.gmail.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Santosh,
See inline.

Santosh Esale wrote:

>Hi Acee,
>            U mean i should check whether the ASBR path is via type-5
>capable area, and if its not USE NSSA external lsa for calculation and
>do the type-7 to type-5 conversion immediately.
>  
>
I'm saying that you should not use the AS-external-LSA if the path to
the ASBR is not
through a regular area (RFC 3101 uses the term Type-5 capable which I
really don't
like since we have descriptive names for the LSAs). If there is an
NSSA-LSA originated
by R1 it will be used by other routers in area 1 and R2 will do the
translation.

>I do agree with this...but we are doubling the LSP database size, how
>to slove it?
>  
>
You don't :^) In your example, R1 could attempt to flush all its
AS-external-LSAs prior
to converting to area 1 to a regular area. However, the network
administrator would have
to time the conversion such that the MAXAGE'ed AS-external-LSAs get
flooded to other
routers in area 1 prior to conversion (since AS scoped LSAs are not
flooded over NSSA
interfaces). In any case, they will not be used and it may be easier to
allow them to just
age out.

Hope this helps,
Acee


>Thanks
>Santosh
>
>On 5/16/05, Acee Lindem <acee@cisco.com> wrote:
>  
>
>>Hi Santosh,
>>
>>Whether or not R1 purges its AS-external-LSAs prior to area 1 being
>>coverted from a regular area to an NSSA is implementation specific.
>>However, the
>>timing of the conversion may be such that R1 is unable to purge them
>>from the
>>OSPF routing domain. In all cases, R1 should immediately originate
>>NSSA-LSAs
>>(type-7s) for redistributed routes. When R2 computes its external/NSSA
>>routes
>>it should not use R1's AS-external-LSA since its path to the ASBR is not
>>through
>>a regular area (see section 2.5 in RFC 3101).
>>
>>Hope this helps,
>>Acee
>>
>>Santosh Esale wrote:
>>
>>    
>>
>>>Hi guys,
>>>          Mine topology is as below-
>>>
>>>R1----Area 1 ------R2--------Backbone Area------R3
>>>
>>>Initially Area 1 was type-5 capabale area and i was redistributing RIP
>>>routes into area 1 on R1, so R2 and R3 have type-5 LSAs for all the
>>>RIP routes.Now i changed
>>>Area 1 to NSSA , So R1 is now orginating type-7 LSAs for all the RIP
>>>routes into area 1 with P-bit set.
>>>
>>>Now mine question is should R2 -
>>>
>>>1.     Prefer type 7 LSA over type-5 .
>>>Convert type-7 LSA into type-5 LSA  and flood into backbone, which
>>>aleardy have  type-5 LSAs for the same netwroks earlier orginated by
>>>R1(not yet flushed as it will remain in backbone for MAX AGE)
>>>(According to RFC 3101. section 2.5 stp 6 (e) ).
>>>
>>>Disadvantage: The LSP database size will be doubled till MAX AGE time.
>>>Advantage : simplicity
>>>
>>>2. Prefer type-5 over type-7 .
>>>Use type-5 LSA for calculating external routes till type-5 LSAs
>>>advertised by R1 exists in backbone(MAX Age) , and once type is
>>>flushed because of MAX age , USE type -7 now to calculate external
>>>routes , and translate at this point from type-7 to type-5(RFC 1587
>>>3.5 step 5)
>>>
>>>Advantage : LSP database size is small.
>>>Disadvantage: bit complex,but not much.
>>>
>>>3. or its Implementations Specific.
>>>
>>>Thanks in Advance
>>>
>>>
>>>
>>>
>>>      
>>>
>
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May 16 10:30:15 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19475
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 May 2005 10:30:15 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0104994B@cherry.ease.lsoft.com>; Mon, 16 May 2005 10:30:16 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71016572 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 May 2005 10:30:14
          -0400
Received: from 64.233.184.195 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Mon, 16 May 2005 10:30:14 -0400
Received: by wproxy.gmail.com with SMTP id 71so1911497wri for
          <OSPF@peach.ease.lsoft.com>; Mon, 16 May 2005 07:30:14 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
                     h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
                     b=Ck4MJ7BNf8d8WdcTaoM8fyVzGImAB8tDpFycrLKFGWz+5iZgzwDLlL67u8yxPEhZCpXL+ZKNKbPaTtyNtK/NHJg1KcnqE9qTUsUCXb775SBvOITdqCOxflk8KxeSlb6MIVjIsj0ob17mdkEZcMc37pNN7msL29H+Iof16yqShl4=
Received: by 10.54.51.45 with SMTP id y45mr3719077wry; Mon, 16 May 2005
          07:30:14 -0700 (PDT)
Received: by 10.54.13.19 with HTTP; Mon, 16 May 2005 07:30:14 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <c4bf85a2050514081066c7ef0a@mail.gmail.com>
            <428874E3.1020408@cisco.com>
            <c4bf85a20505160343ab75063@mail.gmail.com>
            <4288AC41.4060309@cisco.com>
Message-ID:  <c4bf85a20505160730410ffe58@mail.gmail.com>
Date:         Mon, 16 May 2005 20:00:14 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Santosh Esale <s.esale@GMAIL.COM>
Subject: Re: Type-7 to Type-5 translation issue
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <4288AC41.4060309@cisco.com>
Precedence: list
Content-Transfer-Encoding: quoted-printable

Thankyou Acee.

Regards
Santosh

On 5/16/05, Acee Lindem <acee@cisco.com> wrote:
> Santosh,
> See inline.
>=20
> Santosh Esale wrote:
>=20
> >Hi Acee,
> >            U mean i should check whether the ASBR path is via type-5
> >capable area, and if its not USE NSSA external lsa for calculation and
> >do the type-7 to type-5 conversion immediately.
> >
> >
> I'm saying that you should not use the AS-external-LSA if the path to
> the ASBR is not
> through a regular area (RFC 3101 uses the term Type-5 capable which I
> really don't
> like since we have descriptive names for the LSAs). If there is an
> NSSA-LSA originated
> by R1 it will be used by other routers in area 1 and R2 will do the
> translation.
>=20
> >I do agree with this...but we are doubling the LSP database size, how
> >to slove it?
> >
> >
> You don't :^) In your example, R1 could attempt to flush all its
> AS-external-LSAs prior
> to converting to area 1 to a regular area. However, the network
> administrator would have
> to time the conversion such that the MAXAGE'ed AS-external-LSAs get
> flooded to other
> routers in area 1 prior to conversion (since AS scoped LSAs are not
> flooded over NSSA
> interfaces). In any case, they will not be used and it may be easier to
> allow them to just
> age out.
>=20
> Hope this helps,
> Acee
>=20
>=20
> >Thanks
> >Santosh
> >
> >On 5/16/05, Acee Lindem <acee@cisco.com> wrote:
> >
> >
> >>Hi Santosh,
> >>
> >>Whether or not R1 purges its AS-external-LSAs prior to area 1 being
> >>coverted from a regular area to an NSSA is implementation specific.
> >>However, the
> >>timing of the conversion may be such that R1 is unable to purge them
> >>from the
> >>OSPF routing domain. In all cases, R1 should immediately originate
> >>NSSA-LSAs
> >>(type-7s) for redistributed routes. When R2 computes its external/NSSA
> >>routes
> >>it should not use R1's AS-external-LSA since its path to the ASBR is no=
t
> >>through
> >>a regular area (see section 2.5 in RFC 3101).
> >>
> >>Hope this helps,
> >>Acee
> >>
> >>Santosh Esale wrote:
> >>
> >>
> >>
> >>>Hi guys,
> >>>          Mine topology is as below-
> >>>
> >>>R1----Area 1 ------R2--------Backbone Area------R3
> >>>
> >>>Initially Area 1 was type-5 capabale area and i was redistributing RIP
> >>>routes into area 1 on R1, so R2 and R3 have type-5 LSAs for all the
> >>>RIP routes.Now i changed
> >>>Area 1 to NSSA , So R1 is now orginating type-7 LSAs for all the RIP
> >>>routes into area 1 with P-bit set.
> >>>
> >>>Now mine question is should R2 -
> >>>
> >>>1.     Prefer type 7 LSA over type-5 .
> >>>Convert type-7 LSA into type-5 LSA  and flood into backbone, which
> >>>aleardy have  type-5 LSAs for the same netwroks earlier orginated by
> >>>R1(not yet flushed as it will remain in backbone for MAX AGE)
> >>>(According to RFC 3101. section 2.5 stp 6 (e) ).
> >>>
> >>>Disadvantage: The LSP database size will be doubled till MAX AGE time.
> >>>Advantage : simplicity
> >>>
> >>>2. Prefer type-5 over type-7 .
> >>>Use type-5 LSA for calculating external routes till type-5 LSAs
> >>>advertised by R1 exists in backbone(MAX Age) , and once type is
> >>>flushed because of MAX age , USE type -7 now to calculate external
> >>>routes , and translate at this point from type-7 to type-5(RFC 1587
> >>>3.5 step 5)
> >>>
> >>>Advantage : LSP database size is small.
> >>>Disadvantage: bit complex,but not much.
> >>>
> >>>3. or its Implementations Specific.
> >>>
> >>>Thanks in Advance
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
>=20


--=20
Santosh Esale

Member - Technical Staff

Riverstone Networks India Pvt. Ltd.

Email: sesale@riverstonenet.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May 16 15:52:16 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03076
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 May 2005 15:52:16 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.01049E72@cherry.ease.lsoft.com>; Mon, 16 May 2005 15:52:14 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71052347 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 May 2005 15:52:13
          -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Mon, 16 May 2005 15:42:07 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id PAA00205; Mon, 16 May 2005 15:42:05
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200505161942.PAA00205@ietf.org>
Date:         Mon, 16 May 2005 15:42:04 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ospf-ospfv3-update-04.txt
Comments: To: i-d-announce@ietf.org
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.

	Title		: OSPF for IPv6
	Author(s)	: D. Ferguson, et al.
	Filename	: draft-ietf-ospf-ospfv3-update-04.txt
	Pages		: 95
	Date		: 2005-5-16
	
This document describes the modifications to OSPF to support version
   6 of the Internet Protocol (IPv6).  The fundamental mechanisms of
   OSPF (flooding, DR election, area support, SPF calculations, etc.)
   remain unchanged.  However, some changes have been necessary, either
   due to changes in protocol semantics between IPv4 and IPv6, or simply
   to handle the increased address size of IPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ospf-ospfv3-update-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2005-5-16152101.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ospf-ospfv3-update-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2005-5-16152101.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May 17 10:48:05 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02512
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 May 2005 10:48:05 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0104AE3C@cherry.ease.lsoft.com>; Tue, 17 May 2005 10:48:01 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71203506 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 May 2005 10:47:58
          -0400
Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Tue, 17 May 2005 10:47:58 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392)
          id <01LOCVDOOG9C002VJL@omega7.wr.usgs.gov> for
          OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 May 2005 07:50:45 -0700 (PDT)
X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM
X-VMS-Cc: PMURPHY,s.esale@GMAIL.COM
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Message-ID:  <01LOCVDOOH7M002VJL@omega7.wr.usgs.gov>
Date:         Tue, 17 May 2005 07:50:45 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: Type-7 to Type-5 translation issue
Comments: cc: S.ESALE@GMAIL.COM
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Santosh,

I am not sure why my first post never listed, so here again are a few 
thoughts regarding, 

> 1. Prefer type 7 LSA over type-5 .
...
> 2. Prefer type-5 over type-7
...
>3. or its Implementations Specific.
 
Given that the forwarding addresses are the same and point into a newly 
created NSSA, the type-5 LSA would never install on R2. An NSSA border 
router (like R2) never chooses a forwarding path into an NSSA for a 
type-5 LSA as the NSSA's routers (some of which might be internal) 
cannot be counted on to forward packets destined for its prefix along 
the expected path. The same is true for simple stub areas.

Second, you are in complete control here regardless of implementation 
specifics. Simply stop the RIP redistribution on R1 through access-list 
control or by simply shutting down the path to the gateway router of the 
RIP learned routes. Any proper OSPF implementation on R1 should 
immediately flush its type-5 LSAs, as it is no longer a source for these 
routes. Then convert Area 1 to an NSSA. Afterwards restart the RIP 
redistribution.

Hope this helps.

Pat


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May 17 15:52:29 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02678
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 May 2005 15:52:28 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0104BE4E@cherry.ease.lsoft.com>; Tue, 17 May 2005 15:52:28 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71257735 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 May 2005 15:52:26
          -0400
Received: from 32.97.110.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Tue, 17 May 2005 15:52:26 -0400
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com
          [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id
          j4HJqKmD188666 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 17 May 2005
          15:52:20 -0400
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
          by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id
          j4HJqJnP198398 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 17 May 2005
          13:52:19 -0600
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by
          d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4HJqJPQ014387
          for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 17 May 2005 13:52:19 -0600
Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com
          [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with
          ESMTP id j4HJqJus014381 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 17 May
          2005 13:52:19 -0600
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
X-MIMETrack: S/MIME Sign by Notes Client on Mike Fox/Raleigh/IBM(Release
             6.0.2CF1|June 9, 2003) at 05/17/2005 03:52:02 PM,
             Serialize by Notes Client on Mike Fox/Raleigh/IBM(Release
             6.0.2CF1|June 9, 2003) at 05/17/2005 03:52:02 PM,
             Serialize complete at 05/17/2005 03:52:02 PM,
             S/MIME Sign failed at 05/17/2005 03:52:02 PM: The cryptographic
             key was not found,
             Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005
             Beta 3|January 11, 2005) at 05/17/2005 13:52:18,
             Serialize complete at 05/17/2005 13:52:18
Content-Type: multipart/alternative; boundary="=_alternative 006D224F85257004_="
Message-ID:  <OF098FB926.6A7C1AAD-ON85257004.006C9A75-85257004.006D2256@us.ibm.com>
Date:         Tue, 17 May 2005 13:52:12 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mike Fox <mjfox@US.IBM.COM>
Subject: More comments and questions on OSPFv3 security draft
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

This is a multipart message in MIME format.
--=_alternative 006D224F85257004_=
Content-Type: text/plain; charset="US-ASCII"

Back in Feburary and March I had a dialog with Vishwas involving some 
questions on the OSPFv3 security draft.  Our security expert has asked for 
some additional clarification, here is his comment: 

My comment is based on the following from RFC 2401 (section 4.1): 

A security association is uniquely identified by a triple consisting
   of a Security Parameter Index (SPI), an IP Destination Address, and a
   security protocol (AH or ESP) identifier.  In principle, the
   Destination Address may be a unicast address, an IP broadcast
   address, or a multicast group address.  However, IPsec SA management
   mechanisms currently are defined only for unicast SAs.  Hence, in the
   discussions that follow, SAs will be described in the context of
   point-to-point communication, even though the concept is applicable
   in the point-to-multipoint case as well.

As noted above, two types of SAs are defined: transport mode and
   tunnel mode.  A transport mode SA is a security association between
   two hosts.

Comment: Certainly an SPD can have a ranged address that points to the 
same SA. This is how you would set up an SPD in a firewall for tunnel mode 
traffic. That is, a range of addresses for a network (not on the firewall) 
can use a single SA. The destination IP address is an IPSec SA endpoint. 
However, the SA must adhere to the definition above. For unicast transport 
mode, I read this to be that the destination address is a single IP 
address not a range. I suggest that the OSPFv3 security draft specify 
exactly how the manual SAs would need to be set up to be compliant. I 
don't think there is anything in RFC 2401 that allows a range of unicast 
IP addresses to be "a unicast address". 

And since it has been a while, here is the string of notes he is 
commenting on: 






Vishwas Manral <Vishwas@SINETT.COM>
Sent by: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
03/01/2005 05:59 AM
Please respond to Mailing List
 
        To:     OSPF@PEACH.EASE.LSOFT.COM
        cc: 
        Subject:        Re: Questions about OSPF v3 security draft


Hi Mike,

Sorry for the delay. I may be wrong as I have not implemented this myself, 
however my views are as follows: -

If you see the SPD entry the Remote IP Address can be 
      "- Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges
        of IP addresses (unicast, anycast, broadcast (IPv4 only), or
                multicast group). "
So for OSPF the Multicast as well as the unicast addresses will be used to 
refer to an SA.

Next Layer Protocol would say OSPF.

That way we will have just one entry for all OSPF packets out of an 
interface, just as we want it and a similar entry for inbound traffic. I 
do not see a case of Full Mesh at all. I may be missing the point.

Thanks,
Vishwas
________________________________________
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike 
Fox
Sent: Friday, February 25, 2005 2:58 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Questions about OSPF v3 security draft


Vishwas, 

I shared your response with our security expert and here is his response: 

What we need to know is whether the paragraph is referring to unicast. " 
What it means is we will use the same crypto-algorithm and keys for all 
traffic to a neighbor over an interface." If this comment is referring to 
unicast, the point remains is that there will be multiple SAs. We will not 
be able to adhere to the figure 3 requirements for unicast, and there will 
be full meshing of SAs required between all communicating OSPFs. Not so 
bad if using IKE. Really bad if using manual SAs.   

Here is the thread of notes being referred to (since it's been a couple of 
weeks): 

Vishwas Manral <Vishwas@SINETT.COM> 
Sent by: Mailing List <OSPF@PEACH.EASE.LSOFT.COM> 
02/15/2005 12:01 AM 
Please respond to Mailing List 
        
        To:        OSPF@PEACH.EASE.LSOFT.COM 
        cc:         
        Subject:        Re: Questions about OSPF v3 security draft



Hi Mike, 
  
I think both the authors are on leave, so they will probably reply later. 
  
However regarding the first point, I agree the wording should be clearer. 
However what it means is we will use the same crypto-algorithm and keys 
for all traffic to a neighbor over an interface. 
  
Regarding the second point, I think I too have brought the issue on this 
list and the reply I think was that the draft does not prohibit the use of 
IKE for unicast flows. 
                                                                          
                                                                          
      
Thanks, 
Vishwas 
________________________________________

From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike 
Fox
Sent: Friday, February 11, 2005 8:04 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Questions about OSPF v3 security draft 
  

Regarding 
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt, 
and the previous drafts, a couple of questions have come up in our shop. 

1) Section 7, 2nd paragraph says "the implementations MUST use manually 
configured keys with same SA for inbound and outbound traffic (as shown in 
figure 3).  I assume the "same SA" MUST rule applies to multicast traffic 
only and not unicast traffic. This is because an SA is defined as an SPI, 
security protocol (AH or ESP), and destination IP address. For unicast 
addresses, by definition there will be as many SAs as there are unicast 
destination addresses. Therefore, I don't think it is possible to apply 
this MUST rule given the current IPSec definition (RFC 2401 section 4.1) 
of an SA for unicast. Assuming the intention of the draft was to apply 
only to multicast and given the number of potential SAs carrying unicast 
traffic, it would seem that using IKE to setup the SAs dynamically would 
be a reasonable alternative to manual keying.     
 
2)Section 9, 2nd paragraph discusses setting up a "secure IPSec channel 
dynamically once it acquires the required information".  Since this 
traffic is unicast only, IKE could easily set up the required SAs without 
knowing the specific IP addresses in advance. Creating SAs dynamically do 
not fit easily within scope of manual SA functional capabilities. Why not 
use IKE for this traffic? Is this an acceptable option?   

Mike 


-----------------------------------------------------------------------
Enterprise Network Solutions
-----------------------------------------------------------------------
Research Triangle Park, NC  USA
--=_alternative 006D224F85257004_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Back in Feburary and March I had a dialog
with Vishwas involving some questions on the OSPFv3 security draft. &nbsp;Our
security expert has asked for some additional clarification, here is his
comment: &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">My comment is based on the following
from RFC 2401 (section 4.1): </font>
<br>
<br><font size=3><tt><b>A security association is uniquely identified by
a triple consisting<br>
 &nbsp; of a Security Parameter Index (SPI), an IP Destination Address,
and a<br>
 &nbsp; security protocol (AH or ESP) identifier.</b> &nbsp;In principle,
the<br>
 &nbsp; Destination Address may be <b>a unicast address</b>, an IP broadcast<br>
 &nbsp; address, or a multicast group address. &nbsp;However, IPsec SA
management<br>
 &nbsp; mechanisms currently are defined only for unicast SAs. &nbsp;Hence,
in the<br>
 &nbsp; discussions that follow, SAs will be described in the context of<br>
 &nbsp; point-to-point communication, even though the concept is applicable<br>
 &nbsp; in the point-to-multipoint case as well.</tt></font>
<br>
<br><font size=3><tt>As noted above, two types of SAs are defined: transport
mode and<br>
 &nbsp; tunnel mode. &nbsp;A transport mode SA is a security association
between<br>
 &nbsp; two hosts.<br>
<br>
Comment: </tt></font><font size=2 face="sans-serif">Certainly an SPD can
have a ranged address that points to the same SA. This is how you would
set up an SPD in a firewall for tunnel mode traffic. That is, a range of
addresses for a network (not on the firewall) can use a single SA. The
destination IP address is an IPSec SA endpoint. However, the SA must adhere
to the definition above. For unicast transport mode, I read this to be
that the destination address is a single IP address not a range. I suggest
that the OSPFv3 security draft specify exactly how the manual SAs would
need to be set up to be compliant. I don't think there is anything in RFC
2401 that allows a range of unicast IP addresses to be &quot;a unicast
address&quot;. </font>
<br>
<br><font size=2 face="sans-serif">And since it has been a while, here
is the string of notes he is commenting on: </font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Vishwas Manral &lt;Vishwas@SINETT.COM&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: Mailing List &lt;OSPF@PEACH.EASE.LSOFT.COM&gt;</font>
<p><font size=1 face="sans-serif">03/01/2005 05:59 AM</font>
<br><font size=1 face="sans-serif">Please respond to Mailing List</font>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To:
&nbsp; &nbsp; &nbsp; &nbsp;OSPF@PEACH.EASE.LSOFT.COM</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc:
&nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:
&nbsp; &nbsp; &nbsp; &nbsp;Re: Questions about OSPF v3 security
draft</font></table>
<br>
<br>
<br><font size=2><tt>Hi Mike,<br>
<br>
Sorry for the delay. I may be wrong as I have not implemented this myself,
however my views are as follows: -<br>
<br>
If you see the SPD entry the Remote IP Address can be <br>
 &nbsp; &nbsp; &nbsp;&quot;- Remote IP Address(es) (IPv4 or IPv6): this
is a list of ranges<br>
 &nbsp; &nbsp; &nbsp; &nbsp;of IP addresses (unicast, anycast, broadcast
(IPv4 only), or<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;multicast group).
&quot;<br>
So for OSPF the Multicast as well as the unicast addresses will be used
to refer to an SA.<br>
<br>
Next Layer Protocol would say OSPF.<br>
<br>
That way we will have just one entry for all OSPF packets out of an interface,
just as we want it and a similar entry for inbound traffic. I do not see
a case of Full Mesh at all. I may be missing the point.<br>
<br>
Thanks,<br>
Vishwas<br>
________________________________________<br>
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike
Fox<br>
Sent: Friday, February 25, 2005 2:58 AM<br>
To: OSPF@PEACH.EASE.LSOFT.COM<br>
Subject: Re: Questions about OSPF v3 security draft<br>
<br>
<br>
Vishwas, <br>
<br>
I shared your response with our security expert and here is his response:
<br>
<br>
What we need to know is whether the paragraph is referring to unicast.
&quot; What it means is we will use the same crypto-algorithm and keys
for all traffic to a neighbor over an interface.&quot; If this comment
is referring to unicast, the point remains is that there will be multiple
SAs. We will not be able to adhere to the figure 3 requirements for unicast,
and there will be full meshing of SAs required between all communicating
OSPFs. Not so bad if using IKE. Really bad if using manual SAs. &nbsp;
<br>
<br>
Here is the thread of notes being referred to (since it's been a couple
of weeks): <br>
<br>
Vishwas Manral &lt;Vishwas@SINETT.COM&gt; <br>
Sent by: Mailing List &lt;OSPF@PEACH.EASE.LSOFT.COM&gt; <br>
02/15/2005 12:01 AM <br>
Please respond to Mailing List <br>
&nbsp; &nbsp; &nbsp; &nbsp; <br>
&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;OSPF@PEACH.EASE.LSOFT.COM
<br>
&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp; <br>
&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: Questions
about OSPF v3 security draft<br>
<br>
<br>
<br>
Hi Mike, <br>
&nbsp; <br>
I think both the authors are on leave, so they will probably reply later.
<br>
&nbsp; <br>
However regarding the first point, I agree the wording should be clearer.
However what it means is we will use the same crypto-algorithm and keys
for all traffic to a neighbor over an interface. <br>
&nbsp; <br>
Regarding the second point, I think I too have brought the issue on this
list and the reply I think was that the draft does not prohibit the use
of IKE for unicast flows. <br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
<br>
Thanks, <br>
Vishwas <br>
________________________________________<br>
<br>
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike
Fox<br>
Sent: Friday, February 11, 2005 8:04 PM<br>
To: OSPF@PEACH.EASE.LSOFT.COM<br>
Subject: Questions about OSPF v3 security draft <br>
&nbsp; <br>
<br>
Regarding http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt,
and the previous drafts, a couple of questions have come up in our shop.
<br>
<br>
1) Section 7, 2nd paragraph says &quot;the implementations MUST use manually
configured keys with same SA for inbound and outbound traffic (as shown
in figure 3). &nbsp;I assume the &quot;same SA&quot; MUST rule applies
to multicast traffic only and not unicast traffic. This is because an SA
is defined as an SPI, security protocol (AH or ESP), and destination IP
address. For unicast addresses, by definition there will be as many SAs
as there are unicast destination addresses. Therefore, I don't think it
is possible to apply this MUST rule given the current IPSec definition
(RFC 2401 section 4.1) of an SA for unicast. Assuming the intention of
the draft was to apply only to multicast and given the number of potential
SAs carrying unicast traffic, it would seem that using IKE to setup the
SAs dynamically would be a reasonable alternative to manual keying. &nbsp;
&nbsp; <br>
&nbsp;<br>
2)Section 9, 2nd paragraph discusses setting up a &quot;secure IPSec channel
dynamically once it acquires the required information&quot;. &nbsp;Since
this traffic is unicast only, IKE could easily set up the required SAs
without knowing the specific IP addresses in advance. Creating SAs dynamically
do not fit easily within scope of manual SA functional capabilities. Why
not use IKE for this traffic? Is this an acceptable option? &nbsp; <br>
<br>
Mike <br>
</tt></font>
<br><font size=2 face="sans-serif"><br>
-----------------------------------------------------------------------<br>
Enterprise Network Solutions<br>
-----------------------------------------------------------------------<br>
Research Triangle Park, NC &nbsp;USA</font>
--=_alternative 006D224F85257004_=--


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May 17 23:27:57 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19825
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 May 2005 23:27:56 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0104D498@cherry.ease.lsoft.com>; Tue, 17 May 2005 23:27:56 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71305002 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 May 2005 23:27:54
          -0400
Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Tue, 17 May 2005 23:27:54 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C55B59.937E8049"
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Thread-Topic: More comments and questions on OSPFv3 security draft
Thread-Index: AcVbGfXCIK0ZHKApSh6vvoFtmuhrTQAQRcdw
Message-ID:  <BB6D74C75CC76A419B6D6FA7C38317B27A8C26@sinett-sbs.SiNett.LAN>
Date:         Tue, 17 May 2005 20:27:53 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vishwas Manral <Vishwas@SINETT.COM>
Subject: Re: More comments and questions on OSPFv3 security draft
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

This is a multi-part message in MIME format.

------_=_NextPart_001_01C55B59.937E8049
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Mike,

=20

The quote I refer to is from 2401bis(which is with the IESG), which
replaces 2401.

     "- Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges
       of IP addresses (unicast, anycast, broadcast (IPv4 only), or
       multicast group). "



I would be ok if any clarification is added though.

=20

Thanks,

Vishwas

=20

________________________________

From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike
Fox
Sent: Wednesday, May 18, 2005 1:22 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: More comments and questions on OSPFv3 security draft

=20


Back in Feburary and March I had a dialog with Vishwas involving some
questions on the OSPFv3 security draft.  Our security expert has asked
for some additional clarification, here is his comment:  =20

My comment is based on the following from RFC 2401 (section 4.1):=20

A security association is uniquely identified by a triple consisting
  of a Security Parameter Index (SPI), an IP Destination Address, and a
  security protocol (AH or ESP) identifier.  In principle, the
  Destination Address may be a unicast address, an IP broadcast
  address, or a multicast group address.  However, IPsec SA management
  mechanisms currently are defined only for unicast SAs.  Hence, in the
  discussions that follow, SAs will be described in the context of
  point-to-point communication, even though the concept is applicable
  in the point-to-multipoint case as well.=20

As noted above, two types of SAs are defined: transport mode and
  tunnel mode.  A transport mode SA is a security association between
  two hosts.

Comment: Certainly an SPD can have a ranged address that points to the
same SA. This is how you would set up an SPD in a firewall for tunnel
mode traffic. That is, a range of addresses for a network (not on the
firewall) can use a single SA. The destination IP address is an IPSec SA
endpoint. However, the SA must adhere to the definition above. For
unicast transport mode, I read this to be that the destination address
is a single IP address not a range. I suggest that the OSPFv3 security
draft specify exactly how the manual SAs would need to be set up to be
compliant. I don't think there is anything in RFC 2401 that allows a
range of unicast IP addresses to be "a unicast address".=20

And since it has been a while, here is the string of notes he is
commenting on:=20





=20

Vishwas Manral <Vishwas@SINETT.COM>=20
Sent by: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>=20

03/01/2005 05:59 AM=20
Please respond to Mailing List=20

       =20
        To:        OSPF@PEACH.EASE.LSOFT.COM=20
        cc:        =20
        Subject:        Re: Questions about OSPF v3 security draft




Hi Mike,

Sorry for the delay. I may be wrong as I have not implemented this
myself, however my views are as follows: -

If you see the SPD entry the Remote IP Address can be=20
     "- Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges
       of IP addresses (unicast, anycast, broadcast (IPv4 only), or
               multicast group). "
So for OSPF the Multicast as well as the unicast addresses will be used
to refer to an SA.

Next Layer Protocol would say OSPF.

That way we will have just one entry for all OSPF packets out of an
interface, just as we want it and a similar entry for inbound traffic. I
do not see a case of Full Mesh at all. I may be missing the point.

Thanks,
Vishwas
________________________________________
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike
Fox
Sent: Friday, February 25, 2005 2:58 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Questions about OSPF v3 security draft


Vishwas,=20

I shared your response with our security expert and here is his
response:=20

What we need to know is whether the paragraph is referring to unicast. "
What it means is we will use the same crypto-algorithm and keys for all
traffic to a neighbor over an interface." If this comment is referring
to unicast, the point remains is that there will be multiple SAs. We
will not be able to adhere to the figure 3 requirements for unicast, and
there will be full meshing of SAs required between all communicating
OSPFs. Not so bad if using IKE. Really bad if using manual SAs.  =20

Here is the thread of notes being referred to (since it's been a couple
of weeks):=20

Vishwas Manral <Vishwas@SINETT.COM>=20
Sent by: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>=20
02/15/2005 12:01 AM=20
Please respond to Mailing List=20
       =20
        To:        OSPF@PEACH.EASE.LSOFT.COM=20
        cc:        =20
        Subject:        Re: Questions about OSPF v3 security draft



Hi Mike,=20
 =20
I think both the authors are on leave, so they will probably reply
later.=20
 =20
However regarding the first point, I agree the wording should be
clearer. However what it means is we will use the same crypto-algorithm
and keys for all traffic to a neighbor over an interface.=20
 =20
Regarding the second point, I think I too have brought the issue on this
list and the reply I think was that the draft does not prohibit the use
of IKE for unicast flows.=20
=20

Thanks,=20
Vishwas=20
________________________________________

From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike
Fox
Sent: Friday, February 11, 2005 8:04 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Questions about OSPF v3 security draft=20
 =20

Regarding
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt,
and the previous drafts, a couple of questions have come up in our shop.


1) Section 7, 2nd paragraph says "the implementations MUST use manually
configured keys with same SA for inbound and outbound traffic (as shown
in figure 3).  I assume the "same SA" MUST rule applies to multicast
traffic only and not unicast traffic. This is because an SA is defined
as an SPI, security protocol (AH or ESP), and destination IP address.
For unicast addresses, by definition there will be as many SAs as there
are unicast destination addresses. Therefore, I don't think it is
possible to apply this MUST rule given the current IPSec definition (RFC
2401 section 4.1) of an SA for unicast. Assuming the intention of the
draft was to apply only to multicast and given the number of potential
SAs carrying unicast traffic, it would seem that using IKE to setup the
SAs dynamically would be a reasonable alternative to manual keying.    =20
=20
2)Section 9, 2nd paragraph discusses setting up a "secure IPSec channel
dynamically once it acquires the required information".  Since this
traffic is unicast only, IKE could easily set up the required SAs
without knowing the specific IP addresses in advance. Creating SAs
dynamically do not fit easily within scope of manual SA functional
capabilities. Why not use IKE for this traffic? Is this an acceptable
option?  =20

Mike=20


-----------------------------------------------------------------------
Enterprise Network Solutions
-----------------------------------------------------------------------
Research Triangle Park, NC  USA


------_=_NextPart_001_01C55B59.937E8049
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:sans-serif;
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
tt
	{font-family:"Courier New";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi =
Mike,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The quote I refer to is from =
2401bis(which
is with the IESG), which replaces 2401.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp; &nbsp; &nbsp;&quot;- Remote IP Address(es) (IPv4 or =
IPv6): this
is a list of ranges</span></font></tt><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face=3D"Courier New">&nbsp; &nbsp; &nbsp; &nbsp;of IP =
addresses
(unicast, anycast, broadcast (IPv4 only), or</font></tt><br>
<tt><font face=3D"Courier New">&nbsp; &nbsp; &nbsp; &nbsp;multicast =
group).
&quot;</font></tt><br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>I would be ok if any clarification is added =
though.</span></font><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Vishwas<o:p></o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
<st1:PersonName
w:st=3D"on">Mailing List</st1:PersonName> =
[mailto:OSPF@PEACH.EASE.LSOFT.COM] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Mike Fox<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, May 18, =
2005 1:22
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
OSPF@PEACH.EASE.LSOFT.COM<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> More comments =
and
questions on OSPFv3 security draft</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'><br>
</span></font><font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;
font-family:sans-serif'>Back in Feburary and March I had a dialog with =
Vishwas
involving some questions on the OSPFv3 security draft. &nbsp;Our =
security
expert has asked for some additional clarification, here is his comment: =
&nbsp;</span></font>
<br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>My
comment is based on the following from RFC 2401 (section 4.1): =
</span></font><br>
<br>
<tt><b><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-weight:bold'>A security association is uniquely identified by a =
triple
consisting</span></font></b></tt><b><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New";font-weight:bold'><br>
<tt><font face=3D"Courier New">&nbsp; of a Security Parameter Index =
(SPI), an IP
Destination Address, and a</font></tt><br>
<tt><font face=3D"Courier New">&nbsp; security protocol (AH or ESP) =
identifier.</font></tt></span></font></b><tt><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> &nbsp;In =
principle,
the</span></font></tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><br>
<tt><font face=3D"Courier New">&nbsp; Destination Address may be =
<b><span
style=3D'font-weight:bold'>a unicast address</span></b>, an IP =
broadcast</font></tt><br>
<tt><font face=3D"Courier New">&nbsp; address, or a multicast group =
address.
&nbsp;However, IPsec SA management</font></tt><br>
<tt><font face=3D"Courier New">&nbsp; mechanisms currently are defined =
only for
unicast SAs. &nbsp;Hence, in the</font></tt><br>
<tt><font face=3D"Courier New">&nbsp; discussions that follow, SAs will =
be
described in the context of</font></tt><br>
<tt><font face=3D"Courier New">&nbsp; point-to-point communication, even =
though
the concept is applicable</font></tt><br>
<tt><font face=3D"Courier New">&nbsp; in the point-to-multipoint case as =
well.</font></tt></span></font>
<br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>As noted
above, two types of SAs are defined: transport mode =
and</span></font></tt><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face=3D"Courier New">&nbsp; tunnel mode. &nbsp;A transport =
mode SA is a
security association between</font></tt><br>
<tt><font face=3D"Courier New">&nbsp; two hosts.</font></tt><br>
<br>
<tt><font face=3D"Courier New">Comment: </font></tt></span></font><font =
size=3D2
face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Certainly
an SPD can have a ranged address that points to the same SA. This is how =
you
would set up an SPD in a firewall for tunnel mode traffic. That is, a =
range of
addresses for a network (not on the firewall) can use a single SA. The =
destination
IP address is an IPSec SA endpoint. However, the SA must adhere to the
definition above. For unicast transport mode, I read this to be that the
destination address is a single IP address not a range. I suggest that =
the
OSPFv3 security draft specify exactly how the manual SAs would need to =
be set
up to be compliant. I don't think there is anything in RFC 2401 that =
allows a
range of unicast IP addresses to be &quot;a unicast address&quot;. =
</span></font><br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>And
since it has been a while, here is the string of notes he is commenting =
on: </span></font><br>
<br>
<br>
<br>
<o:p></o:p></p>

<table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
 style=3D'width:100.0%'>
 <tr>
  <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
  <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
  style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>
  </td>
  <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
  <p class=3DMsoNormal><st1:PersonName w:st=3D"on"><b><font size=3D1 =
face=3Dsans-serif><span
   =
style=3D'font-size:7.5pt;font-family:sans-serif;font-weight:bold'>Vishwas=

   Manral</span></font></b></st1:PersonName><b><font size=3D1 =
face=3Dsans-serif><span
  style=3D'font-size:7.5pt;font-family:sans-serif;font-weight:bold'>
  &lt;Vishwas@SINETT.COM&gt;</span></font></b> <br>
  <font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>Sent
  by: <st1:PersonName w:st=3D"on">Mailing List</st1:PersonName>
  &lt;OSPF@PEACH.EASE.LSOFT.COM&gt;</span></font> <o:p></o:p></p>
  <p><font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:
  sans-serif'>03/01/2005 05:59 AM</span></font> <br>
  <font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>Please
  respond to <st1:PersonName w:st=3D"on">Mailing =
List</st1:PersonName></span></font>
  <o:p></o:p></p>
  </td>
  <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
  <p class=3DMsoNormal><font size=3D1 face=3DArial><span =
style=3D'font-size:7.5pt;
  font-family:Arial'>&nbsp; &nbsp; &nbsp; &nbsp; </span></font><br>
  <font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>&nbsp;
  &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; =
&nbsp;OSPF@PEACH.EASE.LSOFT.COM</span></font>
  <br>
  <font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>&nbsp;
  &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</span></font> =
<br>
  <font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>&nbsp;
  &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: Questions =
about
  OSPF v3 security draft</span></font><o:p></o:p></p>
  </td>
 </tr>
</table>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><br>
<br>
<br>
</span></font><tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Hi
Mike,</span></font></tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><br>
<br>
<tt><font face=3D"Courier New">Sorry for the delay. I may be wrong as I =
have not
implemented this myself, however my views are as follows: =
-</font></tt><br>
<br>
<tt><font face=3D"Courier New">If you see the SPD entry the Remote IP =
Address can
be </font></tt><br>
<tt><font face=3D"Courier New">&nbsp; &nbsp; &nbsp;&quot;- Remote IP =
Address(es)
(IPv4 or IPv6): this is a list of ranges</font></tt><br>
<tt><font face=3D"Courier New">&nbsp; &nbsp; &nbsp; &nbsp;of IP =
addresses
(unicast, anycast, broadcast (IPv4 only), or</font></tt><br>
<tt><font face=3D"Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;
&nbsp;multicast group). &quot;</font></tt><br>
<tt><font face=3D"Courier New">So for OSPF the Multicast as well as the =
unicast
addresses will be used to refer to an SA.</font></tt><br>
<br>
<tt><font face=3D"Courier New">Next Layer Protocol would say =
OSPF.</font></tt><br>
<br>
<tt><font face=3D"Courier New">That way we will have just one entry for =
all OSPF
packets out of an interface, just as we want it and a similar entry for =
inbound
traffic. I do not see a case of Full Mesh at all. I may be missing the =
point.</font></tt><br>
<br>
<tt><font face=3D"Courier New">Thanks,</font></tt><br>
<tt><font face=3D"Courier New">Vishwas</font></tt><br>
<tt><font face=3D"Courier =
New">________________________________________</font></tt><br>
<tt><font face=3D"Courier New">From: <st1:PersonName w:st=3D"on">Mailing =
List</st1:PersonName>
[mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox</font></tt><br>
<tt><font face=3D"Courier New">Sent: Friday, February 25, 2005 2:58 =
AM</font></tt><br>
<tt><font face=3D"Courier New">To: =
OSPF@PEACH.EASE.LSOFT.COM</font></tt><br>
<tt><font face=3D"Courier New">Subject: Re: Questions about OSPF v3 =
security
draft</font></tt><br>
<br>
<br>
<tt><font face=3D"Courier New">Vishwas, </font></tt><br>
<br>
<tt><font face=3D"Courier New">I shared your response with our security =
expert
and here is his response: </font></tt><br>
<br>
<tt><font face=3D"Courier New">What we need to know is whether the =
paragraph is
referring to unicast. &quot; What it means is we will use the same
crypto-algorithm and keys for all traffic to a neighbor over an =
interface.&quot;
If this comment is referring to unicast, the point remains is that there =
will
be multiple SAs. We will not be able to adhere to the figure 3 =
requirements for
unicast, and there will be full meshing of SAs required between all
communicating OSPFs. Not so bad if using IKE. Really bad if using manual =
SAs.
&nbsp; </font></tt><br>
<br>
<tt><font face=3D"Courier New">Here is the thread of notes being =
referred to
(since it's been a couple of weeks): </font></tt><br>
<br>
<st1:PersonName w:st=3D"on"><tt><font face=3D"Courier New">Vishwas =
Manral</font></tt></st1:PersonName><tt><font
face=3D"Courier New"> &lt;Vishwas@SINETT.COM&gt; </font></tt><br>
<tt><font face=3D"Courier New">Sent by: <st1:PersonName =
w:st=3D"on">Mailing List</st1:PersonName>
&lt;OSPF@PEACH.EASE.LSOFT.COM&gt; </font></tt><br>
<tt><font face=3D"Courier New">02/15/2005 12:01 AM </font></tt><br>
<tt><font face=3D"Courier New">Please respond to <st1:PersonName =
w:st=3D"on">Mailing
 List</st1:PersonName> </font></tt><br>
<tt><font face=3D"Courier New">&nbsp; &nbsp; &nbsp; &nbsp; =
</font></tt><br>
<tt><font face=3D"Courier New">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; =
&nbsp;
&nbsp; &nbsp;OSPF@PEACH.EASE.LSOFT.COM </font></tt><br>
<tt><font face=3D"Courier New">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; =
&nbsp;
&nbsp; &nbsp; </font></tt><br>
<tt><font face=3D"Courier New">&nbsp; &nbsp; &nbsp; &nbsp; Subject: =
&nbsp; &nbsp;
&nbsp; &nbsp;Re: Questions about OSPF v3 security draft</font></tt><br>
<br>
<br>
<br>
<tt><font face=3D"Courier New">Hi Mike, </font></tt><br>
<tt><font face=3D"Courier New">&nbsp; </font></tt><br>
<tt><font face=3D"Courier New">I think both the authors are on leave, so =
they
will probably reply later. </font></tt><br>
<tt><font face=3D"Courier New">&nbsp; </font></tt><br>
<tt><font face=3D"Courier New">However regarding the first point, I =
agree the
wording should be clearer. However what it means is we will use the same
crypto-algorithm and keys for all traffic to a neighbor over an =
interface. </font></tt><br>
<tt><font face=3D"Courier New">&nbsp; </font></tt><br>
<tt><font face=3D"Courier New">Regarding the second point, I think I too =
have
brought the issue on this list and the reply I think was that the draft =
does
not prohibit the use of IKE for unicast flows. </font></tt><br>
<tt><font face=3D"Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; </font></tt><br>
<tt><font face=3D"Courier New">Thanks, </font></tt><br>
<tt><font face=3D"Courier New">Vishwas </font></tt><br>
<tt><font face=3D"Courier =
New">________________________________________</font></tt><br>
<br>
<tt><font face=3D"Courier New">From: <st1:PersonName w:st=3D"on">Mailing =
List</st1:PersonName>
[mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox</font></tt><br>
<tt><font face=3D"Courier New">Sent: Friday, February 11, 2005 8:04 =
PM</font></tt><br>
<tt><font face=3D"Courier New">To: =
OSPF@PEACH.EASE.LSOFT.COM</font></tt><br>
<tt><font face=3D"Courier New">Subject: Questions about OSPF v3 security =
draft </font></tt><br>
<tt><font face=3D"Courier New">&nbsp; </font></tt><br>
<br>
<tt><font face=3D"Courier New">Regarding
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt, =
and the
previous drafts, a couple of questions have come up in our shop. =
</font></tt><br>
<br>
<tt><font face=3D"Courier New">1) Section 7, 2nd paragraph says =
&quot;the
implementations MUST use manually configured keys with same SA for =
inbound and
outbound traffic (as shown in figure 3). &nbsp;I assume the &quot;same =
SA&quot;
MUST rule applies to multicast traffic only and not unicast traffic. =
This is
because an SA is defined as an SPI, security protocol (AH or ESP), and
destination IP address. For unicast addresses, by definition there will =
be as
many SAs as there are unicast destination addresses. Therefore, I don't =
think
it is possible to apply this MUST rule given the current IPSec =
definition (RFC
2401 section 4.1) of an SA for unicast. Assuming the intention of the =
draft was
to apply only to multicast and given the number of potential SAs =
carrying
unicast traffic, it would seem that using IKE to setup the SAs =
dynamically
would be a reasonable alternative to manual keying. &nbsp; &nbsp; =
</font></tt><br>
<tt><font face=3D"Courier New">&nbsp;</font></tt><br>
<tt><font face=3D"Courier New">2)Section 9, 2nd paragraph discusses =
setting up a
&quot;secure IPSec channel dynamically once it acquires the required
information&quot;. &nbsp;Since this traffic is unicast only, IKE could =
easily
set up the required SAs without knowing the specific IP addresses in =
advance.
Creating SAs dynamically do not fit easily within scope of manual SA =
functional
capabilities. Why not use IKE for this traffic? Is this an acceptable =
option?
&nbsp; </font></tt><br>
<br>
<tt><font face=3D"Courier New">Mike </font></tt><br>
</span></font><br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'><br>
-----------------------------------------------------------------------<b=
r>
<st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Enterprise</st1:place></st1:City>
Network Solutions<br>
-----------------------------------------------------------------------<b=
r>
<st1:place w:st=3D"on"><st1:City w:st=3D"on">Research Triangle =
Park</st1:City>, <st1:State
 w:st=3D"on">NC</st1:State> &nbsp;<st1:country-region =
w:st=3D"on">USA</st1:country-region></st1:place></span></font><o:p></o:p>=
</p>

</div>

</body>

</html>

------_=_NextPart_001_01C55B59.937E8049--


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 05:47:16 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11225
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 05:47:15 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0104FBA0@cherry.ease.lsoft.com>; Thu, 19 May 2005 5:47:13 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71575805 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 05:47:10
          -0400
Received: from 192.91.191.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Thu, 19 May 2005 05:47:10 -0400
Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by
          smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.211); Thu,
          19 May 2005 10:47:09 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Thread-Topic: Comments on draft-ietf-ospf-mt-ospfv3-00
Thread-Index: AcVcV7lRJiTghrxKSCC+EArwiICO9Q==
X-OriginalArrivalTime: 19 May 2005 09:47:09.0586 (UTC)
                       FILETIME=[B99C3720:01C55C57]
Message-ID:  <2E60260A5637C2448841A5F60A6F9B033F75C6@enfimail1.datcon.co.uk>
Date:         Thu, 19 May 2005 10:47:09 +0100
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Alan Davey <Alan.Davey@DATACONNECTION.COM>
Subject: Comments on draft-ietf-ospf-mt-ospfv3-00
Comments: To: sina@cisco.com, akr@cisco.com
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

Folks

I have read the draft-ietf-ospf-mt-ospfv3-00 and I have some doubts and
questions.  I have listed these below, together with some minor
editorial nits that I noticed as I went through the draft.=20

Please let me know your thoughts.

Regards
Alan

------------------------------------
Alan Davey
Data Connection Ltd
Tel:   +44 20 8366 1177
Fax:   +44 20 8363 1039
Email: Alan.Davey@dataconnection.com
Web:   http://www.dataconnection.com


Comments and Doubts
-------------------

1.  I think that the draft probably requires an "IANA considerations"
section.  You may need to request a new address space for the MT values.
You may also need to request a space for TLV and sub-TLV type values.

2.  Currently, the scope of the TLV types is restricted to the
containing LSA.  I wonder if having globally unique TLV types would
simplify code, for example, for protocol analysis.

3.  I have some doubts about the S-bit in the value field of TLVs to
indicate the presence of sub-TLVs.

-  I am not convinced that the S-bit is necessary; an implementation
either recognizes a TLV type or it does not.  In my opinion, if the
implementation recognizes the TLV then it knows if sub-TLVs are present.
If the implementation does not recognize the TLV type then the TLV is
ignored.  Either way, the S-bit does not appear to be necessary.

-  I may be misinterpreting the draft, but it appears to be inconsistent
in its specification of the use of the S-bit.  Section 6 states that the
S-bit is set in the value field of TLVs.  However,=20

	o	the extended LSA formats in section 20 do not define the
S-bit.  For example, in section 20.1, the extended Router-LSA LD-TLV has
sub-TLVs defined but the S-bit does not appear in the definition of the
LD-TLV.

	o	section 20.1 defines a Router Multi-Topology *sub-TLV*
with an S-bit shown.  What is the purpose of the S-bit in the sub-TLV?

4.  I also have doubts as to whether the "Total sub-TLV length" field
defined in section 6. is needed.  I think that

-  an implementation can use the sub-TLV length fields to skip to the
next value
-  the "Total sub-TLV length" is only useful if there are multiple
sub-TLVs that an implementation does not process.

5.  I am confused over whether the default topology MUST be defined
using non-extended LSAs or if it MAY be defined using extended LSAs.

-  Section 7. states that "In order to interact with non-MT capable
routers we define default topology as the topology that is built by
using the existing LSAs as specified in OSPFv3 [OSPFv3]."

-  Section 8. states that "When a MT capable router participates in
Default Topology, depending on RFC2740Compatibility (see Appendix A) it
will generate existing LSAs or extended LSAs for the Default Topology."

I suggest removing the first paragraph of Section 7.

6.  Section 11., paragraph 2 states that "(and all routers should be MT
capable)".  I think that this should be "MUST be MT capable".

7.  Section 20.1 states the following.

	We define a Router Multi-Topology sub-TLV (RMT-sTLV) below. This
sub-TLV could further contain sub-TLVs.

I think that it may be better to define the RMT-sTLV without the
possibility of further sub-TLVs.  If future extensions are required then
they can be added as separate sub-TLVs of the LD-TLV.

8.  Section 20.5 states the following.

	Note that when the sub-TLV is present (S-bit set in the
PrefixOptions) the=20
	sub-TLV is placed after Forwarding address and external route
Tag if they are present.

I think that it is not possible to tell if the Forwarding address and
external route Tag are present if a sub-TLV is placed inside the
EMT-TLV. =20

Better to define the MT-TLV as not having any sub-TLVs.  Any future
additions can be made as separate TLVs.

Questions
---------

1.  Do you expect any new LSAs defined in the future to have the T-bit
set in the LS type field?

2.  Can passive interfaces be configured on a per-MT basis?  That is,
can a single interface be configured to appear as a passive interface in
some MT, not to appear at all in other MT and, maybe, be an active
interface in other MT.

3.  The Extended Inter-Area-Prefix-LSA, Extended AS-External-LSA,
Extended Link-LSA and Extended Intra-Area-Prefix-LSA include a prefix
block.  Is there any reason why this is not defined as a TLV?  In the
draft, it has no type field, only a length.  The meaning must be deduced
from its position in the LSA.

4.  There are 2 places in the draft where the phrase "the only top level
TLV defined by this document" is used, in sections 20.1 and 20.4.
Should this read "the only top level TLV defined by this document for
this LSA"?

Minor Editorial Comments
------------------------

1.  There are multiple places in the draft where the future tense is
used.  I think that the present tense is more normal in IETF drafts.

2.  There are multiple places where the text states that "all fields are
defined as in [OSPFv3]".  I think that it is more accurate to state that
"all fields not defined in this document are as defined in [OSPFv3]".

3.  There are multiple places in the code where lower case "must" is
used.  I think that upper case MUST should be used instead, in line with
RFC 2119.  For example, see second to last paragraph in section 20.1.

4.  Given the length of the draft, you may want to consider adding a
Table of Contents.

5.  Minor editorial nits.

Section 4., first sentence:

s/in Options filed/in the Options field/

Section 5., first sentence:

s/in LS type/in the LS type/

Section 8., first sentence:

s/We define a 8 bit/We define an 8 bit/

Section 9., header:

s/MT Control packet/MT Control Packets/

Section 11.,  first sentence:

s/metrics in E-router-LSA/metrics in the E-Router-LSA/

Section 12., first sentence:

s/When a MT-capable router participate in non-Default/When a MT-capable
router participates in non-Default/

Section 13., first sentence:

s/On multi-access links, the DR is responsible to generate prefix-LSA/On
multi-access links, the DR is responsible for generating prefix-LSA/

Section 15., first sentence:

s/it's MT-ID value is carried/its MT-ID value is carried/

Section 16., first sentence:

s/only routes belonging to the single/only routes belonging to a single/

Section 19., second paragraph:

s/RFC2740Compatibility can be set to disable/RFC2740Compatibility can be
set to disabled/

Section 20.1, last sentence in paragraph 1:

s/Each TLV could further contains sub-TLVs./Each TLV MAY contain
sub-TLVs./

Section 20.2, paragraph 5:

Suggest

	An Attached-Router TLV (AR-TLV) is defined. This TLV has similar
contents to the network-LSA payload.

	The E-network-LSA MUST contain an AR-TLV.

Instead of

	We define a Attached-Router TLV (AR-TLV). This TLV has similar
contents as the network-LSA payload.

	E-network-LSA must contain AR-TLV.

Section 20.6, second to last paragraph on page 19:

s/if the link participate in a MT/if the link participates in a MT/


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 08:20:25 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28337
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 08:20:24 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0104FB35@cherry.ease.lsoft.com>; Thu, 19 May 2005 8:20:23 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71615807 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 08:20:21
          -0400
Received: from 217.12.10.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Thu, 19 May 2005 08:20:21 -0400
Received: (qmail 40978 invoked by uid 60001); 19 May 2005 12:20:21 -0000
Received: from [202.144.106.188] by web25301.mail.ukl.yahoo.com via HTTP; Thu,
          19 May 2005 13:20:20 BST
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>
Date:         Thu, 19 May 2005 13:20:20 +0100
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: John Smith <jsmith4112003@YAHOO.CO.UK>
Subject: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit

Hi,

When a router comes up it starts the Wait Timer before it elects the DR/BDR. It either
waits for the Wait Timer to expire or it waits for a router declaring itself as the BDR
before it decides that it needs to get out of the 'Waiting' state (it does this by
generating the Backupseen event). 

My question is why does it wait only for the BDR? Why not the DR? It can when it recieves
a HELLO from the DR know that their exists a DR and a BDR. Why not then get out of the
'Waiting' state?

Thanks,
John

Send instant messages to your online friends http://uk.messenger.yahoo.com 


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 10:43:04 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11547
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 10:43:04 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0104FD25@cherry.ease.lsoft.com>; Thu, 19 May 2005 10:43:04 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71630840 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 10:42:52
          -0400
Received: from 131.254.254.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Thu, 19 May 2005 10:32:52 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by
          localhost.irisa.fr (Postfix) with ESMTP id 5C9B3FAAB for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 May 2005 16:32:53 +0200 (CEST)
Received: from smtp.irisa.fr ([131.254.254.26]) by localhost (meli.irisa.fr
          [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11729-07 for 
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 May 2005 16:32:52 +0200 (CEST)
Received: from mail.irisa.fr (melo.irisa.fr [131.254.254.28]) by smtp.irisa.fr
          (Postfix) with ESMTP id E3A0FFAD1 for <OSPF@PEACH.EASE.LSOFT.COM>;
          Thu, 19 May 2005 16:32:51 +0200 (CEST)
Received: from 148.60.12.11 (SquirrelMail authenticated user abaire) by
          mail.irisa.fr with HTTP; Thu, 19 May 2005 16:32:52 +0200 (CEST)
References: <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>
User-Agent: SquirrelMail/1.4.4
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 5 (Lowest)
Importance: Low
X-Virus-Scanned: by amavisd-new at irisa.fr
Message-ID:  <2108.148.60.12.11.1116513172.squirrel@mail.irisa.fr>
Date:         Thu, 19 May 2005 16:32:52 +0200
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Anthony Baire <Anthony.Baire@IRISA.FR>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>
Precedence: list
Content-Transfer-Encoding: 8bit

On Jeu 19 mai 2005 14:20, John Smith a écrit :
> Hi,
>
> When a router comes up it starts the Wait Timer before it elects the
> DR/BDR. It either
> waits for the Wait Timer to expire or it waits for a router declaring
> itself as the BDR
> before it decides that it needs to get out of the 'Waiting' state (it does
> this by
> generating the Backupseen event).
>
> My question is why does it wait only for the BDR? Why not the DR? It can
> when it recieves
> a HELLO from the DR know that their exists a DR and a BDR. Why not then
> get out of the
> 'Waiting' state?


Hi John,

this is not the exact definition of event BackupSeen. The event is
generated when the router detects the existence or non-existence of a
backup designated router. This can be done by receiving a Hello packet
from a DR claiming that there is no BDR on the network.


Anthony


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 12:21:10 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21697
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 12:21:09 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0105000B@cherry.ease.lsoft.com>; Thu, 19 May 2005 12:21:08 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71646274 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 12:21:07
          -0400
Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Thu, 19 May 2005 12:21:07 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com
          with ESMTP; 19 May 2005 12:31:45 -0400
X-IronPort-AV: i="3.93,121,1115006400"; d="scan'208"; a="50181716:sNHT30420140"
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 j4JGKYnm028509 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 May 2005
          12:21:05 -0400 (EDT)
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); Thu,
          19 May 2005 12:20:59 -0400
Received: from [10.82.242.200] ([10.82.242.200]) by xfe-rtp-201.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 12:20:59 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <200505161942.PAA00205@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 May 2005 16:20:59.0257 (UTC)
                       FILETIME=[BDFDDE90:01C55C8E]
Message-ID:  <428CBCDA.1050304@cisco.com>
Date:         Thu, 19 May 2005 12:20:42 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-update-04.txt
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <200505161942.PAA00205@ietf.org>
Precedence: list
Content-Transfer-Encoding: 7bit

Most of the changes in this version are typographical. I also reference
the new OSPF IANA draft.

I'm still interested opinions with removing the prevention of flooding
unknown LSA types (with the U bit set to 1) into stub areas. I think this
is somewhat broken since the protection is non-deterministic. Stub/NSSA
areas only include area and link scoped LSAs anyway. So, in order for
there to be an unknown LSA type at least one router in the stub or NSSA
must understand it. I really don't see the point of trying to limit the 
size of
databases (and this will be somewhat arbitrary dependent on which routers
understand the LSA). As long as there is a spanning tree inside the 
area, all
routers will need to store the LSAs which some routers don't understand 
any way.

If we can reach concensus I'd indicate that this RFC 2740 stub/nssa 
flooding
restriction is no longer valid. Again, I'd reiterate that functional 
changes were
made to OSPFv2 in the RFC 1247->RFC 1583 -> RFC 2178 -> RFC 2328
protocol specification evolution.

Thanks,
Acee

Internet-Drafts@IETF.ORG wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.
>
>	Title		: OSPF for IPv6
>	Author(s)	: D. Ferguson, et al.
>	Filename	: draft-ietf-ospf-ospfv3-update-04.txt
>	Pages		: 95
>	Date		: 2005-5-16
>	
>This document describes the modifications to OSPF to support version
>   6 of the Internet Protocol (IPv6).  The fundamental mechanisms of
>   OSPF (flooding, DR election, area support, SPF calculations, etc.)
>   remain unchanged.  However, some changes have been necessary, either
>   due to changes in protocol semantics between IPv4 and IPv6, or simply
>   to handle the increased address size of IPv6.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-04.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-ietf-ospf-ospfv3-update-04.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	mailserv@ietf.org.
>In the body type:
>	"FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-04.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>-------------------------------------------------------------------------
>CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
>-------------------------------------------------------------------------
>In order to maintain computing infrastructure integrity, Cisco Systems
>Enterprise Messaging Services and InfoSec teams have set a mail policy
>disallowing executable attachments in email.
>
>This message contained an executable attachment type that is prohibited 
>by this policy. The attachment has been removed from this message and 
>copied to quarantine by our systems. It will be held in quarantine for
>seven days in the event that the content needs to be retrieved.
>
>Please be aware many viruses attempt to look like legitimate email or 
>notifications from anti-virus systems. We will clearly mark a seperation
>between our notifications and the original email as follows:
>
>  "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"
>
>For further reference information about viruses and email antivirus 
>efforts within Cisco, please visit:
>
>http://wwwin.cisco.com/it/ems/services/antiviral
>
>If your concern isn't addressed by the information in this notification 
>or the above web page, you may open a support request:
>
>http://wwwin.cisco.com/support/
>
>Select "Messaging", "Email-Related", "Mail Routing"
>
>Please include in the text of your case the following information:
>
>* Full headers of the message. Documentation on displaying the full 
>headers is available at this URL:
>
>http://wwwin.cisco.com/support/library/faqs/solution002471.html 
>
>* This unique quarantine identifier: j4GJqJnP001734
>
>If the matter is urgent, you may follow up by calling one of the below 
>referenced numbers. Please make every effort to provide the above 
>requested information via the support web tool prior to calling as it 
>will greatly aid the resolution of your issue.
>
>Americas:
>1 408 526 8888
>
>Asiapac
>+61 2 8446 8888
>
>EMEA
>+31 20 485 4888
>
>Japan
>+81 3 5549 6888
>
>US (Toll Free)
>1| 800| 888| 8187| (ext.68888)
>
>Thank you for your cooperation,
>
>Enterprise Messaging Services
>Cisco Systems, Inc
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 12:53:50 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24154
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 12:53:49 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010500A3@cherry.ease.lsoft.com>; Thu, 19 May 2005 12:53:51 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71654656 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 12:53:49
          -0400
Received: from 208.8.0.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Thu, 19 May 2005 12:53:49 -0400
Received: from mailhub2.ind.alcatel.com (mailhub2.ind.alcatel.com
          [198.206.181.70]) by ind.alcatel.com (8.12.9/8.12.9/(postal1 2.1
          [OUT])) with ESMTP id j4JGrkPG015236 for <OSPF@peach.ease.lsoft.com>;
          Thu, 19 May 2005 09:53:48 -0700 (PDT)
X-InterScan: Passed
Received: from mailhub2.ind.alcatel.com (localhost [127.0.0.1]) by
          mailhub2.ind.alcatel.com (8.12.10/8.12.10/(mailhub2 4.1.4 [HUB2]))
          with ESMTP id j4JGrkaw012992 for <OSPF@peach.ease.lsoft.com>; Thu, 19
          May 2005 09:53:46 -0700 (PDT)
Received: from omni.ind.alcatel.com ([198.206.181.20]) by
          mailhub2.ind.alcatel.com (MailFrontier 4.0.2.4693) with ESMTP; Thu,
          19 May 2005 09:53:46 -0700
Received: from Kishorepc ([128.251.40.163]) by omni.ind.alcatel.com
          (8.9.3+Sun/8.9.1 (omni 3.0 [engr-SPOOL])) with SMTP id JAA18410 for
          <OSPF@peach.ease.lsoft.com>; Thu, 19 May 2005 09:53:45 -0700 (PDT)
References:  <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>
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.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mlf-Threat: nothreat
X-Mlf-Threat-Detailed: nothreat;none;list_addrbk_domain
Message-ID:  <06c101c55c93$8020fa80$a328fb80@Kishorepc>
Date:         Thu, 19 May 2005 10:55:02 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Kishore Rao <kishore@IND.ALCATEL.COM>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

> My question is why does it wait only for the BDR? Why not the DR? It can
when it recieves
> a HELLO from the DR know that their exists a DR and a BDR. Why not then
get out of the
> 'Waiting' state?

It also waits for a router to declare itself as a DR (section 10.5 Receving
Hello packets). The
'Neighborchange' event triggers DR election.

[Otherwise, if the neighbor is declaring itself to be Designated Router and
it had not previously,
or the neighbor is not declaring itself  Designated Router where it had
previously, the receiving
interface's state machine is scheduled with the event NeighborChange.]

Kishore

>
> Thanks,
> John
>
> Send instant messages to your online friends http://uk.messenger.yahoo.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 14:14:28 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01913
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 14:14:27 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.01050038@cherry.ease.lsoft.com>; Thu, 19 May 2005 14:14:26 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71662314 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 14:14:24
          -0400
Received: from 129.89.169.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Thu, 19 May 2005 14:14:24 -0400
Received: from mail04.imt.uwm.edu (mail04.imt.uwm.edu [129.89.7.46]) by
          batch3.csd.uwm.edu (8.12.10/8.12.6) with ESMTP id j4JIENDD000161 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 May 2005 13:14:23 -0500 (CDT)
Received: from localhost (pm02.imt.uwm.edu [129.89.7.62]) by mail04.imt.uwm.edu
          (8.12.10/8.12.5) with ESMTP id j4JIEMrW009101 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 May 2005 13:14:23 -0500
Received: from adsl-68-248-231-128.dsl.milwwi.ameritech.net
          (adsl-68-248-231-128.dsl.milwwi.ameritech.net [68.248.231.128]) by
          panthermail.uwm.edu (IMP) with HTTP for <mukul@localhost>; Thu, 19
          May 2005 13:14:22 -0500
References: <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: PantherMail 3.2.9-cvs
X-Originating-IP: 68.248.231.128
X-Virus-Scanned: by amavisd-new
X-Spam-Status: No,
               hits=-48.165 required=5
               tests=MAILTO_TO_SPAM_ADDR,NO_REAL_NAME,UWM_DOMAIN_MESSAGE_1
X-Scanned-By: MIMEDefang 2.51 on 129.89.7.46
Message-ID:  <1116526462.428cd77ee421b@panthermail.uwm.edu>
Date:         Thu, 19 May 2005 13:14:22 -0500
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mukul Goyal <mukul@UWM.EDU>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>
Precedence: list
Content-Transfer-Encoding: 8bit

My guess is that if an interface comes out of the waiting state on receiving a
Hello from DR (without having received a Hello from BDR), it may elect itself
as BDR. This way many routers may elect themselves as BDR. Now all these BDR
claimants (except one) will ultimately take their claims to BDRship back but in
the process each router on the LAN may have to do several DR elections.

Here is a paper we wrote recently that may shed further light on this:
http://cs.uwm.edu/~mukul/ospflan.pdf

Thanks,
Mukul

Quoting John Smith <jsmith4112003@YAHOO.CO.UK>:

> Hi,
>
> When a router comes up it starts the Wait Timer before it elects the DR/BDR.
> It either
> waits for the Wait Timer to expire or it waits for a router declaring itself
> as the BDR
> before it decides that it needs to get out of the 'Waiting' state (it does
> this by
> generating the Backupseen event).
>
> My question is why does it wait only for the BDR? Why not the DR? It can when
> it recieves
> a HELLO from the DR know that their exists a DR and a BDR. Why not then get
> out of the
> 'Waiting' state?
>
> Thanks,
> John
>
> Send instant messages to your online friends http://uk.messenger.yahoo.com
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 14:24:00 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02827
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 14:24:00 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0105020F@cherry.ease.lsoft.com>; Thu, 19 May 2005 14:24:00 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71662957 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 14:23:58
          -0400
Received: from 207.217.121.183 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Thu, 19 May 2005 14:23:58 -0400
Received: from h-68-164-85-18.snvacaid.dynamic.covad.net ([68.164.85.18]
          helo=earthlink.net) by pop-a065c05.pas.sa.earthlink.net with esmtp
          (Exim 3.36 #10) id 1DYpgb-0004rY-00 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 19 May 2005 11:23:57 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>
            <2108.148.60.12.11.1116513172.squirrel@mail.irisa.fr>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <428CDB83.BFAB88FA@earthlink.net>
Date:         Thu, 19 May 2005 11:31:31 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit

Anthony, et al,

	I am not sure what you are stating is correct.

	When an interface becomes active, the router checks
	the hellos on that interface for a period of
	time, known as the Waiting period in environments
	that supports DR and BDRs.

	If the interface is a passive interface, then ...
	Else {

	If one DR is seen and we are not declaring ourselves
	as the DR, we accept it and synch our LSDB, etc...

	}

	Else...

	Mitchell Erblich
	-----------------------

Anthony Baire wrote:
> 
> On Jeu 19 mai 2005 14:20, John Smith a écrit :
> > Hi,
> >
> > When a router comes up it starts the Wait Timer before it elects the
> > DR/BDR. It either
> > waits for the Wait Timer to expire or it waits for a router declaring
> > itself as the BDR
> > before it decides that it needs to get out of the 'Waiting' state (it does
> > this by
> > generating the Backupseen event).
> >
> > My question is why does it wait only for the BDR? Why not the DR? It can
> > when it recieves
> > a HELLO from the DR know that their exists a DR and a BDR. Why not then
> > get out of the
> > 'Waiting' state?
> 
> Hi John,
> 
> this is not the exact definition of event BackupSeen. The event is
> generated when the router detects the existence or non-existence of a
> backup designated router. This can be done by receiving a Hello packet
> from a DR claiming that there is no BDR on the network.
> 
> Anthony


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 14:43:27 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05006
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 14:43:27 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.010503B0@cherry.ease.lsoft.com>; Thu, 19 May 2005 14:43:26 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71664498 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 14:43:25
          -0400
Received: from 208.8.0.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Thu, 19 May 2005 14:43:25 -0400
Received: from mailhub1.ind.alcatel.com (mailhub1.ind.alcatel.com
          [198.206.181.170]) by ind.alcatel.com (8.12.9/8.12.9/(postal 2.0
          [OUT])) with ESMTP id j4JIhOMd018635 for <OSPF@peach.ease.lsoft.com>;
          Thu, 19 May 2005 11:43:24 -0700 (PDT)
X-InterScan: Passed
Received: from mailhub1.ind.alcatel.com (localhost [127.0.0.1]) by
          mailhub1.ind.alcatel.com (8.12.10/8.12.10/(mailhub1 4.1.4 [HUB1]))
          with ESMTP id j4JIhN3l011788 for <OSPF@peach.ease.lsoft.com>; Thu, 19
          May 2005 11:43:24 -0700 (PDT)
Received: from omni.ind.alcatel.com ([198.206.181.20]) by
          mailhub1.ind.alcatel.com (MailFrontier 4.0.2.4693) with ESMTP; Thu,
          19 May 2005 11:43:24 -0700
Received: from Kishorepc ([128.251.40.163]) by omni.ind.alcatel.com
          (8.9.3+Sun/8.9.1 (omni 3.0 [engr-SPOOL])) with SMTP id LAA21651 for
          <OSPF@peach.ease.lsoft.com>; Thu, 19 May 2005 11:43:22 -0700 (PDT)
References: <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com> 
            <1116526462.428cd77ee421b@panthermail.uwm.edu>
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.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mlf-Threat: nothreat
X-Mlf-Threat-Detailed: nothreat;none;list_addrbk_domain
Message-ID:  <072701c55ca2$d08ebd40$a328fb80@Kishorepc>
Date:         Thu, 19 May 2005 12:44:36 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Kishore Rao <kishore@IND.ALCATEL.COM>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

The question was not about how DR or BDRs are elected. John's question was
if the router should exit Wait Timer (and run DR election) on receving Hello
from a router declaring itself as DR. Well, from section 10.5 it should.

Kishore


> My guess is that if an interface comes out of the waiting state on
receiving a
> Hello from DR (without having received a Hello from BDR), it may elect
itself
> as BDR. This way many routers may elect themselves as BDR. Now all these
BDR
> claimants (except one) will ultimately take their claims to BDRship back
but in
> the process each router on the LAN may have to do several DR elections.
>
> Here is a paper we wrote recently that may shed further light on this:
> http://cs.uwm.edu/~mukul/ospflan.pdf
>
> Thanks,
> Mukul
>
> Quoting John Smith <jsmith4112003@YAHOO.CO.UK>:
>
> > Hi,
> >
> > When a router comes up it starts the Wait Timer before it elects the
DR/BDR.
> > It either
> > waits for the Wait Timer to expire or it waits for a router declaring
itself
> > as the BDR
> > before it decides that it needs to get out of the 'Waiting' state (it
does
> > this by
> > generating the Backupseen event).
> >
> > My question is why does it wait only for the BDR? Why not the DR? It can
when
> > it recieves
> > a HELLO from the DR know that their exists a DR and a BDR. Why not then
get
> > out of the
> > 'Waiting' state?
> >
> > Thanks,
> > John
> >
> > Send instant messages to your online friends
http://uk.messenger.yahoo.com
> >


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 14:53:45 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06463
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 14:53:44 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.010502C5@cherry.ease.lsoft.com>; Thu, 19 May 2005 14:53:44 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71665144 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 14:53:43
          -0400
Received: from 129.89.169.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Thu, 19 May 2005 14:53:42 -0400
Received: from mail02.imt.uwm.edu (mail02.imt.uwm.edu [129.89.7.44]) by
          batch3.csd.uwm.edu (8.12.10/8.12.6) with ESMTP id j4JIrgDD016256 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 May 2005 13:53:42 -0500 (CDT)
Received: from localhost (pm02.imt.uwm.edu [129.89.7.62]) by mail02.imt.uwm.edu
          (8.12.10/8.12.5) with ESMTP id j4JIrfsB018572 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 May 2005 13:53:41 -0500
Received: from adsl-68-248-231-128.dsl.milwwi.ameritech.net
          (adsl-68-248-231-128.dsl.milwwi.ameritech.net [68.248.231.128]) by
          panthermail.uwm.edu (IMP) with HTTP for <mukul@localhost>; Thu, 19
          May 2005 13:53:41 -0500
References: <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>           
            <1116526462.428cd77ee421b@panthermail.uwm.edu>
            <072701c55ca2$d08ebd40$a328fb80@Kishorepc>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: PantherMail 3.2.9-cvs
X-Originating-IP: 68.248.231.128
X-Virus-Scanned: by amavisd-new
X-Spam-Status: No,
               hits=-50.223 required=5
               tests=BAYES_00,MAILTO_TO_SPAM_ADDR,NO_REAL_NAME,UWM_DOMAIN_MESSAGE_1
X-Scanned-By: MIMEDefang 2.51 on 129.89.7.44
Message-ID:  <1116528821.428ce0b537b88@panthermail.uwm.edu>
Date:         Thu, 19 May 2005 13:53:41 -0500
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mukul Goyal <mukul@UWM.EDU>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <072701c55ca2$d08ebd40$a328fb80@Kishorepc>
Precedence: list
Content-Transfer-Encoding: 8bit

I think the NeighborChange events are ignored while an interface is in waiting
state.

Thanks,
Mukul


Quoting Kishore Rao <kishore@IND.ALCATEL.COM>:

> The question was not about how DR or BDRs are elected. John's question was
> if the router should exit Wait Timer (and run DR election) on receving Hello
> from a router declaring itself as DR. Well, from section 10.5 it should.
>
> Kishore
>
>
> > My guess is that if an interface comes out of the waiting state on
> receiving a
> > Hello from DR (without having received a Hello from BDR), it may elect
> itself
> > as BDR. This way many routers may elect themselves as BDR. Now all these
> BDR
> > claimants (except one) will ultimately take their claims to BDRship back
> but in
> > the process each router on the LAN may have to do several DR elections.
> >
> > Here is a paper we wrote recently that may shed further light on this:
> > http://cs.uwm.edu/~mukul/ospflan.pdf
> >
> > Thanks,
> > Mukul
> >
> > Quoting John Smith <jsmith4112003@YAHOO.CO.UK>:
> >
> > > Hi,
> > >
> > > When a router comes up it starts the Wait Timer before it elects the
> DR/BDR.
> > > It either
> > > waits for the Wait Timer to expire or it waits for a router declaring
> itself
> > > as the BDR
> > > before it decides that it needs to get out of the 'Waiting' state (it
> does
> > > this by
> > > generating the Backupseen event).
> > >
> > > My question is why does it wait only for the BDR? Why not the DR? It can
> when
> > > it recieves
> > > a HELLO from the DR know that their exists a DR and a BDR. Why not then
> get
> > > out of the
> > > 'Waiting' state?
> > >
> > > Thanks,
> > > John
> > >
> > > Send instant messages to your online friends
> http://uk.messenger.yahoo.com
> > >
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 15:12:21 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09169
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 15:11:57 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010502B7@cherry.ease.lsoft.com>; Thu, 19 May 2005 15:11:47 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71666895 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 15:07:19
          -0400
Received: from 208.8.0.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Thu, 19 May 2005 15:07:19 -0400
Received: from mailhub2.ind.alcatel.com (mailhub2.ind.alcatel.com
          [198.206.181.70]) by ind.alcatel.com (8.12.9/8.12.9/(postal1 2.1
          [OUT])) with ESMTP id j4JJ7HPG018515 for <OSPF@peach.ease.lsoft.com>;
          Thu, 19 May 2005 12:07:17 -0700 (PDT)
X-InterScan: Passed
Received: from mailhub2.ind.alcatel.com (localhost [127.0.0.1]) by
          mailhub2.ind.alcatel.com (8.12.10/8.12.10/(mailhub2 4.1.4 [HUB2]))
          with ESMTP id j4JJ7Gaw025855 for <OSPF@peach.ease.lsoft.com>; Thu, 19
          May 2005 12:07:17 -0700 (PDT)
Received: from omni.ind.alcatel.com ([198.206.181.20]) by
          mailhub2.ind.alcatel.com (MailFrontier 4.0.2.4693) with ESMTP; Thu,
          19 May 2005 12:07:17 -0700
Received: from Kishorepc ([128.251.40.163]) by omni.ind.alcatel.com
          (8.9.3+Sun/8.9.1 (omni 3.0 [engr-SPOOL])) with SMTP id MAA22307 for
          <OSPF@peach.ease.lsoft.com>; Thu, 19 May 2005 12:07:16 -0700 (PDT)
References: <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>           
            <1116526462.428cd77ee421b@panthermail.uwm.edu>           
            <072701c55ca2$d08ebd40$a328fb80@Kishorepc> 
            <1116528821.428ce0b537b88@panthermail.uwm.edu>
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.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mlf-Threat: nothreat
X-Mlf-Threat-Detailed: nothreat;none;list_addrbk_domain
Message-ID:  <075301c55ca6$26ce54b0$a328fb80@Kishorepc>
Date:         Thu, 19 May 2005 13:08:32 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Kishore Rao <kishore@IND.ALCATEL.COM>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Not NeighborChange but Backupseen

"If the neighbor is both declaring itself to be Designated
            Router (Hello Packet's Designated Router field = Neighbor IP
            address) and the Backup Designated Router field in the
            packet is equal to 0.0.0.0 and the receiving interface is in
            state Waiting, the receiving interface's state machine is
            scheduled with the event BackupSeen."

> I think the NeighborChange events are ignored while an interface is in
waiting
> state.
>
> Thanks,
> Mukul
>
>
> Quoting Kishore Rao <kishore@IND.ALCATEL.COM>:
>
> > The question was not about how DR or BDRs are elected. John's question
was
> > if the router should exit Wait Timer (and run DR election) on receving
Hello
> > from a router declaring itself as DR. Well, from section 10.5 it should.
> >
> > Kishore
> >
> >
> > > My guess is that if an interface comes out of the waiting state on
> > receiving a
> > > Hello from DR (without having received a Hello from BDR), it may elect
> > itself
> > > as BDR. This way many routers may elect themselves as BDR. Now all
these
> > BDR
> > > claimants (except one) will ultimately take their claims to BDRship
back
> > but in
> > > the process each router on the LAN may have to do several DR
elections.
> > >
> > > Here is a paper we wrote recently that may shed further light on this:
> > > http://cs.uwm.edu/~mukul/ospflan.pdf
> > >
> > > Thanks,
> > > Mukul
> > >
> > > Quoting John Smith <jsmith4112003@YAHOO.CO.UK>:
> > >
> > > > Hi,
> > > >
> > > > When a router comes up it starts the Wait Timer before it elects the
> > DR/BDR.
> > > > It either
> > > > waits for the Wait Timer to expire or it waits for a router
declaring
> > itself
> > > > as the BDR
> > > > before it decides that it needs to get out of the 'Waiting' state
(it
> > does
> > > > this by
> > > > generating the Backupseen event).
> > > >
> > > > My question is why does it wait only for the BDR? Why not the DR? It
can
> > when
> > > > it recieves
> > > > a HELLO from the DR know that their exists a DR and a BDR. Why not
then
> > get
> > > > out of the
> > > > 'Waiting' state?
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > Send instant messages to your online friends
> > http://uk.messenger.yahoo.com
> > > >
> >


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 15:28:36 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12996
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 15:28:35 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0105039B@cherry.ease.lsoft.com>; Thu, 19 May 2005 15:28:34 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71668047 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 15:28:33
          -0400
Received: from 129.89.169.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Thu, 19 May 2005 15:28:33 -0400
Received: from mail06.imt.uwm.edu (mail06.imt.uwm.edu [129.89.7.48]) by
          batch3.csd.uwm.edu (8.12.10/8.12.6) with ESMTP id j4JJSWDD027212 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 May 2005 14:28:32 -0500 (CDT)
Received: from localhost (pm02.imt.uwm.edu [129.89.7.62]) by mail06.imt.uwm.edu
          (8.12.10/8.12.5) with ESMTP id j4JJSVF2004494 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 May 2005 14:28:32 -0500
Received: from adsl-68-248-231-128.dsl.milwwi.ameritech.net
          (adsl-68-248-231-128.dsl.milwwi.ameritech.net [68.248.231.128]) by
          panthermail.uwm.edu (IMP) with HTTP for <mukul@localhost>; Thu, 19
          May 2005 14:28:31 -0500
References: <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>           
            <1116526462.428cd77ee421b@panthermail.uwm.edu>                     
            <072701c55ca2$d08ebd40$a328fb80@Kishorepc>            
            <1116528821.428ce0b537b88@panthermail.uwm.edu>
            <075301c55ca6$26ce54b0$a328fb80@Kishorepc>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: PantherMail 3.2.9-cvs
X-Originating-IP: 68.248.231.128
X-Virus-Scanned: by amavisd-new
X-Spam-Status: No,
               hits=-48.165 required=5
               tests=MAILTO_TO_SPAM_ADDR,NO_REAL_NAME,UWM_DOMAIN_MESSAGE_1
X-Scanned-By: MIMEDefang 2.51 on 129.89.7.48
Message-ID:  <1116530911.428ce8dfc415b@panthermail.uwm.edu>
Date:         Thu, 19 May 2005 14:28:31 -0500
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mukul Goyal <mukul@UWM.EDU>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <075301c55ca6$26ce54b0$a328fb80@Kishorepc>
Precedence: list
Content-Transfer-Encoding: 8bit

OK. So we agree that an interface comes out of waiting state on receiving a
Hello from DR IF that hello does not list any BDR. OTHERWISE an interface does
not come out of waiting state on receiving a Hello from DR.


Quoting Kishore Rao <kishore@IND.ALCATEL.COM>:

> Not NeighborChange but Backupseen
>
> "If the neighbor is both declaring itself to be Designated
>             Router (Hello Packet's Designated Router field = Neighbor IP
>             address) and the Backup Designated Router field in the
>             packet is equal to 0.0.0.0 and the receiving interface is in
>             state Waiting, the receiving interface's state machine is
>             scheduled with the event BackupSeen."
>
> > I think the NeighborChange events are ignored while an interface is in
> waiting
> > state.
> >
> > Thanks,
> > Mukul
> >
> >
> > Quoting Kishore Rao <kishore@IND.ALCATEL.COM>:
> >
> > > The question was not about how DR or BDRs are elected. John's question
> was
> > > if the router should exit Wait Timer (and run DR election) on receving
> Hello
> > > from a router declaring itself as DR. Well, from section 10.5 it should.
> > >
> > > Kishore
> > >
> > >
> > > > My guess is that if an interface comes out of the waiting state on
> > > receiving a
> > > > Hello from DR (without having received a Hello from BDR), it may elect
> > > itself
> > > > as BDR. This way many routers may elect themselves as BDR. Now all
> these
> > > BDR
> > > > claimants (except one) will ultimately take their claims to BDRship
> back
> > > but in
> > > > the process each router on the LAN may have to do several DR
> elections.
> > > >
> > > > Here is a paper we wrote recently that may shed further light on this:
> > > > http://cs.uwm.edu/~mukul/ospflan.pdf
> > > >
> > > > Thanks,
> > > > Mukul
> > > >
> > > > Quoting John Smith <jsmith4112003@YAHOO.CO.UK>:
> > > >
> > > > > Hi,
> > > > >
> > > > > When a router comes up it starts the Wait Timer before it elects the
> > > DR/BDR.
> > > > > It either
> > > > > waits for the Wait Timer to expire or it waits for a router
> declaring
> > > itself
> > > > > as the BDR
> > > > > before it decides that it needs to get out of the 'Waiting' state
> (it
> > > does
> > > > > this by
> > > > > generating the Backupseen event).
> > > > >
> > > > > My question is why does it wait only for the BDR? Why not the DR? It
> can
> > > when
> > > > > it recieves
> > > > > a HELLO from the DR know that their exists a DR and a BDR. Why not
> then
> > > get
> > > > > out of the
> > > > > 'Waiting' state?
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > > Send instant messages to your online friends
> > > http://uk.messenger.yahoo.com
> > > > >
> > >
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 15:31:31 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13220
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 15:31:30 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.01050239@cherry.ease.lsoft.com>; Thu, 19 May 2005 15:31:30 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71668749 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 15:31:29
          -0400
Received: from 208.8.0.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Thu, 19 May 2005 15:31:29 -0400
Received: from mailhub2.ind.alcatel.com (mailhub2.ind.alcatel.com
          [198.206.181.70]) by ind.alcatel.com (8.12.9/8.12.9/(postal 2.0
          [OUT])) with ESMTP id j4JJVPMd019787 for <OSPF@peach.ease.lsoft.com>;
          Thu, 19 May 2005 12:31:28 -0700 (PDT)
X-InterScan: Passed
Received: from mailhub2.ind.alcatel.com (localhost [127.0.0.1]) by
          mailhub2.ind.alcatel.com (8.12.10/8.12.10/(mailhub2 4.1.4 [HUB2]))
          with ESMTP id j4JJVOaw028044 for <OSPF@peach.ease.lsoft.com>; Thu, 19
          May 2005 12:31:24 -0700 (PDT)
Received: from omni.ind.alcatel.com ([198.206.181.20]) by
          mailhub2.ind.alcatel.com (MailFrontier 4.0.2.4693) with ESMTP; Thu,
          19 May 2005 12:31:24 -0700
Received: from Kishorepc ([128.251.40.163]) by omni.ind.alcatel.com
          (8.9.3+Sun/8.9.1 (omni 3.0 [engr-SPOOL])) with SMTP id MAA22946 for
          <OSPF@peach.ease.lsoft.com>; Thu, 19 May 2005 12:31:24 -0700 (PDT)
References: <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>           
            <1116526462.428cd77ee421b@panthermail.uwm.edu>                     
            <072701c55ca2$d08ebd40$a328fb80@Kishorepc>                       
            <1116528821.428ce0b537b88@panthermail.uwm.edu>           
            <075301c55ca6$26ce54b0$a328fb80@Kishorepc> 
            <1116530911.428ce8dfc415b@panthermail.uwm.edu>
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.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mlf-Threat: nothreat
X-Mlf-Threat-Detailed: nothreat;none;list_addrbk_domain
Message-ID:  <076701c55ca9$85bbc130$a328fb80@Kishorepc>
Date:         Thu, 19 May 2005 13:32:40 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Kishore Rao <kishore@IND.ALCATEL.COM>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Right.

> OK. So we agree that an interface comes out of waiting state on receiving
a
> Hello from DR IF that hello does not list any BDR. OTHERWISE an interface
does
> not come out of waiting state on receiving a Hello from DR.
>
>
> Quoting Kishore Rao <kishore@IND.ALCATEL.COM>:
>
> > Not NeighborChange but Backupseen
> >
> > "If the neighbor is both declaring itself to be Designated
> >             Router (Hello Packet's Designated Router field = Neighbor IP
> >             address) and the Backup Designated Router field in the
> >             packet is equal to 0.0.0.0 and the receiving interface is in
> >             state Waiting, the receiving interface's state machine is
> >             scheduled with the event BackupSeen."
> >
> > > I think the NeighborChange events are ignored while an interface is in
> > waiting
> > > state.
> > >
> > > Thanks,
> > > Mukul
> > >
> > >
> > > Quoting Kishore Rao <kishore@IND.ALCATEL.COM>:
> > >
> > > > The question was not about how DR or BDRs are elected. John's
question
> > was
> > > > if the router should exit Wait Timer (and run DR election) on
receving
> > Hello
> > > > from a router declaring itself as DR. Well, from section 10.5 it
should.
> > > >
> > > > Kishore
> > > >
> > > >
> > > > > My guess is that if an interface comes out of the waiting state on
> > > > receiving a
> > > > > Hello from DR (without having received a Hello from BDR), it may
elect
> > > > itself
> > > > > as BDR. This way many routers may elect themselves as BDR. Now all
> > these
> > > > BDR
> > > > > claimants (except one) will ultimately take their claims to
BDRship
> > back
> > > > but in
> > > > > the process each router on the LAN may have to do several DR
> > elections.
> > > > >
> > > > > Here is a paper we wrote recently that may shed further light on
this:
> > > > > http://cs.uwm.edu/~mukul/ospflan.pdf
> > > > >
> > > > > Thanks,
> > > > > Mukul
> > > > >
> > > > > Quoting John Smith <jsmith4112003@YAHOO.CO.UK>:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > When a router comes up it starts the Wait Timer before it elects
the
> > > > DR/BDR.
> > > > > > It either
> > > > > > waits for the Wait Timer to expire or it waits for a router
> > declaring
> > > > itself
> > > > > > as the BDR
> > > > > > before it decides that it needs to get out of the 'Waiting'
state
> > (it
> > > > does
> > > > > > this by
> > > > > > generating the Backupseen event).
> > > > > >
> > > > > > My question is why does it wait only for the BDR? Why not the
DR? It
> > can
> > > > when
> > > > > > it recieves
> > > > > > a HELLO from the DR know that their exists a DR and a BDR. Why
not
> > then
> > > > get
> > > > > > out of the
> > > > > > 'Waiting' state?
> > > > > >
> > > > > > Thanks,
> > > > > > John
> > > > > >
> > > > > > Send instant messages to your online friends
> > > > http://uk.messenger.yahoo.com
> > > > > >
> > > >
> >


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 15:44:58 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14604
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 15:44:57 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.01050356@cherry.ease.lsoft.com>; Thu, 19 May 2005 15:44:57 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71669868 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 15:44:56
          -0400
Received: from 207.217.121.248 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Thu, 19 May 2005 15:44:56 -0400
Received: from h-68-164-85-18.snvacaid.dynamic.covad.net ([68.164.85.18]
          helo=earthlink.net) by pop-a065d01.pas.sa.earthlink.net with esmtp
          (Exim 3.36 #10) id 1DYqwx-0002wS-00 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 19 May 2005 12:44:55 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>
            <1116526462.428cd77ee421b@panthermail.uwm.edu>
            <072701c55ca2$d08ebd40$a328fb80@Kishorepc>
            <1116528821.428ce0b537b88@panthermail.uwm.edu>
            <075301c55ca6$26ce54b0$a328fb80@Kishorepc>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <428CEE56.186604C1@earthlink.net>
Date:         Thu, 19 May 2005 12:51:50 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Sorry,

	I have to kind of disagree on two accounts with the
	spec vs implimentations..

	First, if the interface is a passive interface. I
	think passives interfaces are after the spec, thus
	it fits as an exception. But in my opinion, passive
	interfaces have a equiv as a infinite waiting
	period.

	Second, "in the case where more than 1 router"
	is declaring itself as the DR, shouldn't enough 
	time pass (1.5 to 2x) hello interval pass to identify
	this situation before exiting wait state and
	poss determine whether 2-ways are forming.  Yes,
	it could/should exit early, but on that first 
	hello???

	Thus, this section of the spec covers the rare simple 
	case where no BDR has yet been elected or is eligible
	to be elected.

	Mitchell Erblich
	-----------------
	
	

Kishore Rao wrote:
> 
> Not NeighborChange but Backupseen
> 
> "If the neighbor is both declaring itself to be Designated
>             Router (Hello Packet's Designated Router field = Neighbor IP
>             address) and the Backup Designated Router field in the
>             packet is equal to 0.0.0.0 and the receiving interface is in
>             state Waiting, the receiving interface's state machine is
>             scheduled with the event BackupSeen."
> 
> > I think the NeighborChange events are ignored while an interface is in
> waiting
> > state.
> >
> > Thanks,
> > Mukul
> >
> >
> > Quoting Kishore Rao <kishore@IND.ALCATEL.COM>:
> >
> > > The question was not about how DR or BDRs are elected. John's question
> was
> > > if the router should exit Wait Timer (and run DR election) on receving
> Hello
> > > from a router declaring itself as DR. Well, from section 10.5 it should.
> > >
> > > Kishore
> > >
> > >
> > > > My guess is that if an interface comes out of the waiting state on
> > > receiving a
> > > > Hello from DR (without having received a Hello from BDR), it may elect
> > > itself
> > > > as BDR. This way many routers may elect themselves as BDR. Now all
> these
> > > BDR
> > > > claimants (except one) will ultimately take their claims to BDRship
> back
> > > but in
> > > > the process each router on the LAN may have to do several DR
> elections.
> > > >
> > > > Here is a paper we wrote recently that may shed further light on this:
> > > > http://cs.uwm.edu/~mukul/ospflan.pdf
> > > >
> > > > Thanks,
> > > > Mukul
> > > >
> > > > Quoting John Smith <jsmith4112003@YAHOO.CO.UK>:
> > > >
> > > > > Hi,
> > > > >
> > > > > When a router comes up it starts the Wait Timer before it elects the
> > > DR/BDR.
> > > > > It either
> > > > > waits for the Wait Timer to expire or it waits for a router
> declaring
> > > itself
> > > > > as the BDR
> > > > > before it decides that it needs to get out of the 'Waiting' state
> (it
> > > does
> > > > > this by
> > > > > generating the Backupseen event).
> > > > >
> > > > > My question is why does it wait only for the BDR? Why not the DR? It
> can
> > > when
> > > > > it recieves
> > > > > a HELLO from the DR know that their exists a DR and a BDR. Why not
> then
> > > get
> > > > > out of the
> > > > > 'Waiting' state?
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > > Send instant messages to your online friends
> > > http://uk.messenger.yahoo.com
> > > > >
> > >


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 17:24:33 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02686
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 17:24:33 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.010506D3@cherry.ease.lsoft.com>; Thu, 19 May 2005 17:24:31 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71679600 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 17:24:29
          -0400
Received: from 208.8.0.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Thu, 19 May 2005 17:24:29 -0400
Received: from mailhub2.ind.alcatel.com (mailhub2.ind.alcatel.com
          [198.206.181.70]) by ind.alcatel.com (8.12.9/8.12.9/(postal1 2.1
          [OUT])) with ESMTP id j4JLOTPG021447 for <OSPF@peach.ease.lsoft.com>;
          Thu, 19 May 2005 14:24:29 -0700 (PDT)
X-InterScan: Passed
Received: from mailhub2.ind.alcatel.com (localhost [127.0.0.1]) by
          mailhub2.ind.alcatel.com (8.12.10/8.12.10/(mailhub2 4.1.4 [HUB2]))
          with ESMTP id j4JLOSaw008912 for <OSPF@peach.ease.lsoft.com>; Thu, 19
          May 2005 14:24:28 -0700 (PDT)
Received: from omni.ind.alcatel.com ([198.206.181.20]) by
          mailhub2.ind.alcatel.com (MailFrontier 4.0.2.4693) with ESMTP; Thu,
          19 May 2005 14:24:28 -0700
Received: from Kishorepc ([128.251.40.163]) by omni.ind.alcatel.com
          (8.9.3+Sun/8.9.1 (omni 3.0 [engr-SPOOL])) with SMTP id OAA25832 for
          <OSPF@peach.ease.lsoft.com>; Thu, 19 May 2005 14:24:28 -0700 (PDT)
References: <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>           
            <1116526462.428cd77ee421b@panthermail.uwm.edu>           
            <072701c55ca2$d08ebd40$a328fb80@Kishorepc>           
            <1116528821.428ce0b537b88@panthermail.uwm.edu>           
            <075301c55ca6$26ce54b0$a328fb80@Kishorepc> 
            <428CEE56.186604C1@earthlink.net>
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.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mlf-Threat: nothreat
X-Mlf-Threat-Detailed: nothreat;none;list_addrbk_domain
Message-ID:  <079301c55cb9$514775b0$a328fb80@Kishorepc>
Date:         Thu, 19 May 2005 15:25:44 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Kishore Rao <kishore@IND.ALCATEL.COM>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

> Second, "in the case where more than 1 router"
> is declaring itself as the DR, shouldn't enough
> time pass (1.5 to 2x) hello interval pass to identify
> this situation before exiting wait state and
> poss determine whether 2-ways are forming.  Yes,
> it could/should exit early, but on that first
> hello???

A possible case of A & B declaring themselves as DR would be when comm. b/n
them is broken; in which case shouldn't router C prefer to elect itself as
BDR ASAP on receiving the hello from either A or B instead of waiting for a
longer period of time without the possiblity of neither A or B being elected
BDR during that time ?

>
> Thus, this section of the spec covers the rare simple
> case where no BDR has yet been elected or is eligible
> to be elected.
>
> Mitchell Erblich
> -----------------
>
>
>
> Kishore Rao wrote:
> >
> > Not NeighborChange but Backupseen
> >
> > "If the neighbor is both declaring itself to be Designated
> >             Router (Hello Packet's Designated Router field = Neighbor IP
> >             address) and the Backup Designated Router field in the
> >             packet is equal to 0.0.0.0 and the receiving interface is in
> >             state Waiting, the receiving interface's state machine is
> >             scheduled with the event BackupSeen."
> >
> > > I think the NeighborChange events are ignored while an interface is in
> > waiting
> > > state.
> > >
> > > Thanks,
> > > Mukul
> > >
> > >
> > > Quoting Kishore Rao <kishore@IND.ALCATEL.COM>:
> > >
> > > > The question was not about how DR or BDRs are elected. John's
question
> > was
> > > > if the router should exit Wait Timer (and run DR election) on
receving
> > Hello
> > > > from a router declaring itself as DR. Well, from section 10.5 it
should.
> > > >
> > > > Kishore
> > > >
> > > >
> > > > > My guess is that if an interface comes out of the waiting state on
> > > > receiving a
> > > > > Hello from DR (without having received a Hello from BDR), it may
elect
> > > > itself
> > > > > as BDR. This way many routers may elect themselves as BDR. Now all
> > these
> > > > BDR
> > > > > claimants (except one) will ultimately take their claims to
BDRship
> > back
> > > > but in
> > > > > the process each router on the LAN may have to do several DR
> > elections.
> > > > >
> > > > > Here is a paper we wrote recently that may shed further light on
this:
> > > > > http://cs.uwm.edu/~mukul/ospflan.pdf
> > > > >
> > > > > Thanks,
> > > > > Mukul
> > > > >
> > > > > Quoting John Smith <jsmith4112003@YAHOO.CO.UK>:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > When a router comes up it starts the Wait Timer before it elects
the
> > > > DR/BDR.
> > > > > > It either
> > > > > > waits for the Wait Timer to expire or it waits for a router
> > declaring
> > > > itself
> > > > > > as the BDR
> > > > > > before it decides that it needs to get out of the 'Waiting'
state
> > (it
> > > > does
> > > > > > this by
> > > > > > generating the Backupseen event).
> > > > > >
> > > > > > My question is why does it wait only for the BDR? Why not the
DR? It
> > can
> > > > when
> > > > > > it recieves
> > > > > > a HELLO from the DR know that their exists a DR and a BDR. Why
not
> > then
> > > > get
> > > > > > out of the
> > > > > > 'Waiting' state?
> > > > > >
> > > > > > Thanks,
> > > > > > John
> > > > > >
> > > > > > Send instant messages to your online friends
> > > > http://uk.messenger.yahoo.com
> > > > > >
> > > >


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 22:12:19 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00368
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 22:12:19 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.01050E10@cherry.ease.lsoft.com>; Thu, 19 May 2005 22:12:18 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71700963 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 22:12:17
          -0400
Received: from 217.12.10.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Thu, 19 May 2005 22:12:16 -0400
Received: (qmail 46168 invoked by uid 60001); 20 May 2005 02:12:16 -0000
Received: from [66.17.149.13] by web25310.mail.ukl.yahoo.com via HTTP; Fri, 20
          May 2005 03:12:16 BST
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <20050520021216.46166.qmail@web25310.mail.ukl.yahoo.com>
Date:         Fri, 20 May 2005 03:12:16 +0100
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: John Smith <jsmith4112003@YAHOO.CO.UK>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit

Hi Mukul,

Extending the same logic cant we say that an if an interface comes out of waiting state
on recieving a Hello from a BDR then it may elect itself as the DR. Okay .. I think i
understand this.

A network will *always* have a DR even if its this single router. So we are sure that if
we recieve a HELLO from the BDR then it will *always* list the DR. SO we now know the
identity of the DR and the BDR.

But, if i recieve a HELLO from the DR cant i look at the BDR field and know that there
exists a BDR and declare that same router as the BDR? OR is the assumption that unless i
hear from that BDR i cannot confirm that its still up. Is this it?

Pretty confused,
John

Mukul Said :

My guess is that if an interface comes out of the waiting state on receiving a
Hello from DR (without having received a Hello from BDR), it may elect itself
as BDR. This way many routers may elect themselves as BDR. Now all these BDR
claimants (except one) will ultimately take their claims to BDRship back but in
the process each router on the LAN may have to do several DR elections.

Here is a paper we wrote recently that may shed further light on this:
http://cs.uwm.edu/~mukul/ospflan.pdf

Thanks,
Mukul




		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 23:06:44 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04924
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 23:06:43 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.010510E4@cherry.ease.lsoft.com>; Thu, 19 May 2005 23:06:44 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71708128 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 23:06:42
          -0400
Received: from 207.217.121.252 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Thu, 19 May 2005 23:06:42 -0400
Received: from h-68-164-85-18.snvacaid.dynamic.covad.net ([68.164.85.18]
          helo=earthlink.net) by pop-a065d14.pas.sa.earthlink.net with esmtp
          (Exim 3.36 #10) id 1DYxqT-0007Gh-00 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 19 May 2005 20:06:41 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>
            <1116526462.428cd77ee421b@panthermail.uwm.edu>
            <072701c55ca2$d08ebd40$a328fb80@Kishorepc>
            <1116528821.428ce0b537b88@panthermail.uwm.edu>
            <075301c55ca6$26ce54b0$a328fb80@Kishorepc>
            <428CEE56.186604C1@earthlink.net>
            <079301c55cb9$514775b0$a328fb80@Kishorepc>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <428D4F61.10D00DA4@earthlink.net>
Date:         Thu, 19 May 2005 19:45:53 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

What is b/n them is broken?

Combine areas and former entry/exit interfaces between
the areas will result in two or more DRs announcements
per pseudonode.

This is taken care of in the Spec? Can anyone find the
section? :-)

Mitchell Erblich
-------------------------

Kishore Rao wrote:
> 
> > Second, "in the case where more than 1 router"
> > is declaring itself as the DR, shouldn't enough
> > time pass (1.5 to 2x) hello interval pass to identify
> > this situation before exiting wait state and
> > poss determine whether 2-ways are forming.  Yes,
> > it could/should exit early, but on that first
> > hello???
> 
> A possible case of A & B declaring themselves as DR would be when comm. b/n
> them is broken; in which case shouldn't router C prefer to elect itself as
> BDR ASAP on receiving the hello from either A or B instead of waiting for a
> longer period of time without the possiblity of neither A or B being elected
> BDR during that time ?
> 
> >
> > Thus, this section of the spec covers the rare simple
> > case where no BDR has yet been elected or is eligible
> > to be elected.
> >
> > Mitchell Erblich
> > -----------------
> >
> >
> >
> > Kishore Rao wrote:
> > >
> > > Not NeighborChange but Backupseen
> > >
> > > "If the neighbor is both declaring itself to be Designated
> > >             Router (Hello Packet's Designated Router field = Neighbor IP
> > >             address) and the Backup Designated Router field in the
> > >             packet is equal to 0.0.0.0 and the receiving interface is in
> > >             state Waiting, the receiving interface's state machine is
> > >             scheduled with the event BackupSeen."
> > >
> > > > I think the NeighborChange events are ignored while an interface is in
> > > waiting
> > > > state.
> > > >
> > > > Thanks,
> > > > Mukul
> > > >
> > > >
> > > > Quoting Kishore Rao <kishore@IND.ALCATEL.COM>:
> > > >
> > > > > The question was not about how DR or BDRs are elected. John's
> question
> > > was
> > > > > if the router should exit Wait Timer (and run DR election) on
> receving
> > > Hello
> > > > > from a router declaring itself as DR. Well, from section 10.5 it
> should.
> > > > >
> > > > > Kishore
> > > > >
> > > > >
> > > > > > My guess is that if an interface comes out of the waiting state on
> > > > > receiving a
> > > > > > Hello from DR (without having received a Hello from BDR), it may
> elect
> > > > > itself
> > > > > > as BDR. This way many routers may elect themselves as BDR. Now all
> > > these
> > > > > BDR
> > > > > > claimants (except one) will ultimately take their claims to
> BDRship
> > > back
> > > > > but in
> > > > > > the process each router on the LAN may have to do several DR
> > > elections.
> > > > > >
> > > > > > Here is a paper we wrote recently that may shed further light on
> this:
> > > > > > http://cs.uwm.edu/~mukul/ospflan.pdf
> > > > > >
> > > > > > Thanks,
> > > > > > Mukul
> > > > > >
> > > > > > Quoting John Smith <jsmith4112003@YAHOO.CO.UK>:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > When a router comes up it starts the Wait Timer before it elects
> the
> > > > > DR/BDR.
> > > > > > > It either
> > > > > > > waits for the Wait Timer to expire or it waits for a router
> > > declaring
> > > > > itself
> > > > > > > as the BDR
> > > > > > > before it decides that it needs to get out of the 'Waiting'
> state
> > > (it
> > > > > does
> > > > > > > this by
> > > > > > > generating the Backupseen event).
> > > > > > >
> > > > > > > My question is why does it wait only for the BDR? Why not the
> DR? It
> > > can
> > > > > when
> > > > > > > it recieves
> > > > > > > a HELLO from the DR know that their exists a DR and a BDR. Why
> not
> > > then
> > > > > get
> > > > > > > out of the
> > > > > > > 'Waiting' state?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > John
> > > > > > >
> > > > > > > Send instant messages to your online friends
> > > > > http://uk.messenger.yahoo.com
> > > > > > >
> > > > >


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu May 19 23:11:44 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05187
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 May 2005 23:11:43 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010510AD@cherry.ease.lsoft.com>; Thu, 19 May 2005 23:11:32 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71709046 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 May 2005 23:11:31
          -0400
Received: from 207.217.121.252 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Thu, 19 May 2005 23:11:31 -0400
Received: from h-68-164-85-18.snvacaid.dynamic.covad.net ([68.164.85.18]
          helo=earthlink.net) by pop-a065d14.pas.sa.earthlink.net with esmtp
          (Exim 3.36 #10) id 1DYxv8-0000Hg-00 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 19 May 2005 20:11:30 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <20050520021216.46166.qmail@web25310.mail.ukl.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <428D505D.23FC11D1@earthlink.net>
Date:         Thu, 19 May 2005 19:50:05 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

John Smith,

	First...
	No. A DR/BDR capable interface doesn't need
	to have a DR and/or a BDR.

	If a single router exists, it can configure
	itself not to elect itself as the DR. Normally
	setting its priority to a set value.

	Mitchell Erblich
	------------------------

John Smith wrote:
> 
> Hi Mukul,
> 
> Extending the same logic cant we say that an if an interface comes out of waiting state
> on recieving a Hello from a BDR then it may elect itself as the DR. Okay .. I think i
> understand this.
> 
> A network will *always* have a DR even if its this single router. So we are sure that if
> we recieve a HELLO from the BDR then it will *always* list the DR. SO we now know the
> identity of the DR and the BDR.
> 
> But, if i recieve a HELLO from the DR cant i look at the BDR field and know that there
> exists a BDR and declare that same router as the BDR? OR is the assumption that unless i
> hear from that BDR i cannot confirm that its still up. Is this it?
> 
> Pretty confused,
> John
> 
> Mukul Said :
> 
> My guess is that if an interface comes out of the waiting state on receiving a
> Hello from DR (without having received a Hello from BDR), it may elect itself
> as BDR. This way many routers may elect themselves as BDR. Now all these BDR
> claimants (except one) will ultimately take their claims to BDRship back but in
> the process each router on the LAN may have to do several DR elections.
> 
> Here is a paper we wrote recently that may shed further light on this:
> http://cs.uwm.edu/~mukul/ospflan.pdf
> 
> Thanks,
> Mukul
> 
> 
> ___________________________________________________________
> How much free photo storage do you get? Store your holiday
> snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri May 20 08:49:16 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09859
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 May 2005 08:49:15 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0105190C@cherry.ease.lsoft.com>; Fri, 20 May 2005 8:49:14 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71772954 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 20 May 2005 08:49:04
          -0400
Received: from 129.89.169.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Fri, 20 May 2005 08:49:04 -0400
Received: from mail02.imt.uwm.edu (mail02.imt.uwm.edu [129.89.7.44]) by
          batch3.csd.uwm.edu (8.12.10/8.12.6) with ESMTP id j4KCn4DD020061 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 20 May 2005 07:49:04 -0500 (CDT)
Received: from localhost (pm05.imt.uwm.edu [129.89.7.65]) by mail02.imt.uwm.edu
          (8.12.10/8.12.5) with ESMTP id j4KCn3sB019548 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 20 May 2005 07:49:03 -0500
Received: from adsl-68-248-231-128.dsl.milwwi.ameritech.net
          (adsl-68-248-231-128.dsl.milwwi.ameritech.net [68.248.231.128]) by
          panthermail.uwm.edu (IMP) with HTTP for <mukul@localhost>; Fri, 20
          May 2005 07:49:03 -0500
References: <20050520021216.46166.qmail@web25310.mail.ukl.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: PantherMail 3.2.9-cvs
X-Originating-IP: 68.248.231.128
X-Virus-Scanned: by amavisd-new
X-Spam-Status: No,
               hits=-50.329 required=5
               tests=BAYES_00,NO_REAL_NAME,UWM_DOMAIN_MESSAGE_1
X-Scanned-By: MIMEDefang 2.51 on 129.89.7.44
Message-ID:  <1116593343.428ddcbf643a6@panthermail.uwm.edu>
Date:         Fri, 20 May 2005 07:49:03 -0500
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mukul Goyal <mukul@UWM.EDU>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <20050520021216.46166.qmail@web25310.mail.ukl.yahoo.com>
Precedence: list
Content-Transfer-Encoding: 8bit

Hi John,

> Extending the same logic cant we say that an if an interface comes out of
> waiting state
> on recieving a Hello from a BDR then it may elect itself as the DR. Okay .. I
> think i
> understand this.

Suppose router A comes out of waiting state on receiving BDRship claim from
router B. If router A has not received any claim to DRship yet, it will elect
router B as BDR (assuming B is the only claimant to BDRship) and DR as well (no
claimant for DRship; choose BDR as DR). So, router A can not elect itself as
DR.

>
> A network will *always* have a DR even if its this single router. So we are
> sure that if
> we recieve a HELLO from the BDR then it will *always* list the DR. SO we now
> know the
> identity of the DR and the BDR.

Exactly. A router can elect itself as BDR only if there is some other router
that claims DRship.

>
> But, if i recieve a HELLO from the DR cant i look at the BDR field and know
> that there
> exists a BDR and declare that same router as the BDR? OR is the assumption
> that unless i
> hear from that BDR i cannot confirm that its still up. Is this it?

Well, consider the scenario where router X comes up on the LAN at time 0, 
router Y comes up at time 20 and router Z (with higher Router ID than router Y)
comes up at time 40. At time 40, just after router Z comes up, router X comes
out of the waiting state, elects itself as DR and router Y as BDR. Router X
will not elect router Z as BDR since it has not yet established bidirectional
comunication with router Z. At this time, routers Y and Z are still in the
waiting state. Router Y will come out of waiting state at time 60 and would
have established bidirectional communication with router Z by this time. So, at
time 60, rouer Y will elect router Z as BDR (since router Z has a higher Router
ID than router Y). So, even though router X thinks (until it has established
bidirectional communication with router Z) that router Y is BDR, this is not
actually the case.

So, you are right, unless I hear a BDRship claim from a router itself, I can not
be sure that this router indeed claims BDRship.

Thanks,
Mukul

>
> Pretty confused,
> John
>
> Mukul Said :
>
> My guess is that if an interface comes out of the waiting state on receiving
> a
> Hello from DR (without having received a Hello from BDR), it may elect itself
> as BDR. This way many routers may elect themselves as BDR. Now all these BDR
> claimants (except one) will ultimately take their claims to BDRship back but
> in
> the process each router on the LAN may have to do several DR elections.
>
> Here is a paper we wrote recently that may shed further light on this:
> http://cs.uwm.edu/~mukul/ospflan.pdf
>
> Thanks,
> Mukul
>
>
>
>
>
> ___________________________________________________________
> How much free photo storage do you get? Store your holiday
> snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri May 20 13:09:11 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08698
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 May 2005 13:09:10 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.01051EE7@cherry.ease.lsoft.com>; Fri, 20 May 2005 13:09:07 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71815282 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 20 May 2005 13:09:05
          -0400
Received: from 208.8.0.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Fri, 20 May 2005 13:09:05 -0400
Received: from mailhub1.ind.alcatel.com (mailhub1.ind.alcatel.com
          [198.206.181.170]) by ind.alcatel.com (8.12.9/8.12.9/(postal1 2.1
          [OUT])) with ESMTP id j4KH94PG015166 for <OSPF@peach.ease.lsoft.com>;
          Fri, 20 May 2005 10:09:04 -0700 (PDT)
X-InterScan: Passed
Received: from mailhub1.ind.alcatel.com (localhost [127.0.0.1]) by
          mailhub1.ind.alcatel.com (8.12.10/8.12.10/(mailhub1 4.1.4 [HUB1]))
          with ESMTP id j4KH913l010401 for <OSPF@peach.ease.lsoft.com>; Fri, 20
          May 2005 10:09:01 -0700 (PDT)
Received: from omni.ind.alcatel.com ([198.206.181.20]) by
          mailhub1.ind.alcatel.com (MailFrontier 4.0.2.4693) with ESMTP; Fri,
          20 May 2005 10:09:01 -0700
Received: from Kishorepc ([128.251.40.163]) by omni.ind.alcatel.com
          (8.9.3+Sun/8.9.1 (omni 3.0 [engr-SPOOL])) with SMTP id KAA15948 for
          <OSPF@peach.ease.lsoft.com>; Fri, 20 May 2005 10:08:59 -0700 (PDT)
References: <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>           
            <1116526462.428cd77ee421b@panthermail.uwm.edu>           
            <072701c55ca2$d08ebd40$a328fb80@Kishorepc>           
            <1116528821.428ce0b537b88@panthermail.uwm.edu>           
            <075301c55ca6$26ce54b0$a328fb80@Kishorepc>           
            <428CEE56.186604C1@earthlink.net>           
            <079301c55cb9$514775b0$a328fb80@Kishorepc> 
            <428D4F61.10D00DA4@earthlink.net>
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.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mlf-Threat: nothreat
X-Mlf-Threat-Detailed: nothreat;none;list_addrbk_domain
Message-ID:  <003f01c55d5e$d3a9d980$a328fb80@Kishorepc>
Date:         Fri, 20 May 2005 11:10:28 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Kishore Rao <kishore@IND.ALCATEL.COM>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

> What is b/n them is broken?

Comunication between them is broken.

>
> Combine areas and former entry/exit interfaces between
> the areas will result in two or more DRs announcements
> per pseudonode.
>
> This is taken care of in the Spec? Can anyone find the
> section? :-)

Section F: Multiple interfaces to the same network/subnet.

I could not find any other section other than this.

F:  says both the interface should be taken care of together so that there
are no
multiple DRs elected by the same router. In your case, DRs were elected by
two different routers,
which I think could happen only if they have no communication beween them ?

Kishore

>
> Mitchell Erblich
> -------------------------
>
> Kishore Rao wrote:
> >
> > > Second, "in the case where more than 1 router"
> > > is declaring itself as the DR, shouldn't enough
> > > time pass (1.5 to 2x) hello interval pass to identify
> > > this situation before exiting wait state and
> > > poss determine whether 2-ways are forming.  Yes,
> > > it could/should exit early, but on that first
> > > hello???
> >
> > A possible case of A & B declaring themselves as DR would be when comm.
b/n
> > them is broken; in which case shouldn't router C prefer to elect itself
as
> > BDR ASAP on receiving the hello from either A or B instead of waiting
for a
> > longer period of time without the possiblity of neither A or B being
elected
> > BDR during that time ?
> >
> > >
> > > Thus, this section of the spec covers the rare simple
> > > case where no BDR has yet been elected or is eligible
> > > to be elected.
> > >
> > > Mitchell Erblich
> > > -----------------
> > >
> > >
> > >
> > > Kishore Rao wrote:
> > > >
> > > > Not NeighborChange but Backupseen
> > > >
> > > > "If the neighbor is both declaring itself to be Designated
> > > >             Router (Hello Packet's Designated Router field =
Neighbor IP
> > > >             address) and the Backup Designated Router field in the
> > > >             packet is equal to 0.0.0.0 and the receiving interface
is in
> > > >             state Waiting, the receiving interface's state machine
is
> > > >             scheduled with the event BackupSeen."
> > > >
> > > > > I think the NeighborChange events are ignored while an interface
is in
> > > > waiting
> > > > > state.
> > > > >
> > > > > Thanks,
> > > > > Mukul
> > > > >
> > > > >
> > > > > Quoting Kishore Rao <kishore@IND.ALCATEL.COM>:
> > > > >
> > > > > > The question was not about how DR or BDRs are elected. John's
> > question
> > > > was
> > > > > > if the router should exit Wait Timer (and run DR election) on
> > receving
> > > > Hello
> > > > > > from a router declaring itself as DR. Well, from section 10.5 it
> > should.
> > > > > >
> > > > > > Kishore
> > > > > >
> > > > > >
> > > > > > > My guess is that if an interface comes out of the waiting
state on
> > > > > > receiving a
> > > > > > > Hello from DR (without having received a Hello from BDR), it
may
> > elect
> > > > > > itself
> > > > > > > as BDR. This way many routers may elect themselves as BDR. Now
all
> > > > these
> > > > > > BDR
> > > > > > > claimants (except one) will ultimately take their claims to
> > BDRship
> > > > back
> > > > > > but in
> > > > > > > the process each router on the LAN may have to do several DR
> > > > elections.
> > > > > > >
> > > > > > > Here is a paper we wrote recently that may shed further light
on
> > this:
> > > > > > > http://cs.uwm.edu/~mukul/ospflan.pdf
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Mukul
> > > > > > >
> > > > > > > Quoting John Smith <jsmith4112003@YAHOO.CO.UK>:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > When a router comes up it starts the Wait Timer before it
elects
> > the
> > > > > > DR/BDR.
> > > > > > > > It either
> > > > > > > > waits for the Wait Timer to expire or it waits for a router
> > > > declaring
> > > > > > itself
> > > > > > > > as the BDR
> > > > > > > > before it decides that it needs to get out of the 'Waiting'
> > state
> > > > (it
> > > > > > does
> > > > > > > > this by
> > > > > > > > generating the Backupseen event).
> > > > > > > >
> > > > > > > > My question is why does it wait only for the BDR? Why not
the
> > DR? It
> > > > can
> > > > > > when
> > > > > > > > it recieves
> > > > > > > > a HELLO from the DR know that their exists a DR and a BDR.
Why
> > not
> > > > then
> > > > > > get
> > > > > > > > out of the
> > > > > > > > 'Waiting' state?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > John
> > > > > > > >
> > > > > > > > Send instant messages to your online friends
> > > > > > http://uk.messenger.yahoo.com
> > > > > > > >
> > > > > >


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri May 20 14:41:12 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22624
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 May 2005 14:41:12 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.01051EA0@cherry.ease.lsoft.com>; Fri, 20 May 2005 14:41:11 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71826424 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 20 May 2005 14:41:08
          -0400
Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Fri, 20 May 2005 14:41:08 -0400
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com
          with ESMTP; 20 May 2005 11:41:08 -0700
Received: from smirtorawxp (dhcp-171-69-101-3.cisco.com [171.69.101.3]) by
          sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4KIf5nC005639 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 20 May 2005 11:41:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcVcV7lRJiTghrxKSCC+EArwiICO9QAMxjkQ
Message-ID:  <200505201841.j4KIf5nC005639@sj-core-4.cisco.com>
Date:         Fri, 20 May 2005 11:41:05 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Sina Mirtorabi <sina@CISCO.COM>
Subject: Re: Comments on draft-ietf-ospf-mt-ospfv3-00
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <2E60260A5637C2448841A5F60A6F9B033F75C6@enfimail1.datcon.co.uk>
Precedence: list
Content-Transfer-Encoding: 7bit

Alan,

 
-> Comments and Doubts
-> -------------------
-> 
-> 1.  I think that the draft probably requires an "IANA considerations"
-> section.  You may need to request a new address space for 
-> the MT values.
-> You may also need to request a space for TLV and sub-TLV type values.

Ok 

-> 
-> 2.  Currently, the scope of the TLV types is restricted to 
-> the containing LSA.  I wonder if having globally unique TLV 
-> types would simplify code, for example, for protocol analysis.

Right, on the other hand restricting TLV type to a given LSA (i.e. define
same type in different LSA) give more Type space for use and also removes
any possibility of expecting the "wrong" TLV in the wrong LSA type. That
said we are not against of changing that to global scope

-> 
-> 3.  I have some doubts about the S-bit in the value field of 
-> TLVs to indicate the presence of sub-TLVs.
-> 
-> -  I am not convinced that the S-bit is necessary; an 
-> implementation either recognizes a TLV type or it does not.  
-> In my opinion, if the implementation recognizes the TLV then 
-> it knows if sub-TLVs are present.
-> If the implementation does not recognize the TLV type then 
-> the TLV is ignored.  Either way, the S-bit does not appear 
-> to be necessary.

sub-TLV may appear in value filed of TLV, without the S bit you would not be
able to tell if the next field correspond to sub-TLV or is yet another value
field in TLV

-> 
-> -  I may be misinterpreting the draft, but it appears to be 
-> inconsistent in its specification of the use of the S-bit.  
-> Section 6 states that the S-bit is set in the value field of 
-> TLVs.  However, 
-> 
-> 	o	the extended LSA formats in section 20 do not define the
-> S-bit.  For example, in section 20.1, the extended 
-> Router-LSA LD-TLV has sub-TLVs defined but the S-bit does 
-> not appear in the definition of the LD-TLV.

The S bit is present whenever the presence of sub-TLV is optional, for
E-router-LSA, Link-description (LD) TLV is a mandatory sub-TLV


-> 	o	section 20.1 defines a Router Multi-Topology *sub-TLV*
-> with an S-bit shown.  What is the purpose of the S-bit in 
-> the sub-TLV?

This allows nesting of sub-TLVs to deeper levels, e.g. define extension
under MT

-> 
-> 4.  I also have doubts as to whether the "Total sub-TLV 
-> length" field defined in section 6. is needed.  I think that
-> 
-> -  an implementation can use the sub-TLV length fields to 
-> skip to the next value

Total sub-tlv length is useful when the value field in the TLV is more than
one (and multiple sub-TLV are present). This is the only way to get to the
next Value within the same TLV.

-> -  the "Total sub-TLV length" is only useful if there are 
-> multiple sub-TLVs that an implementation does not process.
-> 
-> 5.  I am confused over whether the default topology MUST be 
-> defined using non-extended LSAs or if it MAY be defined 
-> using extended LSAs.

In order to interoperate, by default rfc2740compatibility is set to enable
and existing LSA is used for default topology, once all routers are MT
capable new LSA could be used for default topology

-> 
-> -  Section 7. states that "In order to interact with non-MT 
-> capable routers we define default topology as the topology 
-> that is built by using the existing LSAs as specified in 
-> OSPFv3 [OSPFv3]."
-> 
-> -  Section 8. states that "When a MT capable router 
-> participates in Default Topology, depending on 
-> RFC2740Compatibility (see Appendix A) it will generate 
-> existing LSAs or extended LSAs for the Default Topology."
-> 
-> I suggest removing the first paragraph of Section 7.

We could add that the default topology is the topology that is built by
either using existing LSA or using extended LSA with MT-ID#0

-> 
-> 6.  Section 11., paragraph 2 states that "(and all routers 
-> should be MT capable)".  I think that this should be "MUST 
-> be MT capable".

Ok

-> 
-> 7.  Section 20.1 states the following.
-> 
-> 	We define a Router Multi-Topology sub-TLV (RMT-sTLV) 
-> below. This sub-TLV could further contain sub-TLVs.
-> 
-> I think that it may be better to define the RMT-sTLV without 
-> the possibility of further sub-TLVs.  If future extensions 
-> are required then they can be added as separate sub-TLVs of 
-> the LD-TLV.

You need that in order to define extension under each MT

-> 
-> 8.  Section 20.5 states the following.
-> 
-> 	Note that when the sub-TLV is present (S-bit set in the
-> PrefixOptions) the 
-> 	sub-TLV is placed after Forwarding address and external 
-> route Tag if they are present.
-> 
-> I think that it is not possible to tell if the Forwarding 
-> address and external route Tag are present if a sub-TLV is 
-> placed inside the EMT-TLV.  

Why not? The presence of Tag, FA, Sub-TLV explicitly marked with the
corresponding bits (i.e. T, F, S)

-> 
-> Better to define the MT-TLV as not having any sub-TLVs.  Any 
-> future additions can be made as separate TLVs.

Again you need sub-TLV to define extension under each MT

-> 
-> Questions
-> ---------
-> 
-> 1.  Do you expect any new LSAs defined in the future to have 
-> the T-bit set in the LS type field?

If it is defined to interact with MT extension, yes

-> 
-> 2.  Can passive interfaces be configured on a per-MT basis?  
-> That is, can a single interface be configured to appear as a 
-> passive interface in some MT, not to appear at all in other 
-> MT and, maybe, be an active interface in other MT.

Yes, when the interface is passive in a given topology, there is no
adjacency advertised in e-router-LSA but simply the prefix is advertised in
e-intra-area-prefix-LSA

-> 
-> 3.  The Extended Inter-Area-Prefix-LSA, Extended 
-> AS-External-LSA, Extended Link-LSA and Extended 
-> Intra-Area-Prefix-LSA include a prefix block.  Is there any 
-> reason why this is not defined as a TLV?  In the draft, it 
-> has no type field, only a length.  The meaning must be 
-> deduced from its position in the LSA.

It is more compact and there is really no need to carry a type, all we want
is to define TLV under each Prefix address and being able to define the next
block. That said we are not against changing the prefix block to TLV (and
its TLV would become sub-TLV...)

-> 
-> 4.  There are 2 places in the draft where the phrase "the 
-> only top level TLV defined by this document" is used, in 
-> sections 20.1 and 20.4.
-> Should this read "the only top level TLV defined by this 
-> document for this LSA"?

Ok

-> 
-> Minor Editorial Comments
-> ------------------------

Will change that

Thanks
Sina


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri May 20 15:50:05 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04968
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 May 2005 15:50:05 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.01052176@cherry.ease.lsoft.com>; Fri, 20 May 2005 15:49:03 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71831812 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 20 May 2005 15:49:01
          -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Fri, 20 May 2005 15:39:01 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id PAA01251; Fri, 20 May 2005 15:38:58
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200505201938.PAA01251@ietf.org>
Date:         Fri, 20 May 2005 15:38:58 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ospf-ospfv3-traffic-05.txt
Comments: To: i-d-announce@ietf.org
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.

	Title		: Traffic Engineering Extensions to OSPF version 3
	Author(s)	: K. Ishiguro, et al.
	Filename	: draft-ietf-ospf-ospfv3-traffic-05.txt
	Pages		: 17
	Date		: 2005-5-20
	
This document describes extensions to OSPFv3 to support intra-area
   Traffic Engineering (TE).  This document extends OSPFv2 TE to handle
   IPv6 networks.  A new TLV and several new sub-TLVs are defined to
   support IPv6 networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-traffic-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ospf-ospfv3-traffic-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ospf-ospfv3-traffic-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2005-5-20154622.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-ospfv3-traffic-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ospf-ospfv3-traffic-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2005-5-20154622.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@PEACH.EASE.LSOFT.COM  Sat May 21 12:39:55 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04700
	for <ospf-archive@LISTS.IETF.ORG>; Sat, 21 May 2005 12:39:55 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.01053DCF@cherry.ease.lsoft.com>; Sat, 21 May 2005 12:39:55 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          71959383 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 21 May 2005 12:39:52
          -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Sat, 21 May 2005 12:39:52 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com
          with ESMTP; 21 May 2005 12:39:52 -0400
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 j4LGdnl6020350 for <OSPF@PEACH.EASE.LSOFT.COM>; Sat, 21 May 2005
          12:39:49 -0400 (EDT)
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); Sat,
          21 May 2005 12:39:49 -0400
Received: from [10.82.242.200] ([10.82.242.200]) by xfe-rtp-202.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Sat, 21 May 2005 12:39:48 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 May 2005 16:39:49.0000 (UTC)
                       FILETIME=[B4327880:01C55E23]
Message-ID:  <428F6453.7030405@cisco.com>
Date:         Sat, 21 May 2005 12:39:47 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Working Group Last Call for "Traffic Engineering Extensions to OSPF version 3"
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

A couple weeks back I asked if anyone had any objections
to last calling this document. Heretofore, I have received
none. Also, I believe there is at least one commercially
available implementation.

Hence, without further ado, this is the start of a
OSPF Working Group last call for:

Traffic Engineering Extensions to OSPF version 3"
(draft-ietf-ospf-ospfv3-traffic-04.txt).

All comments should be sent to this list by
12 AM (EDT), 06/07/2005.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-traffic-05.txt

Thanks,
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May 23 06:43:19 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12096
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 May 2005 06:43:19 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.010563DA@cherry.ease.lsoft.com>; Mon, 23 May 2005 6:43:18 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72164807 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 May 2005 06:43:17
          -0400
Received: from 80.168.70.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Mon, 23 May 2005 06:33:16 -0400
Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id
          1DaAFI-0000Cg-9V; Mon, 23 May 2005 11:33:16 +0100
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Remote_Addr: 156.106.205.33
Message-ID:  <E1DaAFI-0000Cg-9V@oceanus.uk.clara.net>
Date:         Mon, 23 May 2005 11:33:16 +0100
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Adrian Farrel <olddog@CLARA.CO.UK>
Subject: Re: Working Group Last Call for "Traffic Engineering Extensions to OSPF version 3"
Comments: cc: adrian@olddog.co.uk
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi, 

Two comments... 

1. Would it be possible to clarify the behavior if the scope is
  set to some value other than 01? Is it a requirement that the
  scope be ignored in that case, that TE information be allowed
  to be flooded out of the area, or that the LSA is rejected? 

  Given the setting of the U-bit, this may be hard to control
  properly and I suspect the best you can do is say MUST
  be transmitted as 01 and SHOULD only be flooded within
  the area. 

2. Section 4 - Router IPv6 Address TLV 

  "The Router IPv6 Address TLV has type 3, length 16, and a value
   containing a 16 octet local IPv6 address.  It MUST appear in exactly
   one Traffic Engineering LSA originated by an OSPFv3 router supporting
   the TE extensions." 

  I am confused by 'MUST appear in exactly one'.
  Can a router advertise multiple Router addresses? (Hint, please talk to
  the CCAMP ASON Routing design team for a very good reason why the answer
  is "yes".)
  Can a TE LSA contain "orphaned" TLVs? I.e. can we have a continuation TE
  LSA that does not carry a Router Address TLV?
  Given that a router has (probably) more than one "stable IPv6 address
  that is always reachable if there is connectivity to the OSPFv3 router"
  must all of these be advertised in Router Address TLVs? 

  The text needs to cover all of these questions. 

Cheers,
Adrian


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May 23 09:02:05 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22548
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 May 2005 09:02:05 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.010566C4@cherry.ease.lsoft.com>; Mon, 23 May 2005 9:02:03 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72192850 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 May 2005 09:02:01
          -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Mon, 23 May 2005 09:02:01 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com
          with ESMTP; 23 May 2005 09:02:02 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
          [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP
          id j4ND1q52002262 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 23 May 2005
          09:01:59 -0400 (EDT)
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); Mon,
          23 May 2005 09:01:55 -0400
Received: from [10.82.242.200] ([10.82.242.200]) by xfe-rtp-201.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 09:01:54 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <E1DaAFI-0000Cg-9V@oceanus.uk.clara.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 May 2005 13:01:55.0029 (UTC)
                       FILETIME=[98545050:01C55F97]
Message-ID:  <4291D442.4090700@cisco.com>
Date:         Mon, 23 May 2005 09:01:54 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: Working Group Last Call for "Traffic Engineering Extensions to OSPF version 3"
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <E1DaAFI-0000Cg-9V@oceanus.uk.clara.net>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Adrian,

Adrian Farrel wrote:

> Hi,
> Two comments...
> 1. Would it be possible to clarify the behavior if the scope is
>  set to some value other than 01? Is it a requirement that the
>  scope be ignored in that case, that TE information be allowed
>  to be flooded out of the area, or that the LSA is rejected?
>  Given the setting of the U-bit, this may be hard to control
>  properly and I suspect the best you can do is say MUST
>  be transmitted as 01 and SHOULD only be flooded within
>  the area.

I'll change the text to say the flooding scope MUST be set to 01. This
is enough since flooding outside the orginating area would not
be compliant with OSPFv3.

> 2. Section 4 - Router IPv6 Address TLV
>  "The Router IPv6 Address TLV has type 3, length 16, and a value
>   containing a 16 octet local IPv6 address.  It MUST appear in exactly
>   one Traffic Engineering LSA originated by an OSPFv3 router supporting
>   the TE extensions."
>  I am confused by 'MUST appear in exactly one'.
>  Can a router advertise multiple Router addresses? (Hint, please talk to
>  the CCAMP ASON Routing design team for a very good reason why the answer
>  is "yes".)

The intent is that there is at least one stable routable address for the 
OSPF TE router.
There is a proposal to advertise multiple addresses using the TE Node 
Address TLV.


>  Can a TE LSA contain "orphaned" TLVs? I.e. can we have a continuation TE
>  LSA that does not carry a Router Address TLV?

I don't understand this - each TE LSA has a unique LSID. An OSPFv3 router
can originate multiples per area.

>  Given that a router has (probably) more than one "stable IPv6 address
>  that is always reachable if there is connectivity to the OSPFv3 router"
>  must all of these be advertised in Router Address TLVs?

I think the TE node address TLV is meant to advertise additional
addresses. At one time, this TLV was to take on the function of the
Router IPv6 Address TLV. However, it was felt that have a single
preferred router address was preferable. Here is a link to the TE node
address draft:

http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-02.txt

Thanks,
Acee

>
>  The text needs to cover all of these questions.
> Cheers,
> Adrian
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May 23 15:55:36 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06215
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 May 2005 15:55:35 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.01056C07@cherry.ease.lsoft.com>; Mon, 23 May 2005 15:55:35 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72231815 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 May 2005 15:55:20
          -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Mon, 23 May 2005 15:45:20 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id PAA03257; Mon, 23 May 2005 15:45:18
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200505231945.PAA03257@ietf.org>
Date:         Mon, 23 May 2005 15:45:18 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ospf-cap-07.txt
Comments: To: i-d-announce@ietf.org
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.

	Title		: Extensions to OSPF for Advertising Optional Router 
			  Capabilities
	Author(s)	: A. Lindem, et al.
	Filename	: draft-ietf-ospf-cap-07.txt
	Pages		: 14
	Date		: 2005-5-23
	
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to
   know the capabilities of their neighbors and other routers in the
   routing domain.  This draft proposes extensions to OSPFv2 and OSPFv3
   for advertising optional router capabilities.  A new Router
   Information (RI) LSA is proposed for this purpose.  In OSPFv2, the RI
   LSA will be implemented with a new opaque LSA type ID.  In OSPFv3,
   the RI LSA will be implemented with a new LSA type function code.  In
   both protocols, the RI LSA can be advertised at any of the defined
   flooding scopes (link, area, or AS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-07.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ospf-cap-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ospf-cap-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2005-5-23145017.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-cap-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ospf-cap-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2005-5-23145017.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May 25 04:44:56 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19414
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 May 2005 04:44:55 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0105A3FC@cherry.ease.lsoft.com>; Wed, 25 May 2005 4:44:53 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72428155 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 May 2005 04:44:51
          -0400
Received: from 207.69.195.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Wed, 25 May 2005 04:44:51 -0400
Received: from h-68-164-85-18.snvacaid.dynamic.covad.net ([68.164.85.18]
          helo=earthlink.net) by pop-savannah.atl.sa.earthlink.net with esmtp
          (Exim 3.36 #10) id 1DarVS-0002zi-00 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 25 May 2005 04:44:50 -0400
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <20050519122021.40976.qmail@web25301.mail.ukl.yahoo.com>
            <1116526462.428cd77ee421b@panthermail.uwm.edu>
            <072701c55ca2$d08ebd40$a328fb80@Kishorepc>
            <1116528821.428ce0b537b88@panthermail.uwm.edu>
            <075301c55ca6$26ce54b0$a328fb80@Kishorepc>
            <428CEE56.186604C1@earthlink.net>
            <079301c55cb9$514775b0$a328fb80@Kishorepc>
            <428D4F61.10D00DA4@earthlink.net>
            <003f01c55d5e$d3a9d980$a328fb80@Kishorepc>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <42943CD9.971A7D1C@earthlink.net>
Date:         Wed, 25 May 2005 01:52:41 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: Waiting State Question
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Kishore Rao,

	Sorry for the late response.
	Lets see. Oh...

	Adj communciation causing a split area can
	be done intentionally and un-intentionally...
	
	One might intentionally impliment a dual or more
	routing paths thru an area because..

	  One wishes to support the equiv of a VPN where
	  each group uses a diff MD5 auth.

	  OSPF does not offically support unequal cost
	  paths and thus alternate routes would be
	  unused without MPLS.

	  We wish to minimize the number of routers
	  within a grouping.

	  we wish to minimize the number of LSAs per
	  group.

	  We wish to only inject routes from other
	  routing protcols into one group.

	  We wish to support a different set of routers
	  per ISP and maybe have a limited number of
	  merge points.

	  We wish to support a subset of routers for
	  only transit traffic..

	  We wish to support a very fast hello interval
	  for one group and that functionally or someother
	  functionally is ONLY supported by a subset of
	  the routers..

	  etc...

	And unintentionally because one or more adj early
	  adj formation parameters, (hello fields) are diff,
	  thus dropping the hello pkt..

	  Because a full adj is unstable and past history
	  is delaying our newest adj formation.

	  Or,,, because we are in the latency time period
	  before we identify that we have two DRs..

	OR, because the new router / DR on that interface
	has a higher capability and we would rather have
	a re-election of DR, versus taking down all the
	routers for dead router interval..

	OR  ... 

	But it is too simple to declare "because the
	adj is broken".. It is because their are MANY
	reasons.


	Mitchell Erblich
	----------------------
	

	

Kishore Rao wrote:
> 
> > What is b/n them is broken?
> 
> Comunication between them is broken.
> 
> >
> > Combine areas and former entry/exit interfaces between
> > the areas will result in two or more DRs announcements
> > per pseudonode.
> >
> > This is taken care of in the Spec? Can anyone find the
> > section? :-)
> 
> Section F: Multiple interfaces to the same network/subnet.
> 
> I could not find any other section other than this.
> 
> F:  says both the interface should be taken care of together so that there
> are no
> multiple DRs elected by the same router. In your case, DRs were elected by
> two different routers,
> which I think could happen only if they have no communication beween them ?
> 
> Kishore
> 
> >
> > Mitchell Erblich
> > -------------------------
> >
> > Kishore Rao wrote:
> > >
> > > > Second, "in the case where more than 1 router"
> > > > is declaring itself as the DR, shouldn't enough
> > > > time pass (1.5 to 2x) hello interval pass to identify
> > > > this situation before exiting wait state and
> > > > poss determine whether 2-ways are forming.  Yes,
> > > > it could/should exit early, but on that first
> > > > hello???
> > >
> > > A possible case of A & B declaring themselves as DR would be when comm.
> b/n
> > > them is broken; in which case shouldn't router C prefer to elect itself
> as
> > > BDR ASAP on receiving the hello from either A or B instead of waiting
> for a
> > > longer period of time without the possiblity of neither A or B being
> elected
> > > BDR during that time ?
> > >
> > > >
> > > > Thus, this section of the spec covers the rare simple
> > > > case where no BDR has yet been elected or is eligible
> > > > to be elected.
> > > >
> > > > Mitchell Erblich
> > > > -----------------
> > > >
> > > >
> > > >
> > > > Kishore Rao wrote:
> > > > >
> > > > > Not NeighborChange but Backupseen
> > > > >
> > > > > "If the neighbor is both declaring itself to be Designated
> > > > >             Router (Hello Packet's Designated Router field =
> Neighbor IP
> > > > >             address) and the Backup Designated Router field in the
> > > > >             packet is equal to 0.0.0.0 and the receiving interface
> is in
> > > > >             state Waiting, the receiving interface's state machine
> is
> > > > >             scheduled with the event BackupSeen."
> > > > >
> > > > > > I think the NeighborChange events are ignored while an interface
> is in
> > > > > waiting
> > > > > > state.
> > > > > >
> > > > > > Thanks,
> > > > > > Mukul
> > > > > >
> > > > > >
> > > > > > Quoting Kishore Rao <kishore@IND.ALCATEL.COM>:
> > > > > >
> > > > > > > The question was not about how DR or BDRs are elected. John's
> > > question
> > > > > was
> > > > > > > if the router should exit Wait Timer (and run DR election) on
> > > receving
> > > > > Hello
> > > > > > > from a router declaring itself as DR. Well, from section 10.5 it
> > > should.
> > > > > > >
> > > > > > > Kishore
> > > > > > >
> > > > > > >
> > > > > > > > My guess is that if an interface comes out of the waiting
> state on
> > > > > > > receiving a
> > > > > > > > Hello from DR (without having received a Hello from BDR), it
> may
> > > elect
> > > > > > > itself
> > > > > > > > as BDR. This way many routers may elect themselves as BDR. Now
> all
> > > > > these
> > > > > > > BDR
> > > > > > > > claimants (except one) will ultimately take their claims to
> > > BDRship
> > > > > back
> > > > > > > but in
> > > > > > > > the process each router on the LAN may have to do several DR
> > > > > elections.
> > > > > > > >
> > > > > > > > Here is a paper we wrote recently that may shed further light
> on
> > > this:
> > > > > > > > http://cs.uwm.edu/~mukul/ospflan.pdf
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Mukul
> > > > > > > >
> > > > > > > > Quoting John Smith <jsmith4112003@YAHOO.CO.UK>:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > When a router comes up it starts the Wait Timer before it
> elects
> > > the
> > > > > > > DR/BDR.
> > > > > > > > > It either
> > > > > > > > > waits for the Wait Timer to expire or it waits for a router
> > > > > declaring
> > > > > > > itself
> > > > > > > > > as the BDR
> > > > > > > > > before it decides that it needs to get out of the 'Waiting'
> > > state
> > > > > (it
> > > > > > > does
> > > > > > > > > this by
> > > > > > > > > generating the Backupseen event).
> > > > > > > > >
> > > > > > > > > My question is why does it wait only for the BDR? Why not
> the
> > > DR? It
> > > > > can
> > > > > > > when
> > > > > > > > > it recieves
> > > > > > > > > a HELLO from the DR know that their exists a DR and a BDR.
> Why
> > > not
> > > > > then
> > > > > > > get
> > > > > > > > > out of the
> > > > > > > > > 'Waiting' state?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > John
> > > > > > > > >
> > > > > > > > > Send instant messages to your online friends
> > > > > > > http://uk.messenger.yahoo.com
> > > > > > > > >
> > > > > > >


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May 25 10:25:31 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16178
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 May 2005 10:25:30 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0105AE25@cherry.ease.lsoft.com>; Wed, 25 May 2005 10:25:30 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72493386 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 May 2005 10:25:26
          -0400
Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Wed, 25 May 2005 10:25:26 -0400
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com
          (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with
          ESMTP id <0IH100BLQUTRKF@szxga03-in.huawei.com> for
          OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 May 2005 22:27:27 +0800 (CST)
Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet
          Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id
          <0IH100001UTR4N@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 25 May 2005 22:27:27 +0800 (CST)
Received: from dell60 ([10.18.4.202]) by szxml02-in.huawei.com (iPlanet
          Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id
          <0IH100NOKUXZ4I@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 25 May 2005 22:30:00 +0800 (CST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook, Build 10.0.4024
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Message-ID:  <000001c56135$9cb892b0$ca04120a@china.huawei.com>
Date:         Wed, 25 May 2005 19:55:33 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: sujay <sujayg@HUAWEI.COM>
Subject: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <42943CD9.971A7D1C@earthlink.net>
Precedence: list
Content-Transfer-Encoding: 7BIT

Hi All,

Considering RFC3623, Graceful Restart for OSPF V2 I have a problem;

Ex:

  (network)---- DUT ---- RTA

(All in the same area)

Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's to
RTA and other routers in the 'network'

At the instant RTA recvs the Grace-LSA it also goes down.

Is there a way in the RFC 3623 specified as to how DUT could 
Detect this topology change and Exit GR *before* grace period expiry??

For other routers in the network RTA is still reachable and traffic 
Will be eventually dropped.

Kindly correct me,

Regds,
Ashok/Sujay


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May 25 11:02:56 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19408
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 May 2005 11:02:56 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0105B002@cherry.ease.lsoft.com>; Wed, 25 May 2005 11:02:57 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72495754 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 May 2005 11:02:52
          -0400
Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Wed, 25 May 2005 11:02:51 -0400
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com
          with ESMTP; 25 May 2005 08:02:52 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
          [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP
          id j4PF2j3Q027448 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 25 May 2005
          08:02:46 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
          xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed,
          25 May 2005 08:02:43 -0700
Received: from [192.168.0.2] ([10.21.83.168]) by xfe-sjc-212.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 08:02:43 -0700
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000001c56135$9cb892b0$ca04120a@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 May 2005 15:02:43.0676 (UTC)
                       FILETIME=[CDAF91C0:01C5613A]
Message-ID:  <42949392.3060002@cisco.com>
Date:         Wed, 25 May 2005 08:02:42 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Padma Pillay-Esnault <ppe@CISCO.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <000001c56135$9cb892b0$ca04120a@china.huawei.com>
Precedence: list
Content-Transfer-Encoding: 7bit

sujay wrote:

>Hi All,
>
>Considering RFC3623, Graceful Restart for OSPF V2 I have a problem;
>
>Ex:
>
>  (network)---- DUT ---- RTA
>
>(All in the same area)
>
>Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's to
>RTA and other routers in the 'network'
>
>At the instant RTA recvs the Grace-LSA it also goes down.
>
>Is there a way in the RFC 3623 specified as to how DUT could 
>Detect this topology change and Exit GR *before* grace period expiry??
>  
>
I do not think the RFC covers this case. You are in a double failure 
situation.

I can think of a simple solution. When DUT reacquires its router-lsa. It 
can determine its previous
neighbors. It can then decide that if within DeadRouterInterval that 
neighbor did not  respond
to hellos to abort GR. This would be equivalent to the normal situation 
when a router goes down and its
neigbors takes DeadInterval to bring down their adjacency

Padma.

>For other routers in the network RTA is still reachable and traffic 
>Will be eventually dropped.
>
>Kindly correct me,
>
>Regds,
>Ashok/Sujay
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May 25 12:11:23 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24515
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 May 2005 12:11:22 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0105B0D6@cherry.ease.lsoft.com>; Wed, 25 May 2005 12:11:22 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72503258 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 May 2005 12:11:14
          -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Wed, 25 May 2005 12:11:11 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com
          with ESMTP; 25 May 2005 12:11:11 -0400
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 j4PGB252023143 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 25 May 2005
          12:11:09 -0400 (EDT)
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,
          25 May 2005 12:10:41 -0400
Received: from [10.82.224.4] ([10.82.224.4]) by xfe-rtp-202.amer.cisco.com with
          Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 12:10:41 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000001c56135$9cb892b0$ca04120a@china.huawei.com>
            <42949392.3060002@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 May 2005 16:10:41.0143 (UTC)
                       FILETIME=[4C0BA870:01C56144]
Message-ID:  <4294A37E.2000000@cisco.com>
Date:         Wed, 25 May 2005 12:10:38 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <42949392.3060002@cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Padma Pillay-Esnault wrote:

> sujay wrote:
>
>> Hi All,
>>
>> Considering RFC3623, Graceful Restart for OSPF V2 I have a problem;
>>
>> Ex:
>>
>>  (network)---- DUT ---- RTA
>>
>> (All in the same area)
>>
>> Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's to
>> RTA and other routers in the 'network'
>>
>> At the instant RTA recvs the Grace-LSA it also goes down.
>>
>> Is there a way in the RFC 3623 specified as to how DUT could Detect 
>> this topology change and Exit GR *before* grace period expiry??
>>  
>>
> I do not think the RFC covers this case. You are in a double failure 
> situation.
>
> I can think of a simple solution. When DUT reacquires its router-lsa. 
> It can determine its previous
> neighbors. It can then decide that if within DeadRouterInterval that 
> neighbor did not  respond
> to hellos to abort GR. This would be equivalent to the normal 
> situation when a router goes down and its
> neigbors takes DeadInterval to bring down their adjacency

I agree completely with Padma. One point, if RTA comes back up and 
originates a new router LSA
then the DUT will detect the inconsistency (as specified in RFC 3623) 
with it's pre-restart LSA and
terminate graceful restart. 


>
> Padma.
>
>> For other routers in the network RTA is still reachable and traffic 
>> Will be eventually dropped.
>>
>> Kindly correct me,
>>
>> Regds,
>> Ashok/Sujay
>>
>>  
>>
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May 25 13:49:30 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04099
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 May 2005 13:49:29 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0105B27B@cherry.ease.lsoft.com>; Wed, 25 May 2005 13:49:27 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72510390 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 May 2005 13:49:23
          -0400
Received: from 208.8.0.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Wed, 25 May 2005 13:49:23 -0400
Received: from mailhub2.ind.alcatel.com (mailhub2.ind.alcatel.com
          [198.206.181.70]) by ind.alcatel.com (8.12.9/8.12.9/(postal 2.0
          [OUT])) with ESMTP id j4PHnMMd023000 for <OSPF@peach.ease.lsoft.com>;
          Wed, 25 May 2005 10:49:22 -0700 (PDT)
X-InterScan: Passed
Received: from mailhub2.ind.alcatel.com (localhost [127.0.0.1]) by
          mailhub2.ind.alcatel.com (8.12.10/8.12.10/(mailhub2 4.1.4 [HUB2]))
          with ESMTP id j4PHnMaw005421 for <OSPF@peach.ease.lsoft.com>; Wed, 25
          May 2005 10:49:22 -0700 (PDT)
Received: from omni.ind.alcatel.com ([198.206.181.20]) by
          mailhub2.ind.alcatel.com (MailFrontier 4.0.2.4693) with ESMTP; Wed,
          25 May 2005 10:49:22 -0700
Received: from Kishorepc ([128.251.40.163]) by omni.ind.alcatel.com
          (8.9.3+Sun/8.9.1 (omni 3.0 [engr-SPOOL])) with SMTP id KAA11311 for
          <OSPF@peach.ease.lsoft.com>; Wed, 25 May 2005 10:49:21 -0700 (PDT)
References: <000001c56135$9cb892b0$ca04120a@china.huawei.com>           
            <42949392.3060002@cisco.com>  <4294A37E.2000000@cisco.com>
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.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mlf-Threat: nothreat
X-Mlf-Threat-Detailed: nothreat;none;list_addrbk_domain
Message-ID:  <03e201c56152$44214210$a328fb80@Kishorepc>
Date:         Wed, 25 May 2005 11:50:39 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Kishore Rao <kishore@IND.ALCATEL.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Acee Lindem" <acee@cisco.com>
To: <OSPF@peach.ease.lsoft.com>
Sent: Wednesday, May 25, 2005 10:10 AM
Subject: Re: Exit-Graceful Restart Condition


> Padma Pillay-Esnault wrote:
>
> > sujay wrote:
> >
> >> Hi All,
> >>
> >> Considering RFC3623, Graceful Restart for OSPF V2 I have a problem;
> >>
> >> Ex:
> >>
> >>  (network)---- DUT ---- RTA
> >>
> >> (All in the same area)
> >>
> >> Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's to
> >> RTA and other routers in the 'network'
> >>
> >> At the instant RTA recvs the Grace-LSA it also goes down.
> >>
> >> Is there a way in the RFC 3623 specified as to how DUT could Detect
> >> this topology change and Exit GR *before* grace period expiry??
> >>
> >>
> > I do not think the RFC covers this case. You are in a double failure
> > situation.
> >
> > I can think of a simple solution. When DUT reacquires its router-lsa.
> > It can determine its previous
> > neighbors. It can then decide that if within DeadRouterInterval that
> > neighbor did not  respond
> > to hellos to abort GR. This would be equivalent to the normal
> > situation when a router goes down and its
> > neigbors takes DeadInterval to bring down their adjacency
>
> I agree completely with Padma. One point, if RTA comes back up and
> originates a new router LSA
> then the DUT will detect the inconsistency (as specified in RFC 3623)
> with it's pre-restart LSA and
> terminate graceful restart.

Acee,

Will this work ?
In case there is another router RTB, scan the Hello from RTB for all
neighbors on the network and then make sure Hello from RTA has been received
within a Hello interval + 2 (say) . If not, exit GR.

This would be faster than using the reacquired Router and Network LSAs to
determine the neighbors, isnt it ?

Kishore


>
>
> >
> > Padma.
> >
> >> For other routers in the network RTA is still reachable and traffic
> >> Will be eventually dropped.
> >>
> >> Kindly correct me,
> >>
> >> Regds,
> >> Ashok/Sujay
> >>
> >>
> >>
> >


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May 25 13:54:26 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04396
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 May 2005 13:54:26 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0105B42B@cherry.ease.lsoft.com>; Wed, 25 May 2005 13:54:25 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72510735 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 May 2005 13:54:24
          -0400
Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Wed, 25 May 2005 13:54:24 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com
          with ESMTP; 25 May 2005 10:54:24 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
          [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP
          id j4PHrlmK020520 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 25 May 2005
          10:54:18 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
          xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed,
          25 May 2005 10:54:21 -0700
Received: from [192.168.0.2] ([10.21.83.168]) by xfe-sjc-212.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 10:54:21 -0700
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000001c56135$9cb892b0$ca04120a@china.huawei.com>                  
            <42949392.3060002@cisco.com>  <4294A37E.2000000@cisco.com>
            <03e201c56152$44214210$a328fb80@Kishorepc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 May 2005 17:54:21.0051 (UTC)
                       FILETIME=[C7664CB0:01C56152]
Message-ID:  <4294BBCC.5010607@cisco.com>
Date:         Wed, 25 May 2005 10:54:20 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Padma Pillay-Esnault <ppe@CISCO.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <03e201c56152$44214210$a328fb80@Kishorepc>
Precedence: list
Content-Transfer-Encoding: 7bit

Kishore Rao wrote:

>----- Original Message ----- 
>From: "Acee Lindem" <acee@cisco.com>
>To: <OSPF@peach.ease.lsoft.com>
>Sent: Wednesday, May 25, 2005 10:10 AM
>Subject: Re: Exit-Graceful Restart Condition
>
>
>  
>
>>Padma Pillay-Esnault wrote:
>>
>>    
>>
>>>sujay wrote:
>>>
>>>      
>>>
>>>>Hi All,
>>>>
>>>>Considering RFC3623, Graceful Restart for OSPF V2 I have a problem;
>>>>
>>>>Ex:
>>>>
>>>> (network)---- DUT ---- RTA
>>>>
>>>>(All in the same area)
>>>>
>>>>Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's to
>>>>RTA and other routers in the 'network'
>>>>
>>>>At the instant RTA recvs the Grace-LSA it also goes down.
>>>>
>>>>Is there a way in the RFC 3623 specified as to how DUT could Detect
>>>>this topology change and Exit GR *before* grace period expiry??
>>>>
>>>>
>>>>        
>>>>
>>>I do not think the RFC covers this case. You are in a double failure
>>>situation.
>>>
>>>I can think of a simple solution. When DUT reacquires its router-lsa.
>>>It can determine its previous
>>>neighbors. It can then decide that if within DeadRouterInterval that
>>>neighbor did not  respond
>>>to hellos to abort GR. This would be equivalent to the normal
>>>situation when a router goes down and its
>>>neigbors takes DeadInterval to bring down their adjacency
>>>      
>>>
>>I agree completely with Padma. One point, if RTA comes back up and
>>originates a new router LSA
>>then the DUT will detect the inconsistency (as specified in RFC 3623)
>>with it's pre-restart LSA and
>>terminate graceful restart.
>>    
>>
>
>Acee,
>
>Will this work ?
>In case there is another router RTB, scan the Hello from RTB for all
>neighbors on the network and then make sure Hello from RTA has been received
>within a Hello interval + 2 (say) . If not, exit GR.
>  
>
It is not clear to me. Do you mean that RTB has the same neighbors as 
DUT and is on the same network link ?

Padma

>This would be faster than using the reacquired Router and Network LSAs to
>determine the neighbors, isnt it ?
>
>Kishore
>
>
>  
>
>>    
>>
>>>Padma.
>>>
>>>      
>>>
>>>>For other routers in the network RTA is still reachable and traffic
>>>>Will be eventually dropped.
>>>>
>>>>Kindly correct me,
>>>>
>>>>Regds,
>>>>Ashok/Sujay
>>>>
>>>>
>>>>
>>>>        
>>>>
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May 25 14:32:00 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06974
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 May 2005 14:32:00 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0105B45D@cherry.ease.lsoft.com>; Wed, 25 May 2005 14:31:59 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72514611 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 May 2005 14:31:57
          -0400
Received: from 64.233.184.195 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Wed, 25 May 2005 14:21:55 -0400
Received: by wproxy.gmail.com with SMTP id 58so578471wri for
          <OSPF@peach.ease.lsoft.com>; Wed, 25 May 2005 11:21:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
                     h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
                     b=s3zcIMjtScNIrXAGddCZrNTjRbUC/+8ucweMfXlRyqJ2+flVxA6jCgDkTEjqt0IHCLz6oAl3oxJgY0dX9A8woeVUNdkOncOcSR6Dn+f7VBrva7RjYTNe1w4/x5B7SWn1AhUwlpaEEOQsun+UjmfltPou1cYxErOTU4PhtMBy6VQ=
Received: by 10.54.45.2 with SMTP id s2mr1400226wrs; Wed, 25 May 2005 11:21:55
          -0700 (PDT)
Received: by 10.54.46.73 with HTTP; Wed, 25 May 2005 11:21:55 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <000001c56135$9cb892b0$ca04120a@china.huawei.com>
            <42949392.3060002@cisco.com> <4294A37E.2000000@cisco.com>
Message-ID:  <4dbb3ecf05052511211a3138e6@mail.gmail.com>
Date:         Wed, 25 May 2005 23:51:55 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: ashok holla <ashok.holla@GMAIL.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <4294A37E.2000000@cisco.com>
Precedence: list
Content-Transfer-Encoding: quoted-printable

Hi,
When myself and Sujay raised this issue, we thought about the
possibility which Pama and Acee suggested.
However, this will not work in all cases.

Consider:

TOPO------------------------ DUT---------------------------RTA
          Area0                                Area1
In this case, DUT will not get his pre-restart router of Area 1 as
there no other router in the area to give it to him.
Therefore, this solution fails.=20
In this case, suppose DUT had run the spf, he would have seen that the
type-3 summary lsa he had advertised into area 0, is no longer
consistent with the topology and then could have exited GR. However,
this consistensy check can be done only after grace period terminates
as RTA MAY come up within that time.
So, for this case, there seems to be no solution.

However, it does seem to be worthwhile to start deadTimers for all
nbrs listed in the pre-restart router lsa when we get it for the first
time.  (even though we have not received hello pkts from them). When
any inactivity timer fires on the restarting router, he can quit GR.
This can be done to impro convergence incase, topology is unstable.

Is our understanding correct?

regards,
Ashok/Sujay


On 5/25/05, Acee Lindem <acee@cisco.com> wrote:
> Padma Pillay-Esnault wrote:
>=20
> > sujay wrote:
> >
> >> Hi All,
> >>
> >> Considering RFC3623, Graceful Restart for OSPF V2 I have a problem;
> >>
> >> Ex:
> >>
> >>  (network)---- DUT ---- RTA
> >>
> >> (All in the same area)
> >>
> >> Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's to
> >> RTA and other routers in the 'network'
> >>
> >> At the instant RTA recvs the Grace-LSA it also goes down.
> >>
> >> Is there a way in the RFC 3623 specified as to how DUT could Detect
> >> this topology change and Exit GR *before* grace period expiry??
> >>
> >>
> > I do not think the RFC covers this case. You are in a double failure
> > situation.
> >
> > I can think of a simple solution. When DUT reacquires its router-lsa.
> > It can determine its previous
> > neighbors. It can then decide that if within DeadRouterInterval that
> > neighbor did not  respond
> > to hellos to abort GR. This would be equivalent to the normal
> > situation when a router goes down and its
> > neigbors takes DeadInterval to bring down their adjacency
>=20
> I agree completely with Padma. One point, if RTA comes back up and
> originates a new router LSA
> then the DUT will detect the inconsistency (as specified in RFC 3623)
> with it's pre-restart LSA and
> terminate graceful restart.
>=20
>=20
> >
> > Padma.
> >
> >> For other routers in the network RTA is still reachable and traffic
> >> Will be eventually dropped.
> >>
> >> Kindly correct me,
> >>
> >> Regds,
> >> Ashok/Sujay
> >>
> >>
> >>
> >
>=20


--=20
Best regards,
Ashok Chandrashekar Holla


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May 25 14:46:55 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07841
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 May 2005 14:46:55 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0105B3AC@cherry.ease.lsoft.com>; Wed, 25 May 2005 14:46:55 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72515923 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 May 2005 14:46:53
          -0400
Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Wed, 25 May 2005 14:46:53 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com
          with ESMTP; 25 May 2005 11:46:53 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
          [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP
          id j4PIk2mY028816 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 25 May 2005
          11:46:49 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
          xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed,
          25 May 2005 11:46:50 -0700
Received: from [192.168.0.2] ([10.21.83.168]) by xfe-sjc-212.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 11:46:49 -0700
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000001c56135$9cb892b0$ca04120a@china.huawei.com>           
            <42949392.3060002@cisco.com> <4294A37E.2000000@cisco.com>
            <4dbb3ecf05052511211a3138e6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 May 2005 18:46:50.0035 (UTC)
                       FILETIME=[1C572030:01C5615A]
Message-ID:  <4294C810.4030608@cisco.com>
Date:         Wed, 25 May 2005 11:46:40 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Padma Pillay-Esnault <ppe@CISCO.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <4dbb3ecf05052511211a3138e6@mail.gmail.com>
Precedence: list
Content-Transfer-Encoding: 7bit

ashok holla wrote:

>Hi,
>When myself and Sujay raised this issue, we thought about the
>possibility which Pama and Acee suggested.
>However, this will not work in all cases.
>
>Consider:
>
>TOPO------------------------ DUT---------------------------RTA
>          Area0                                Area1
>In this case, DUT will not get his pre-restart router of Area 1 as
>there no other router in the area to give it to him.
>Therefore, this solution fails. 
>In this case, suppose DUT had run the spf, he would have seen that the
>type-3 summary lsa he had advertised into area 0, is no longer
>consistent with the topology and then could have exited GR. However,
>this consistensy check can be done only after grace period terminates
>as RTA MAY come up within that time.
>So, for this case, there seems to be no solution.
>  
>
You have not taken into account one major premise in thr rfc -
For graceful restart to success you MUST have a helper to enable you to 
recover.
In the case above you have
1. A double failure
2. No helper in the area

With 2 - There can be no GR restart in the first place. Optimizing the 
detection is not possible if you do not even
 have the list of your previous neighbors.

>However, it does seem to be worthwhile to start deadTimers for all
>nbrs listed in the pre-restart router lsa when we get it for the first
>time.  (even though we have not received hello pkts from them). When
>any inactivity timer fires on the restarting router, he can quit GR.
>This can be done to impro convergence incase, topology is unstable.
>
>  
>
I would put that as an option rather than a "must".

Padma

>Is our understanding correct?
>
>regards,
>Ashok/Sujay
>
>
>On 5/25/05, Acee Lindem <acee@cisco.com> wrote:
>  
>
>>Padma Pillay-Esnault wrote:
>>
>>    
>>
>>>sujay wrote:
>>>
>>>      
>>>
>>>>Hi All,
>>>>
>>>>Considering RFC3623, Graceful Restart for OSPF V2 I have a problem;
>>>>
>>>>Ex:
>>>>
>>>> (network)---- DUT ---- RTA
>>>>
>>>>(All in the same area)
>>>>
>>>>Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's to
>>>>RTA and other routers in the 'network'
>>>>
>>>>At the instant RTA recvs the Grace-LSA it also goes down.
>>>>
>>>>Is there a way in the RFC 3623 specified as to how DUT could Detect
>>>>this topology change and Exit GR *before* grace period expiry??
>>>>
>>>>
>>>>        
>>>>
>>>I do not think the RFC covers this case. You are in a double failure
>>>situation.
>>>
>>>I can think of a simple solution. When DUT reacquires its router-lsa.
>>>It can determine its previous
>>>neighbors. It can then decide that if within DeadRouterInterval that
>>>neighbor did not  respond
>>>to hellos to abort GR. This would be equivalent to the normal
>>>situation when a router goes down and its
>>>neigbors takes DeadInterval to bring down their adjacency
>>>      
>>>
>>I agree completely with Padma. One point, if RTA comes back up and
>>originates a new router LSA
>>then the DUT will detect the inconsistency (as specified in RFC 3623)
>>with it's pre-restart LSA and
>>terminate graceful restart.
>>
>>
>>    
>>
>>>Padma.
>>>
>>>      
>>>
>>>>For other routers in the network RTA is still reachable and traffic
>>>>Will be eventually dropped.
>>>>
>>>>Kindly correct me,
>>>>
>>>>Regds,
>>>>Ashok/Sujay
>>>>
>>>>
>>>>
>>>>        
>>>>
>
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May 25 14:53:11 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08528
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 May 2005 14:53:11 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0105B4C1@cherry.ease.lsoft.com>; Wed, 25 May 2005 14:53:10 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72516152 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 May 2005 14:53:09
          -0400
Received: from 208.8.0.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Wed, 25 May 2005 14:53:09 -0400
Received: from mailhub2.ind.alcatel.com (mailhub2.ind.alcatel.com
          [198.206.181.70]) by ind.alcatel.com (8.12.9/8.12.9/(postal1 2.1
          [OUT])) with ESMTP id j4PIr8PG022836 for <OSPF@peach.ease.lsoft.com>;
          Wed, 25 May 2005 11:53:08 -0700 (PDT)
X-InterScan: Passed
Received: from mailhub2.ind.alcatel.com (localhost [127.0.0.1]) by
          mailhub2.ind.alcatel.com (8.12.10/8.12.10/(mailhub2 4.1.4 [HUB2]))
          with ESMTP id j4PIr6aw011253 for <OSPF@peach.ease.lsoft.com>; Wed, 25
          May 2005 11:53:06 -0700 (PDT)
Received: from omni.ind.alcatel.com ([198.206.181.20]) by
          mailhub2.ind.alcatel.com (MailFrontier 4.0.2.4693) with ESMTP; Wed,
          25 May 2005 11:53:06 -0700
Received: from Kishorepc ([128.251.40.163]) by omni.ind.alcatel.com
          (8.9.3+Sun/8.9.1 (omni 3.0 [engr-SPOOL])) with SMTP id LAA13556 for
          <OSPF@peach.ease.lsoft.com>; Wed, 25 May 2005 11:53:06 -0700 (PDT)
References: <000001c56135$9cb892b0$ca04120a@china.huawei.com>                  
            <42949392.3060002@cisco.com>  <4294A37E.2000000@cisco.com>         
            <03e201c56152$44214210$a328fb80@Kishorepc> 
            <4294BBCC.5010607@cisco.com>
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.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mlf-Threat: nothreat
X-Mlf-Threat-Detailed: nothreat;none;list_addrbk_domain
Message-ID:  <03fc01c5615b$2bcde840$a328fb80@Kishorepc>
Date:         Wed, 25 May 2005 12:54:25 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Kishore Rao <kishore@IND.ALCATEL.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Padma Pillay-Esnault" <ppe@cisco.com>
To: <OSPF@peach.ease.lsoft.com>
Sent: Wednesday, May 25, 2005 11:54 AM
Subject: Re: Exit-Graceful Restart Condition


> Kishore Rao wrote:
>
> >----- Original Message ----- 
> >From: "Acee Lindem" <acee@cisco.com>
> >To: <OSPF@peach.ease.lsoft.com>
> >Sent: Wednesday, May 25, 2005 10:10 AM
> >Subject: Re: Exit-Graceful Restart Condition
> >
> >
> >
> >
> >>Padma Pillay-Esnault wrote:
> >>
> >>
> >>
> >>>sujay wrote:
> >>>
> >>>
> >>>
> >>>>Hi All,
> >>>>
> >>>>Considering RFC3623, Graceful Restart for OSPF V2 I have a problem;
> >>>>
> >>>>Ex:
> >>>>
> >>>> (network)---- DUT ---- RTA
> >>>>
> >>>>(All in the same area)
> >>>>
> >>>>Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's to
> >>>>RTA and other routers in the 'network'
> >>>>
> >>>>At the instant RTA recvs the Grace-LSA it also goes down.
> >>>>
> >>>>Is there a way in the RFC 3623 specified as to how DUT could Detect
> >>>>this topology change and Exit GR *before* grace period expiry??
> >>>>
> >>>>
> >>>>
> >>>>
> >>>I do not think the RFC covers this case. You are in a double failure
> >>>situation.
> >>>
> >>>I can think of a simple solution. When DUT reacquires its router-lsa.
> >>>It can determine its previous
> >>>neighbors. It can then decide that if within DeadRouterInterval that
> >>>neighbor did not  respond
> >>>to hellos to abort GR. This would be equivalent to the normal
> >>>situation when a router goes down and its
> >>>neigbors takes DeadInterval to bring down their adjacency
> >>>
> >>>
> >>I agree completely with Padma. One point, if RTA comes back up and
> >>originates a new router LSA
> >>then the DUT will detect the inconsistency (as specified in RFC 3623)
> >>with it's pre-restart LSA and
> >>terminate graceful restart.
> >>
> >>
> >
> >Acee,
> >
> >Will this work ?
> >In case there is another router RTB, scan the Hello from RTB for all
> >neighbors on the network and then make sure Hello from RTA has been
received
> >within a Hello interval + 2 (say) . If not, exit GR.
> >
> >
> It is not clear to me. Do you mean that RTB has the same neighbors as
> DUT and is on the same network link ?

Yes.


>
> Padma
>
> >This would be faster than using the reacquired Router and Network LSAs to
> >determine the neighbors, isnt it ?
> >
> >Kishore
> >
> >
> >
> >
> >>
> >>
> >>>Padma.
> >>>
> >>>
> >>>
> >>>>For other routers in the network RTA is still reachable and traffic
> >>>>Will be eventually dropped.
> >>>>
> >>>>Kindly correct me,
> >>>>
> >>>>Regds,
> >>>>Ashok/Sujay
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >
> >
> >


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed May 25 15:02:34 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09330
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 May 2005 15:02:33 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0105B5A0@cherry.ease.lsoft.com>; Wed, 25 May 2005 15:02:33 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72516787 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 May 2005 15:02:28
          -0400
Received: from 208.8.0.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Wed, 25 May 2005 15:02:28 -0400
Received: from mailhub2.ind.alcatel.com (mailhub2.ind.alcatel.com
          [198.206.181.70]) by ind.alcatel.com (8.12.9/8.12.9/(postal 2.0
          [OUT])) with ESMTP id j4PJ2SMd024594 for <OSPF@peach.ease.lsoft.com>;
          Wed, 25 May 2005 12:02:28 -0700 (PDT)
X-InterScan: Passed
Received: from mailhub2.ind.alcatel.com (localhost [127.0.0.1]) by
          mailhub2.ind.alcatel.com (8.12.10/8.12.10/(mailhub2 4.1.4 [HUB2]))
          with ESMTP id j4PJ2Raw012182 for <OSPF@peach.ease.lsoft.com>; Wed, 25
          May 2005 12:02:27 -0700 (PDT)
Received: from omni.ind.alcatel.com ([198.206.181.20]) by
          mailhub2.ind.alcatel.com (MailFrontier 4.0.2.4693) with ESMTP; Wed,
          25 May 2005 12:02:27 -0700
Received: from Kishorepc ([128.251.40.163]) by omni.ind.alcatel.com
          (8.9.3+Sun/8.9.1 (omni 3.0 [engr-SPOOL])) with SMTP id MAA13946 for
          <OSPF@peach.ease.lsoft.com>; Wed, 25 May 2005 12:02:27 -0700 (PDT)
References: <000001c56135$9cb892b0$ca04120a@china.huawei.com>                  
            <42949392.3060002@cisco.com> <4294A37E.2000000@cisco.com>          
            <4dbb3ecf05052511211a3138e6@mail.gmail.com> 
            <4294C810.4030608@cisco.com>
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.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mlf-Threat: nothreat
X-Mlf-Threat-Detailed: nothreat;none;list_addrbk_domain
Message-ID:  <040f01c5615c$7a1cf210$a328fb80@Kishorepc>
Date:         Wed, 25 May 2005 13:03:45 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Kishore Rao <kishore@IND.ALCATEL.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Padma Pillay-Esnault" <ppe@cisco.com>
To: <OSPF@peach.ease.lsoft.com>
Sent: Wednesday, May 25, 2005 12:46 PM
Subject: Re: Exit-Graceful Restart Condition


> ashok holla wrote:
>
> >Hi,
> >When myself and Sujay raised this issue, we thought about the
> >possibility which Pama and Acee suggested.
> >However, this will not work in all cases.
> >
> >Consider:
> >
> >TOPO------------------------ DUT---------------------------RTA
> >          Area0                                Area1
> >In this case, DUT will not get his pre-restart router of Area 1 as
> >there no other router in the area to give it to him.
> >Therefore, this solution fails.
> >In this case, suppose DUT had run the spf, he would have seen that the
> >type-3 summary lsa he had advertised into area 0, is no longer
> >consistent with the topology and then could have exited GR. However,
> >this consistensy check can be done only after grace period terminates
> >as RTA MAY come up within that time.
> >So, for this case, there seems to be no solution.
> >
> >
> You have not taken into account one major premise in thr rfc -
> For graceful restart to success you MUST have a helper to enable you to
> recover.
> In the case above you have
> 1. A double failure
> 2. No helper in the area
>
> With 2 - There can be no GR restart in the first place. Optimizing the
> detection is not possible if you do not even
>  have the list of your previous neighbors.

If no neighbors are detected after the interface Hello interval, wouldn't
exiting GR be advisable instead of waiting for grace timer to expire ?

Kishore

>
> >However, it does seem to be worthwhile to start deadTimers for all
> >nbrs listed in the pre-restart router lsa when we get it for the first
> >time.  (even though we have not received hello pkts from them). When
> >any inactivity timer fires on the restarting router, he can quit GR.
> >This can be done to impro convergence incase, topology is unstable.
> >
> >
> >
> I would put that as an option rather than a "must".
>
> Padma
>
> >Is our understanding correct?
> >
> >regards,
> >Ashok/Sujay
> >
> >
> >On 5/25/05, Acee Lindem <acee@cisco.com> wrote:
> >
> >
> >>Padma Pillay-Esnault wrote:
> >>
> >>
> >>
> >>>sujay wrote:
> >>>
> >>>
> >>>
> >>>>Hi All,
> >>>>
> >>>>Considering RFC3623, Graceful Restart for OSPF V2 I have a problem;
> >>>>
> >>>>Ex:
> >>>>
> >>>> (network)---- DUT ---- RTA
> >>>>
> >>>>(All in the same area)
> >>>>
> >>>>Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's to
> >>>>RTA and other routers in the 'network'
> >>>>
> >>>>At the instant RTA recvs the Grace-LSA it also goes down.
> >>>>
> >>>>Is there a way in the RFC 3623 specified as to how DUT could Detect
> >>>>this topology change and Exit GR *before* grace period expiry??
> >>>>
> >>>>
> >>>>
> >>>>
> >>>I do not think the RFC covers this case. You are in a double failure
> >>>situation.
> >>>
> >>>I can think of a simple solution. When DUT reacquires its router-lsa.
> >>>It can determine its previous
> >>>neighbors. It can then decide that if within DeadRouterInterval that
> >>>neighbor did not  respond
> >>>to hellos to abort GR. This would be equivalent to the normal
> >>>situation when a router goes down and its
> >>>neigbors takes DeadInterval to bring down their adjacency
> >>>
> >>>
> >>I agree completely with Padma. One point, if RTA comes back up and
> >>originates a new router LSA
> >>then the DUT will detect the inconsistency (as specified in RFC 3623)
> >>with it's pre-restart LSA and
> >>terminate graceful restart.
> >>
> >>
> >>
> >>
> >>>Padma.
> >>>
> >>>
> >>>
> >>>>For other routers in the network RTA is still reachable and traffic
> >>>>Will be eventually dropped.
> >>>>
> >>>>Kindly correct me,
> >>>>
> >>>>Regds,
> >>>>Ashok/Sujay
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >
> >
> >
> >


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri May 27 11:10:13 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19565
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 27 May 2005 11:10:12 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0105FF39@cherry.ease.lsoft.com>; Fri, 27 May 2005 11:10:11 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          72772138 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 27 May 2005 11:10:09
          -0400
Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Fri, 27 May 2005 11:10:09 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com
          with ESMTP; 27 May 2005 08:10:09 -0700
X-IronPort-AV: i="3.93,144,1115017200"; d="scan'208"; a="639098977:sNHT30802868"
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 j4RF9gm8008928 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 27 May 2005
          08:10:02 -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); Fri,
          27 May 2005 08:10:00 -0700
Received: from [192.168.0.2] ([10.21.90.253]) by xfe-sjc-211.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 08:10:00 -0700
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000001c56135$9cb892b0$ca04120a@china.huawei.com>                  
            <42949392.3060002@cisco.com>  <4294A37E.2000000@cisco.com>         
            <03e201c56152$44214210$a328fb80@Kishorepc>            
            <4294BBCC.5010607@cisco.com>
            <03fc01c5615b$2bcde840$a328fb80@Kishorepc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 May 2005 15:10:00.0223 (UTC)
                       FILETIME=[26B6DAF0:01C562CE]
Message-ID:  <42973845.9070404@cisco.com>
Date:         Fri, 27 May 2005 08:09:57 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Padma Pillay-Esnault <ppe@CISCO.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <03fc01c5615b$2bcde840$a328fb80@Kishorepc>
Precedence: list
Content-Transfer-Encoding: 7bit

Kishore Rao wrote:

>----- Original Message ----- 
>From: "Padma Pillay-Esnault" <ppe@cisco.com>
>To: <OSPF@peach.ease.lsoft.com>
>Sent: Wednesday, May 25, 2005 11:54 AM
>Subject: Re: Exit-Graceful Restart Condition
>
>
>  
>
>>Kishore Rao wrote:
>>
>>    
>>
>>>----- Original Message ----- 
>>>From: "Acee Lindem" <acee@cisco.com>
>>>To: <OSPF@peach.ease.lsoft.com>
>>>Sent: Wednesday, May 25, 2005 10:10 AM
>>>Subject: Re: Exit-Graceful Restart Condition
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>Padma Pillay-Esnault wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>sujay wrote:
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Hi All,
>>>>>>
>>>>>>Considering RFC3623, Graceful Restart for OSPF V2 I have a problem;
>>>>>>
>>>>>>Ex:
>>>>>>
>>>>>>(network)---- DUT ---- RTA
>>>>>>
>>>>>>(All in the same area)
>>>>>>
>>>>>>Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's to
>>>>>>RTA and other routers in the 'network'
>>>>>>
>>>>>>At the instant RTA recvs the Grace-LSA it also goes down.
>>>>>>
>>>>>>Is there a way in the RFC 3623 specified as to how DUT could Detect
>>>>>>this topology change and Exit GR *before* grace period expiry??
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>I do not think the RFC covers this case. You are in a double failure
>>>>>situation.
>>>>>
>>>>>I can think of a simple solution. When DUT reacquires its router-lsa.
>>>>>It can determine its previous
>>>>>neighbors. It can then decide that if within DeadRouterInterval that
>>>>>neighbor did not  respond
>>>>>to hellos to abort GR. This would be equivalent to the normal
>>>>>situation when a router goes down and its
>>>>>neigbors takes DeadInterval to bring down their adjacency
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>I agree completely with Padma. One point, if RTA comes back up and
>>>>originates a new router LSA
>>>>then the DUT will detect the inconsistency (as specified in RFC 3623)
>>>>with it's pre-restart LSA and
>>>>terminate graceful restart.
>>>>
>>>>
>>>>        
>>>>
>>>Acee,
>>>
>>>Will this work ?
>>>In case there is another router RTB, scan the Hello from RTB for all
>>>neighbors on the network and then make sure Hello from RTA has been
>>>      
>>>
>received
>  
>
>>>within a Hello interval + 2 (say) . If not, exit GR.
>>>
>>>
>>>      
>>>
>>It is not clear to me. Do you mean that RTB has the same neighbors as
>>DUT and is on the same network link ?
>>    
>>
>
>Yes.
>  
>

This is not a solution that you can rely one. For one - you can only use 
it on a BCAST interface where there are
2+ neighbors possible. It will not work for p2p for example.

I prefer a generic solution.

Padma

>
>  
>
>>Padma
>>
>>    
>>
>>>This would be faster than using the reacquired Router and Network LSAs to
>>>determine the neighbors, isnt it ?
>>>
>>>Kishore
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>        
>>>>
>>>>>Padma.
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>For other routers in the network RTA is still reachable and traffic
>>>>>>Will be eventually dropped.
>>>>>>
>>>>>>Kindly correct me,
>>>>>>
>>>>>>Regds,
>>>>>>Ashok/Sujay
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>
>>>      
>>>
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon May 30 00:20:35 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21847
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 May 2005 00:20:34 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.01067BF5@cherry.ease.lsoft.com>; Mon, 30 May 2005 0:20:29 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          73038587 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 May 2005 00:20:22
          -0400
Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Mon, 30 May 2005 00:19:25 -0400
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com
          (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with
          ESMTP id <0IHA00GFGBUNOR@szxga03-in.huawei.com> for
          OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 May 2005 12:15:59 +0800 (CST)
Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet
          Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id
          <0IHA00JGNBUM52@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 30 May 2005 12:15:58 +0800 (CST)
Received: from dell60 ([10.18.4.202]) by szxml02-in.huawei.com (iPlanet
          Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id
          <0IHA00J0XBYW22@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 30 May 2005 12:18:33 +0800 (CST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook, Build 10.0.4024
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Message-ID:  <000801c564cd$ffb0d760$ca04120a@china.huawei.com>
Date:         Mon, 30 May 2005 09:43:55 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: sujay <sujayg@HUAWEI.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <42973845.9070404@cisco.com>
Precedence: list
Content-Transfer-Encoding: 7BIT

Hi Padma,

Guess we *must* run the dead interval timer on a per neighbor basis,
else
 for the maximum configured dead interval amongst all possible
neighbours.
It could be of course implementation specific.

Solves more than the one issue mentioned in this thread !

Regds,
Sujay

-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma
Pillay-Esnault
Sent: Friday, May 27, 2005 8:40 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Exit-Graceful Restart Condition


Kishore Rao wrote:

>----- Original Message -----
>From: "Padma Pillay-Esnault" <ppe@cisco.com>
>To: <OSPF@peach.ease.lsoft.com>
>Sent: Wednesday, May 25, 2005 11:54 AM
>Subject: Re: Exit-Graceful Restart Condition
>
>
>  
>
>>Kishore Rao wrote:
>>
>>    
>>
>>>----- Original Message -----
>>>From: "Acee Lindem" <acee@cisco.com>
>>>To: <OSPF@peach.ease.lsoft.com>
>>>Sent: Wednesday, May 25, 2005 10:10 AM
>>>Subject: Re: Exit-Graceful Restart Condition
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>Padma Pillay-Esnault wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>sujay wrote:
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Hi All,
>>>>>>
>>>>>>Considering RFC3623, Graceful Restart for OSPF V2 I have a 
>>>>>>problem;
>>>>>>
>>>>>>Ex:
>>>>>>
>>>>>>(network)---- DUT ---- RTA
>>>>>>
>>>>>>(All in the same area)
>>>>>>
>>>>>>Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's 
>>>>>>to RTA and other routers in the 'network'
>>>>>>
>>>>>>At the instant RTA recvs the Grace-LSA it also goes down.
>>>>>>
>>>>>>Is there a way in the RFC 3623 specified as to how DUT could 
>>>>>>Detect this topology change and Exit GR *before* grace period 
>>>>>>expiry??
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>I do not think the RFC covers this case. You are in a double 
>>>>>failure situation.
>>>>>
>>>>>I can think of a simple solution. When DUT reacquires its 
>>>>>router-lsa. It can determine its previous neighbors. It can then 
>>>>>decide that if within DeadRouterInterval that neighbor did not  
>>>>>respond to hellos to abort GR. This would be equivalent to the 
>>>>>normal situation when a router goes down and its
>>>>>neigbors takes DeadInterval to bring down their adjacency
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>I agree completely with Padma. One point, if RTA comes back up and 
>>>>originates a new router LSA then the DUT will detect the 
>>>>inconsistency (as specified in RFC 3623) with it's pre-restart LSA 
>>>>and terminate graceful restart.
>>>>
>>>>
>>>>        
>>>>
>>>Acee,
>>>
>>>Will this work ?
>>>In case there is another router RTB, scan the Hello from RTB for all 
>>>neighbors on the network and then make sure Hello from RTA has been
>>>      
>>>
>received
>  
>
>>>within a Hello interval + 2 (say) . If not, exit GR.
>>>
>>>
>>>      
>>>
>>It is not clear to me. Do you mean that RTB has the same neighbors as 
>>DUT and is on the same network link ?
>>    
>>
>
>Yes.
>  
>

This is not a solution that you can rely one. For one - you can only use

it on a BCAST interface where there are
2+ neighbors possible. It will not work for p2p for example.

I prefer a generic solution.

Padma

>
>  
>
>>Padma
>>
>>    
>>
>>>This would be faster than using the reacquired Router and Network 
>>>LSAs to determine the neighbors, isnt it ?
>>>
>>>Kishore
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>        
>>>>
>>>>>Padma.
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>For other routers in the network RTA is still reachable and 
>>>>>>traffic Will be eventually dropped.
>>>>>>
>>>>>>Kindly correct me,
>>>>>>
>>>>>>Regds,
>>>>>>Ashok/Sujay
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>
>>>      
>>>
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May 31 18:29:54 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06031
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 31 May 2005 18:29:53 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.01069FF9@cherry.ease.lsoft.com>; Tue, 31 May 2005 18:29:51 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          73560668 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 May 2005 18:29:49
          -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l)
          with TCP; Tue, 31 May 2005 18:28:48 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com
          with ESMTP; 31 May 2005 18:28:49 -0400
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 j4VMSll6000486 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 31 May 2005
          18:28:47 -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); Tue,
          31 May 2005 18:28:46 -0400
Received: from [10.82.242.48] ([10.82.242.48]) by xfe-rtp-202.amer.cisco.com
          with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 18:28:46 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000801c564cd$ffb0d760$ca04120a@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 May 2005 22:28:46.0808 (UTC)
                       FILETIME=[1C3BED80:01C56630]
Message-ID:  <429CE51E.8010909@cisco.com>
Date:         Tue, 31 May 2005 18:28:46 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <000801c564cd$ffb0d760$ca04120a@china.huawei.com>
Precedence: list
Content-Transfer-Encoding: 7bit

sujay wrote:

>Hi Padma,
>
>Guess we *must* run the dead interval timer on a per neighbor basis,
>  
>
Hi Sujay,

IMHO, this is the norm rather than the exception.

>else
> for the maximum configured dead interval amongst all possible
>neighbours.
>It could be of course implementation specific.
>
>Solves more than the one issue mentioned in this thread !
>
>Regds,
>Sujay
>
>-----Original Message-----
>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma
>Pillay-Esnault
>Sent: Friday, May 27, 2005 8:40 PM
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: Re: Exit-Graceful Restart Condition
>
>
>Kishore Rao wrote:
>
>  
>
>>----- Original Message -----
>>From: "Padma Pillay-Esnault" <ppe@cisco.com>
>>To: <OSPF@peach.ease.lsoft.com>
>>Sent: Wednesday, May 25, 2005 11:54 AM
>>Subject: Re: Exit-Graceful Restart Condition
>>
>>
>> 
>>
>>    
>>
>>>Kishore Rao wrote:
>>>
>>>   
>>>
>>>      
>>>
>>>>----- Original Message -----
>>>>From: "Acee Lindem" <acee@cisco.com>
>>>>To: <OSPF@peach.ease.lsoft.com>
>>>>Sent: Wednesday, May 25, 2005 10:10 AM
>>>>Subject: Re: Exit-Graceful Restart Condition
>>>>
>>>>
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>Padma Pillay-Esnault wrote:
>>>>>
>>>>>
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>>>sujay wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Hi All,
>>>>>>>
>>>>>>>Considering RFC3623, Graceful Restart for OSPF V2 I have a 
>>>>>>>problem;
>>>>>>>
>>>>>>>Ex:
>>>>>>>
>>>>>>>(network)---- DUT ---- RTA
>>>>>>>
>>>>>>>(All in the same area)
>>>>>>>
>>>>>>>Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's 
>>>>>>>to RTA and other routers in the 'network'
>>>>>>>
>>>>>>>At the instant RTA recvs the Grace-LSA it also goes down.
>>>>>>>
>>>>>>>Is there a way in the RFC 3623 specified as to how DUT could 
>>>>>>>Detect this topology change and Exit GR *before* grace period 
>>>>>>>expiry??
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>I do not think the RFC covers this case. You are in a double 
>>>>>>failure situation.
>>>>>>
>>>>>>I can think of a simple solution. When DUT reacquires its 
>>>>>>router-lsa. It can determine its previous neighbors. It can then 
>>>>>>decide that if within DeadRouterInterval that neighbor did not  
>>>>>>respond to hellos to abort GR. This would be equivalent to the 
>>>>>>normal situation when a router goes down and its
>>>>>>neigbors takes DeadInterval to bring down their adjacency
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>            
>>>>>>
>>>>>I agree completely with Padma. One point, if RTA comes back up and 
>>>>>originates a new router LSA then the DUT will detect the 
>>>>>inconsistency (as specified in RFC 3623) with it's pre-restart LSA 
>>>>>and terminate graceful restart.
>>>>>
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>Acee,
>>>>
>>>>Will this work ?
>>>>In case there is another router RTB, scan the Hello from RTB for all 
>>>>neighbors on the network and then make sure Hello from RTA has been
>>>>     
>>>>
>>>>        
>>>>
>>received
>> 
>>
>>    
>>
>>>>within a Hello interval + 2 (say) . If not, exit GR.
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>It is not clear to me. Do you mean that RTB has the same neighbors as 
>>>DUT and is on the same network link ?
>>>   
>>>
>>>      
>>>
>>Yes.
>> 
>>
>>    
>>
>
>This is not a solution that you can rely one. For one - you can only use
>
>it on a BCAST interface where there are
>2+ neighbors possible. It will not work for p2p for example.
>
>I prefer a generic solution.
>
>Padma
>
>  
>
>> 
>>
>>    
>>
>>>Padma
>>>
>>>   
>>>
>>>      
>>>
>>>>This would be faster than using the reacquired Router and Network 
>>>>LSAs to determine the neighbors, isnt it ?
>>>>
>>>>Kishore
>>>>
>>>>
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>>>Padma.
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>For other routers in the network RTA is still reachable and 
>>>>>>>traffic Will be eventually dropped.
>>>>>>>
>>>>>>>Kindly correct me,
>>>>>>>
>>>>>>>Regds,
>>>>>>>Ashok/Sujay
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>     
>>>>
>>>>        
>>>>
>> 
>>
>>    
>>
>
>  
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue May 31 18:39:46 2005
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06791
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 31 May 2005 18:39:46 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0106A000@cherry.ease.lsoft.com>; Tue, 31 May 2005 18:39:46 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id
          73562282 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 May 2005 18:39:45
          -0400
Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with
          TCP; Tue, 31 May 2005 18:39:45 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com
          with ESMTP; 31 May 2005 15:39:45 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
          [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP
          id j4VMdNcE008715 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 31 May 2005
          15:39:43 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
          xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue,
          31 May 2005 15:39:40 -0700
Received: from [10.32.9.51] ([10.32.9.51]) by xfe-sjc-212.amer.cisco.com with
          Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 15:39:40 -0700
User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000801c564cd$ffb0d760$ca04120a@china.huawei.com>
            <429CE51E.8010909@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 May 2005 22:39:40.0035 (UTC)
                       FILETIME=[A1967530:01C56631]
Message-ID:  <429CE7C4.90606@cisco.com>
Date:         Tue, 31 May 2005 15:40:04 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Padma Pillay-Esnault <ppe@CISCO.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <429CE51E.8010909@cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Acee Lindem wrote:

> sujay wrote:
>
>> Hi Padma,
>>
>> Guess we *must* run the dead interval timer on a per neighbor basis,
>>  
>>
> Hi Sujay,
>
> IMHO, this is the norm rather than the exception.
>

Agree - this is usual behavior.

Padma

>> else
>> for the maximum configured dead interval amongst all possible
>> neighbours.
>> It could be of course implementation specific.
>>
>> Solves more than the one issue mentioned in this thread !
>>
>> Regds,
>> Sujay
>>
>> -----Original Message-----
>> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma
>> Pillay-Esnault
>> Sent: Friday, May 27, 2005 8:40 PM
>> To: OSPF@PEACH.EASE.LSOFT.COM
>> Subject: Re: Exit-Graceful Restart Condition
>>
>>
>> Kishore Rao wrote:
>>
>>  
>>
>>> ----- Original Message -----
>>> From: "Padma Pillay-Esnault" <ppe@cisco.com>
>>> To: <OSPF@peach.ease.lsoft.com>
>>> Sent: Wednesday, May 25, 2005 11:54 AM
>>> Subject: Re: Exit-Graceful Restart Condition
>>>
>>>
>>>
>>>
>>>   
>>>
>>>> Kishore Rao wrote:
>>>>
>>>>  
>>>>     
>>>>
>>>>> ----- Original Message -----
>>>>> From: "Acee Lindem" <acee@cisco.com>
>>>>> To: <OSPF@peach.ease.lsoft.com>
>>>>> Sent: Wednesday, May 25, 2005 10:10 AM
>>>>> Subject: Re: Exit-Graceful Restart Condition
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>    
>>>>>       
>>>>>
>>>>>> Padma Pillay-Esnault wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>      
>>>>>>         
>>>>>>
>>>>>>> sujay wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>        
>>>>>>>           
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Considering RFC3623, Graceful Restart for OSPF V2 I have a 
>>>>>>>> problem;
>>>>>>>>
>>>>>>>> Ex:
>>>>>>>>
>>>>>>>> (network)---- DUT ---- RTA
>>>>>>>>
>>>>>>>> (All in the same area)
>>>>>>>>
>>>>>>>> Assume DUT undergoes a Graceful-Restart, it sends out grace 
>>>>>>>> LSA's to RTA and other routers in the 'network'
>>>>>>>>
>>>>>>>> At the instant RTA recvs the Grace-LSA it also goes down.
>>>>>>>>
>>>>>>>> Is there a way in the RFC 3623 specified as to how DUT could 
>>>>>>>> Detect this topology change and Exit GR *before* grace period 
>>>>>>>> expiry??
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>          
>>>>>>>>             
>>>>>>>
>>>>>>> I do not think the RFC covers this case. You are in a double 
>>>>>>> failure situation.
>>>>>>>
>>>>>>> I can think of a simple solution. When DUT reacquires its 
>>>>>>> router-lsa. It can determine its previous neighbors. It can then 
>>>>>>> decide that if within DeadRouterInterval that neighbor did not  
>>>>>>> respond to hellos to abort GR. This would be equivalent to the 
>>>>>>> normal situation when a router goes down and its
>>>>>>> neigbors takes DeadInterval to bring down their adjacency
>>>>>>>
>>>>>>>
>>>>>>>        
>>>>>>>           
>>>>>>
>>>>>> I agree completely with Padma. One point, if RTA comes back up 
>>>>>> and originates a new router LSA then the DUT will detect the 
>>>>>> inconsistency (as specified in RFC 3623) with it's pre-restart 
>>>>>> LSA and terminate graceful restart.
>>>>>>
>>>>>>
>>>>>>      
>>>>>>         
>>>>>
>>>>> Acee,
>>>>>
>>>>> Will this work ?
>>>>> In case there is another router RTB, scan the Hello from RTB for 
>>>>> all neighbors on the network and then make sure Hello from RTA has 
>>>>> been
>>>>>    
>>>>>       
>>>>
>>> received
>>>
>>>
>>>   
>>>
>>>>> within a Hello interval + 2 (say) . If not, exit GR.
>>>>>
>>>>>
>>>>>    
>>>>>       
>>>>
>>>> It is not clear to me. Do you mean that RTB has the same neighbors 
>>>> as DUT and is on the same network link ?
>>>>  
>>>>     
>>>
>>> Yes.
>>>
>>>
>>>   
>>
>>
>> This is not a solution that you can rely one. For one - you can only use
>>
>> it on a BCAST interface where there are
>> 2+ neighbors possible. It will not work for p2p for example.
>>
>> I prefer a generic solution.
>>
>> Padma
>>
>>  
>>
>>>
>>>
>>>   
>>>
>>>> Padma
>>>>
>>>>  
>>>>     
>>>>
>>>>> This would be faster than using the reacquired Router and Network 
>>>>> LSAs to determine the neighbors, isnt it ?
>>>>>
>>>>> Kishore
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>    
>>>>>       
>>>>>
>>>>>>      
>>>>>>         
>>>>>>
>>>>>>> Padma.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>        
>>>>>>>           
>>>>>>>
>>>>>>>> For other routers in the network RTA is still reachable and 
>>>>>>>> traffic Will be eventually dropped.
>>>>>>>>
>>>>>>>> Kindly correct me,
>>>>>>>>
>>>>>>>> Regds,
>>>>>>>> Ashok/Sujay
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>          
>>>>>>>>             
>>>>>>>
>>>>>    
>>>>>       
>>>>
>>>
>>>
>>>   
>>
>>
>>  
>>
>