From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun  2 10:24:13 2003
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 KAA09661
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 2 Jun 2003 10:24:12 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.009F4C85@cherry.ease.lsoft.com>; Mon, 2 Jun 2003 10:24:10 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 44405385 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 2 Jun 2003 10:24:08 -0400
Received: from 24.93.67.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Mon, 2 Jun 2003 10:24:07 -0400
Received: from redback.com (rdu162-235-026.nc.rr.com [24.162.235.26]) by
          ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id
          h52EIhd2023594 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 2 Jun 2003
          10:18:43 -0400 (EDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <3ED4495F.4050105@redback.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EDB5D5C.7040202@redback.com>
Date:         Mon, 2 Jun 2003 10:21:16 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: OSPF Capabilities Draft
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

I received one comment from Peter Psenack on this draft. A router
with attached stub or NSSA areas should also originate an area scoped
capability LSAs for these area when the domain wide flooding
option is selected. I think this is a good idea.and will add it
as we more forward. Any more discussion?

Thanks,
Acee

Acee Lindem wrote:
> The draft draft-raggarwal-igp-cap-0x.txt has been discussed at the
> last three IETFs. At the last two IETFs, there was mild support and
> we agreed to take the discussion to the OSPF WG list. In order to remove
> one of the barriers to making this draft a WG document, I have split out
> the OSPF specific portion into a separate draft. Rahul has done the same
> for ISIS.
>
> <Speaking as a WG Member>
>
> I beleive the time has come to accept this as a WG document. The
> described mechanism is consistent with other OSPF features and is
> backward compatible. All the OSPF options been have been allocated and
> new proposal will be able to make use of this mechanism without
> solving the option bit problem. One example is
> draft-vasseur-mpls-ospf-te-cap-00.txt.
>
> </Speaking as a WG Member>
>
> Link to draft below:
>
> http://www.ietf.org/internet-drafts/draft-lindem-ospf-cap-00.txt
>
> Further discussion? Any opposition to accepting this draft as a WG
> document?
>
> Thanks,
> --
> Acee
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun  5 07:15:25 2003
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 HAA15080
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Jun 2003 07:15:23 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.009FAE9C@cherry.ease.lsoft.com>; Thu, 5 Jun 2003 7:15:22 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 44785685 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 5 Jun 2003 07:15:19 -0400
Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Thu, 5 Jun 2003 07:15:17 -0400
Received: from kailash.future.futsoft.com (unverified) by
          fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with
          ESMTP id <B0006122076@fsnt.future.futsoft.com> for
          <OSPF@peach.ease.lsoft.com>; Thu, 05 Jun 2003 16:54:32 +0530
Received: from vivekd (vivekd.future.futsoft.com [10.20.6.77]) by
          kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id
          h55BBA7h016032 for <OSPF@peach.ease.lsoft.com>; Thu, 5 Jun 2003
          16:41:12 +0530
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID:  <000001c32b53$c1805980$4d06140a@future.futsoft.com>
Date:         Thu, 5 Jun 2003 16:45:20 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vivek Dubey <vivekd@FUTURE.FUTSOFT.COM>
Subject: Detecting Inactive Neighbors over OSPF - repost
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <000001c32744$141b51e0$4d06140a@future.futsoft.com>
Precedence: list
Content-Transfer-Encoding: 7bit

if lost in flood of mails ......


-----Original Message-----
From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Vivek
Dubey
Sent: Saturday, 31 May 2003 12:43 PM
To: OSPF@peach.ease.lsoft.com
Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
Demand


Roy,
Adjacency will be restored up again but
won't the purpose of "graceful restart" somewhat
defeated then (NBR is needlessly considered dead -
though it is trying graceful restart).

Won't it be better, if it is explicitly mentioned:
1)Generally graceful restart techniques should finish well before
  the probe retries (configurable) are finished(as you said in reply).
OR
2)If the router has received grace LSA from other end
  point.... delay "Nbr probing" till "graceful restart"
  process completes.

thanks,
vivek





-----Original Message-----
From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Abhay
Roy
Sent: Saturday, 31 May 2003 1:17 AM
To: OSPF@peach.ease.lsoft.com
Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
Demand


Vivek,

Generally graceful restart techniques should finish well before
the probe retries (configurable) are finished. If it does not,
then yes, we will consider the neighbor dead. But it's not a big
problem, because the adjacency will come right back up.

I guess implementations could choose to factor in the grace period
to 'delay' probes.

Regards,
-Roy-

On 05/30/03+0530 at 8:48pm, Vivek Dubey writes:

> Roy,
> Suppose the time "Nbr probing" starts, the Ospf at the
> other end is undergoing "graceful restart"...(grace period
> 1800 sec).....
> while probing fails at this end.....
> should we consdier NBR dead or there is some "safeguard"
> in RFC 1793 - graceful restart - and Nbr probing draft, for such scenario.
>
>
>
> thanks,
> vivek
>
>
>
> -----Original Message-----
> From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Abhay
> Roy
> Sent: Friday, 30 May 2003 2:06 PM
> To: OSPF@peach.ease.lsoft.com
> Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
> Demand
>
>
> Mitchell,
>
> The important point to note here is that: If the originator is
> 'reachable', DoNotAge LSA's can stay forever.
>
> Regards,
> -Roy-
>
> On 05/30/03-0700 at 12:20am, Erblichs writes:
>
> > Lets cover two stones with one throw..
> >
> >         Lets try part of this again..
> >
> >         In the 1793 RFC which deals with demand circuits,
> >         there is a 2.3 - 2) section that mentions MaxAge
> >         seconds, aka 3600 seconds or 1 hr.
> >
> > To ensure that these LSAs are eventually
> >       flushed from the routing domain, and that the size of the link
> >       state database doesn't grow without bound, routers are required to
> >       flush a DoNotAge LSA if BOTH of the following conditions are met:
> >
> > (2) The originator of the LSA has been unreachable (according to
> >     the routing calculations specified by Section 16 of [1]) for
> >             at least MaxAge seconds.
> >
> >         If probe exceeds 1 hr then LSAs are most likely
> >         dropped and LSAs need to be originated. Thus, tell
> >         me why you would want to allow LSAs to be forced
> >         to be re-originated in favor of a longer probe.
> >
> >         I also think you may get a dead nbr, but that is
> >         a different discussion point..
> >
> >         Mitchell Erblich
> >         Sr Software Engineer
> >         ---------------------
> >
> >
> > Mitchell,
> >
> > In case of 'always up' DC links, it does turn out to be periodic
> > probing. But in case of 'on demand' DC links, (if there is no data
> > traffic) it's of no use to bring up the link just to send probes.
> > So it makes sense to piggy back this event on the link coming up
> > event, and keep doing it periodically till the time line remains
> > up (due to data traffic).
> >
> > Regards,
> > -Roy-
> >
> >
> >
> > Abhay Roy wrote:
> > >
> > > Mitchell,
> > >
> > > Why it MUST not exceed 1hr? Today it's infinity, so in theory any
> > > interval (including absurdly high ones) should be allowed.
> > >
> > > Regards,
> > > -Roy-
> > >
> > > On 05/28/03-0700 at 1:06pm, Erblichs writes:
> > >
> > > > Sorry group,
> > > >
> > > >         I forgot..
> > > >
> > > >         E) If ..ProbeInterval is kept, its max value MUST not exceed
> > > >            1 hr..
> > > >
> > > >         I think this follows that if we haven't heard from our
> > > >         nbr in 1 hr "he" is considered dead.
> > > >
> > > >         Mitchell Erblich
> > > >         -------------------
> >
>
>
***************************************************************************
> This message is proprietary to Future Software Limited (FSL)
> and is intended solely for the use of the individual to whom it
> is addressed. It may contain  privileged or confidential information
> and should not be circulated or used for any purpose other than for
> what it is intended.
>
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient,
> you are notified that you are strictly prohibited from using,
> copying, altering, or disclosing the contents of this message.
> FSL accepts no responsibility for loss or damage arising from
> the use of the information transmitted by this email including
> damage from virus.
>
***************************************************************************
>

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun  5 07:18:02 2003
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 HAA15139
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Jun 2003 07:18:01 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.009FB020@cherry.ease.lsoft.com>; Thu, 5 Jun 2003 7:17:59 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 44785758 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 5 Jun 2003 07:17:58 -0400
Received: from 144.189.100.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Thu, 5 Jun 2003 07:17:57 -0400
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by
          motgate4.mot.com (Motorola/Motgate4) with ESMTP id h55BHuoI019578 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 5 Jun 2003 04:17:56 -0700 (MST)
Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by
          az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h55BHsVN020274
          for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 5 Jun 2003 06:17:55 -0500
Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id
          <J0ACTSHH>; Thu, 5 Jun 2003 07:17:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328DD43F4@india_exch.corp.mot.com>
Date:         Thu, 5 Jun 2003 07:19:33 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: OSPF Capabilities Draft
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi Acee,

Are you talking of some sort of a translation mechanism where you have ABR's
send area-scope LSA's into stub/NSSA for each global scope LSA?

Thanks,
Vishwas

-----Original Message-----
From: Acee Lindem [mailto:acee@REDBACK.COM]
Sent: Monday, June 02, 2003 19:51
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: OSPF Capabilities Draft


I received one comment from Peter Psenack on this draft. A router
with attached stub or NSSA areas should also originate an area scoped
capability LSAs for these area when the domain wide flooding
option is selected. I think this is a good idea.and will add it
as we more forward. Any more discussion?

Thanks,
Acee

Acee Lindem wrote:
> The draft draft-raggarwal-igp-cap-0x.txt has been discussed at the
> last three IETFs. At the last two IETFs, there was mild support and
> we agreed to take the discussion to the OSPF WG list. In order to remove
> one of the barriers to making this draft a WG document, I have split out
> the OSPF specific portion into a separate draft. Rahul has done the same
> for ISIS.
>
> <Speaking as a WG Member>
>
> I beleive the time has come to accept this as a WG document. The
> described mechanism is consistent with other OSPF features and is
> backward compatible. All the OSPF options been have been allocated and
> new proposal will be able to make use of this mechanism without
> solving the option bit problem. One example is
> draft-vasseur-mpls-ospf-te-cap-00.txt.
>
> </Speaking as a WG Member>
>
> Link to draft below:
>
> http://www.ietf.org/internet-drafts/draft-lindem-ospf-cap-00.txt
>
> Further discussion? Any opposition to accepting this draft as a WG
> document?
>
> Thanks,
> --
> Acee
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun  5 08:51:56 2003
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 IAA22353
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Jun 2003 08:51:56 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.009FB07F@cherry.ease.lsoft.com>; Thu, 5 Jun 2003 8:51:54 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 44787862 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 5 Jun 2003 08:51:52 -0400
Received: from 216.136.129.134 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Thu, 5 Jun 2003 08:41:51 -0400
Received: from [160.83.32.14] by web9504.mail.yahoo.com via HTTP; Thu, 05 Jun
          2003 13:41:50 BST
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <20030605124150.51373.qmail@web9504.mail.yahoo.com>
Date:         Thu, 5 Jun 2003 13:41:50 +0100
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: =?iso-8859-1?q?Ian=20Potts?= <ijpotts_lists@YAHOO.CO.UK>
Subject: MOSPF can't determine the receiving interface exactly - In John Moy's book OSPF Anatomy of a Routing Protocol
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit

Hello,

In John Moy's excellent book, Anatomy of an Internet
Routing Protocol, on page 195 (section 10.3.1 The
Multicast Forwarding Cache), it states that a router
does the RPF check in MOSPF on the router's ID, and
not on the incoming interface, since MOSPF can't
determine the receiving interface exactly, since there
is insufficient information in the OSPF lsdb to match
the sending and receiving halves.

Can someone please explain this to me since I am
confused.  Looking at the router LSAs given below,
can't the router first work out the router-id, then
consult the routing table to find the interface?

Many Thanks
Ian

Router 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 144.141.252.254
     (Link Data) Router Interface address:
144.128.254.138
      Number of TOS metrics: 0
       TOS 0 Metrics: 1000

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 144.128.254.136
     (Link Data) Network Mask: 255.255.255.248
      Number of TOS metrics: 0
       TOS 0 Metrics: 1000

Router 2

Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 144.141.89.2
     (Link Data) Router Interface address:
144.128.254.137
      Number of TOS metrics: 0
       TOS 0 Metrics: 1000

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 144.128.254.136
     (Link Data) Network Mask: 255.255.255.248
      Number of TOS metrics: 0
       TOS 0 Metrics: 1000




__________________________________________________
Yahoo! Plus - For a better Internet experience
http://uk.promotions.yahoo.com/yplus/yoffer.html


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun  5 15:49:18 2003
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 PAA14412
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Jun 2003 15:49:18 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.009FBB0F@cherry.ease.lsoft.com>; Thu, 5 Jun 2003 15:49:17 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 44818252 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 5 Jun 2003 15:49:15 -0400
Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Thu, 5 Jun 2003 15:49:15 -0400
Received: from cisco.com (ppsenak-isdn-home.cisco.com [10.49.2.218]) by
          strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h55JnER21963
          for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 5 Jun 2003 21:49:14 +0200 (CEST)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2)
            Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <E7E13AAF2F3ED41197C100508BD6A328DD43F4@india_exch.corp.mot.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EDF9EBA.6070501@cisco.com>
Date:         Thu, 5 Jun 2003 21:49:14 +0200
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Peter Psenak <ppsenak@CISCO.COM>
Subject: Re: OSPF Capabilities Draft
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Vishwas,

Manral, Vishwas wrote:

>Hi Acee,
>
>Are you talking of some sort of a translation mechanism where you have ABR's
>send area-scope LSA's into stub/NSSA for each global scope LSA?
>
>
no. We talked with Acee about a case where NSSA ABR  needs to generate
multiple Capability LSA  - one Type-11 plus one Type-10 per each
stub/NSSA area attached.
Similar to Type-5 plus Type-7 LSAs case on NSSA ABR/ASBR.

thanks,
Peter

>Thanks,
>Vishwas
>
>-----Original Message-----
>From: Acee Lindem [mailto:acee@REDBACK.COM]
>Sent: Monday, June 02, 2003 19:51
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: Re: OSPF Capabilities Draft
>
>
>I received one comment from Peter Psenack on this draft. A router
>with attached stub or NSSA areas should also originate an area scoped
>capability LSAs for these area when the domain wide flooding
>option is selected. I think this is a good idea.and will add it
>as we more forward. Any more discussion?
>
>Thanks,
>Acee
>
>Acee Lindem wrote:
>
>
>>The draft draft-raggarwal-igp-cap-0x.txt has been discussed at the
>>last three IETFs. At the last two IETFs, there was mild support and
>>we agreed to take the discussion to the OSPF WG list. In order to remove
>>one of the barriers to making this draft a WG document, I have split out
>>the OSPF specific portion into a separate draft. Rahul has done the same
>>for ISIS.
>>
>><Speaking as a WG Member>
>>
>>I beleive the time has come to accept this as a WG document. The
>>described mechanism is consistent with other OSPF features and is
>>backward compatible. All the OSPF options been have been allocated and
>>new proposal will be able to make use of this mechanism without
>>solving the option bit problem. One example is
>>draft-vasseur-mpls-ospf-te-cap-00.txt.
>>
>></Speaking as a WG Member>
>>
>>Link to draft below:
>>
>>http://www.ietf.org/internet-drafts/draft-lindem-ospf-cap-00.txt
>>
>>Further discussion? Any opposition to accepting this draft as a WG
>>document?
>>
>>Thanks,
>>--
>>Acee
>>
>>
>>
>
>
>--
>Acee
>
>
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun  5 17:01:47 2003
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 RAA16994
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Jun 2003 17:01:46 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.009FBE31@cherry.ease.lsoft.com>; Thu, 5 Jun 2003 17:01:45 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 44822342 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 5 Jun 2003 17:00:12 -0400
Received: from 171.71.177.254 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Thu, 5 Jun 2003 17:00:12 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com
          [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id
          h55L013I009537 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 5 Jun 2003
          14:00:10 -0700 (PDT)
Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by
          mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with
          ESMTP id AHV42717; Thu, 5 Jun 2003 13:55:45 -0700 (PDT)
References: <000001c32b53$c1805980$4d06140a@future.futsoft.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.GSO.4.52.0306051339010.12774@irp-view7.cisco.com>
Date:         Thu, 5 Jun 2003 13:59:47 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Abhay Roy <akr@CISCO.COM>
Subject: Re: Detecting Inactive Neighbors over OSPF - repost
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <000001c32b53$c1805980$4d06140a@future.futsoft.com>
Precedence: list

Vivek,

I discussed this with my co-authors.. And we think that this
should work just fine if the router supports (and is doing)
graceful restart..

The Grace LSA tells us to continue announcing the adjacency even
if it goes down. The restarting router will _reset_ its
adjacencies anyways, and we are going to see this. If the probe
goes out and fails before, the grace period should cover it.

Regards,
-Roy-

On 06/05/03+0530 at 4:45pm, Vivek Dubey writes:

> if lost in flood of mails ......
>
>
> -----Original Message-----
> From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Vivek
> Dubey
> Sent: Saturday, 31 May 2003 12:43 PM
> To: OSPF@peach.ease.lsoft.com
> Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
> Demand
>
>
> Roy,
> Adjacency will be restored up again but
> won't the purpose of "graceful restart" somewhat
> defeated then (NBR is needlessly considered dead -
> though it is trying graceful restart).
>
> Won't it be better, if it is explicitly mentioned:
> 1)Generally graceful restart techniques should finish well before
>   the probe retries (configurable) are finished(as you said in reply).
> OR
> 2)If the router has received grace LSA from other end
>   point.... delay "Nbr probing" till "graceful restart"
>   process completes.
>
> thanks,
> vivek
>
>
>
>
>
> -----Original Message-----
> From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Abhay
> Roy
> Sent: Saturday, 31 May 2003 1:17 AM
> To: OSPF@peach.ease.lsoft.com
> Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
> Demand
>
>
> Vivek,
>
> Generally graceful restart techniques should finish well before
> the probe retries (configurable) are finished. If it does not,
> then yes, we will consider the neighbor dead. But it's not a big
> problem, because the adjacency will come right back up.
>
> I guess implementations could choose to factor in the grace period
> to 'delay' probes.
>
> Regards,
> -Roy-
>
> On 05/30/03+0530 at 8:48pm, Vivek Dubey writes:
>
> > Roy,
> > Suppose the time "Nbr probing" starts, the Ospf at the
> > other end is undergoing "graceful restart"...(grace period
> > 1800 sec).....
> > while probing fails at this end.....
> > should we consdier NBR dead or there is some "safeguard"
> > in RFC 1793 - graceful restart - and Nbr probing draft, for such scenario.
> >
> >
> >
> > thanks,
> > vivek
> >
> >
> >
> > -----Original Message-----
> > From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Abhay
> > Roy
> > Sent: Friday, 30 May 2003 2:06 PM
> > To: OSPF@peach.ease.lsoft.com
> > Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
> > Demand
> >
> >
> > Mitchell,
> >
> > The important point to note here is that: If the originator is
> > 'reachable', DoNotAge LSA's can stay forever.
> >
> > Regards,
> > -Roy-
> >
> > On 05/30/03-0700 at 12:20am, Erblichs writes:
> >
> > > Lets cover two stones with one throw..
> > >
> > >         Lets try part of this again..
> > >
> > >         In the 1793 RFC which deals with demand circuits,
> > >         there is a 2.3 - 2) section that mentions MaxAge
> > >         seconds, aka 3600 seconds or 1 hr.
> > >
> > > To ensure that these LSAs are eventually
> > >       flushed from the routing domain, and that the size of the link
> > >       state database doesn't grow without bound, routers are required to
> > >       flush a DoNotAge LSA if BOTH of the following conditions are met:
> > >
> > > (2) The originator of the LSA has been unreachable (according to
> > >     the routing calculations specified by Section 16 of [1]) for
> > >             at least MaxAge seconds.
> > >
> > >         If probe exceeds 1 hr then LSAs are most likely
> > >         dropped and LSAs need to be originated. Thus, tell
> > >         me why you would want to allow LSAs to be forced
> > >         to be re-originated in favor of a longer probe.
> > >
> > >         I also think you may get a dead nbr, but that is
> > >         a different discussion point..
> > >
> > >         Mitchell Erblich
> > >         Sr Software Engineer
> > >         ---------------------
> > >
> > >
> > > Mitchell,
> > >
> > > In case of 'always up' DC links, it does turn out to be periodic
> > > probing. But in case of 'on demand' DC links, (if there is no data
> > > traffic) it's of no use to bring up the link just to send probes.
> > > So it makes sense to piggy back this event on the link coming up
> > > event, and keep doing it periodically till the time line remains
> > > up (due to data traffic).
> > >
> > > Regards,
> > > -Roy-
> > >
> > >
> > >
> > > Abhay Roy wrote:
> > > >
> > > > Mitchell,
> > > >
> > > > Why it MUST not exceed 1hr? Today it's infinity, so in theory any
> > > > interval (including absurdly high ones) should be allowed.
> > > >
> > > > Regards,
> > > > -Roy-
> > > >
> > > > On 05/28/03-0700 at 1:06pm, Erblichs writes:
> > > >
> > > > > Sorry group,
> > > > >
> > > > >         I forgot..
> > > > >
> > > > >         E) If ..ProbeInterval is kept, its max value MUST not exceed
> > > > >            1 hr..
> > > > >
> > > > >         I think this follows that if we haven't heard from our
> > > > >         nbr in 1 hr "he" is considered dead.
> > > > >
> > > > >         Mitchell Erblich
> > > > >         -------------------
> > >
> >
> >
> ***************************************************************************
> > This message is proprietary to Future Software Limited (FSL)
> > and is intended solely for the use of the individual to whom it
> > is addressed. It may contain  privileged or confidential information
> > and should not be circulated or used for any purpose other than for
> > what it is intended.
> >
> > If you have received this message in error, please notify the
> > originator immediately. If you are not the intended recipient,
> > you are notified that you are strictly prohibited from using,
> > copying, altering, or disclosing the contents of this message.
> > FSL accepts no responsibility for loss or damage arising from
> > the use of the information transmitted by this email including
> > damage from virus.
> >
> ***************************************************************************
> >
>
> ***************************************************************************
> This message is proprietary to Future Software Limited (FSL)
> and is intended solely for the use of the individual to whom it
> is addressed. It may contain  privileged or confidential information
> and should not be circulated or used for any purpose other than for
> what it is intended.
>
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient,
> you are notified that you are strictly prohibited from using,
> copying, altering, or disclosing the contents of this message.
> FSL accepts no responsibility for loss or damage arising from
> the use of the information transmitted by this email including
> damage from virus.
> ***************************************************************************
>
> ***************************************************************************
> This message is proprietary to Future Software Limited (FSL)
> and is intended solely for the use of the individual to whom it
> is addressed. It may contain  privileged or confidential information
> and should not be circulated or used for any purpose other than for
> what it is intended.
>
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient,
> you are notified that you are strictly prohibited from using,
> copying, altering, or disclosing the contents of this message.
> FSL accepts no responsibility for loss or damage arising from
> the use of the information transmitted by this email including
> damage from virus.
> ***************************************************************************
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun  5 17:13:43 2003
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 RAA17434
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Jun 2003 17:13:42 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.009FBF61@cherry.ease.lsoft.com>; Thu, 5 Jun 2003 17:13:42 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 44823748 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 5 Jun 2003 17:13:35 -0400
Received: from 24.93.67.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 5 Jun 2003 17:13:35 -0400
Received: from redback.com (rdu162-240-050.nc.rr.com [24.162.240.50]) by
          ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id
          h55L895J023969 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 5 Jun 2003
          17:08:09 -0400 (EDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000001c32b53$c1805980$4d06140a@future.futsoft.com>
            <Pine.GSO.4.52.0306051339010.12774@irp-view7.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EDFB2C6.9090904@redback.com>
Date:         Thu, 5 Jun 2003 17:14:46 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Detecting Inactive Neighbors over OSPF - repost
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Abhay Roy wrote:
> Vivek,
>
> I discussed this with my co-authors.. And we think that this
> should work just fine if the router supports (and is doing)
> graceful restart..
>
> The Grace LSA tells us to continue announcing the adjacency even
> if it goes down. The restarting router will _reset_ its
> adjacencies anyways, and we are going to see this. If the probe
> goes out and fails before, the grace period should cover it.


Roy,

I was meaning to make the same point but got tied up today.

Vivek,

Look at section 3.0 in draft-ietf-ospf-hitless-restart-07.txt. Note
that the neighbor going to DOWN state doesn't necessary cause
the helper to exit graceful restart.

Thanks,
Acee


>
> Regards,
> -Roy-
>
> On 06/05/03+0530 at 4:45pm, Vivek Dubey writes:
>
>
>>if lost in flood of mails ......
>>
>>
>>-----Original Message-----
>>From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Vivek
>>Dubey
>>Sent: Saturday, 31 May 2003 12:43 PM
>>To: OSPF@peach.ease.lsoft.com
>>Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
>>Demand
>>
>>
>>Roy,
>>Adjacency will be restored up again but
>>won't the purpose of "graceful restart" somewhat
>>defeated then (NBR is needlessly considered dead -
>>though it is trying graceful restart).
>>
>>Won't it be better, if it is explicitly mentioned:
>>1)Generally graceful restart techniques should finish well before
>>  the probe retries (configurable) are finished(as you said in reply).
>>OR
>>2)If the router has received grace LSA from other end
>>  point.... delay "Nbr probing" till "graceful restart"
>>  process completes.
>>
>>thanks,
>>vivek
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Abhay
>>Roy
>>Sent: Saturday, 31 May 2003 1:17 AM
>>To: OSPF@peach.ease.lsoft.com
>>Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
>>Demand
>>
>>
>>Vivek,
>>
>>Generally graceful restart techniques should finish well before
>>the probe retries (configurable) are finished. If it does not,
>>then yes, we will consider the neighbor dead. But it's not a big
>>problem, because the adjacency will come right back up.
>>
>>I guess implementations could choose to factor in the grace period
>>to 'delay' probes.
>>
>>Regards,
>>-Roy-
>>
>>On 05/30/03+0530 at 8:48pm, Vivek Dubey writes:
>>
>>
>>>Roy,
>>>Suppose the time "Nbr probing" starts, the Ospf at the
>>>other end is undergoing "graceful restart"...(grace period
>>>1800 sec).....
>>>while probing fails at this end.....
>>>should we consdier NBR dead or there is some "safeguard"
>>>in RFC 1793 - graceful restart - and Nbr probing draft, for such scenario.
>>>
>>>
>>>
>>>thanks,
>>>vivek
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Abhay
>>>Roy
>>>Sent: Friday, 30 May 2003 2:06 PM
>>>To: OSPF@peach.ease.lsoft.com
>>>Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
>>>Demand
>>>
>>>
>>>Mitchell,
>>>
>>>The important point to note here is that: If the originator is
>>>'reachable', DoNotAge LSA's can stay forever.
>>>
>>>Regards,
>>>-Roy-
>>>
>>>On 05/30/03-0700 at 12:20am, Erblichs writes:
>>>
>>>
>>>>Lets cover two stones with one throw..
>>>>
>>>>        Lets try part of this again..
>>>>
>>>>        In the 1793 RFC which deals with demand circuits,
>>>>        there is a 2.3 - 2) section that mentions MaxAge
>>>>        seconds, aka 3600 seconds or 1 hr.
>>>>
>>>>To ensure that these LSAs are eventually
>>>>      flushed from the routing domain, and that the size of the link
>>>>      state database doesn't grow without bound, routers are required to
>>>>      flush a DoNotAge LSA if BOTH of the following conditions are met:
>>>>
>>>>(2) The originator of the LSA has been unreachable (according to
>>>>    the routing calculations specified by Section 16 of [1]) for
>>>>            at least MaxAge seconds.
>>>>
>>>>        If probe exceeds 1 hr then LSAs are most likely
>>>>        dropped and LSAs need to be originated. Thus, tell
>>>>        me why you would want to allow LSAs to be forced
>>>>        to be re-originated in favor of a longer probe.
>>>>
>>>>        I also think you may get a dead nbr, but that is
>>>>        a different discussion point..
>>>>
>>>>        Mitchell Erblich
>>>>        Sr Software Engineer
>>>>        ---------------------
>>>>
>>>>
>>>>Mitchell,
>>>>
>>>>In case of 'always up' DC links, it does turn out to be periodic
>>>>probing. But in case of 'on demand' DC links, (if there is no data
>>>>traffic) it's of no use to bring up the link just to send probes.
>>>>So it makes sense to piggy back this event on the link coming up
>>>>event, and keep doing it periodically till the time line remains
>>>>up (due to data traffic).
>>>>
>>>>Regards,
>>>>-Roy-
>>>>
>>>>
>>>>
>>>>Abhay Roy wrote:
>>>>
>>>>>Mitchell,
>>>>>
>>>>>Why it MUST not exceed 1hr? Today it's infinity, so in theory any
>>>>>interval (including absurdly high ones) should be allowed.
>>>>>
>>>>>Regards,
>>>>>-Roy-
>>>>>
>>>>>On 05/28/03-0700 at 1:06pm, Erblichs writes:
>>>>>
>>>>>
>>>>>>Sorry group,
>>>>>>
>>>>>>        I forgot..
>>>>>>
>>>>>>        E) If ..ProbeInterval is kept, its max value MUST not exceed
>>>>>>           1 hr..
>>>>>>
>>>>>>        I think this follows that if we haven't heard from our
>>>>>>        nbr in 1 hr "he" is considered dead.
>>>>>>
>>>>>>        Mitchell Erblich
>>>>>>        -------------------
>>>>>
>>>
>>***************************************************************************
>>
>>>This message is proprietary to Future Software Limited (FSL)
>>>and is intended solely for the use of the individual to whom it
>>>is addressed. It may contain  privileged or confidential information
>>>and should not be circulated or used for any purpose other than for
>>>what it is intended.
>>>
>>>If you have received this message in error, please notify the
>>>originator immediately. If you are not the intended recipient,
>>>you are notified that you are strictly prohibited from using,
>>>copying, altering, or disclosing the contents of this message.
>>>FSL accepts no responsibility for loss or damage arising from
>>>the use of the information transmitted by this email including
>>>damage from virus.
>>>
>>
>>***************************************************************************
>>
>>***************************************************************************
>>This message is proprietary to Future Software Limited (FSL)
>>and is intended solely for the use of the individual to whom it
>>is addressed. It may contain  privileged or confidential information
>>and should not be circulated or used for any purpose other than for
>>what it is intended.
>>
>>If you have received this message in error, please notify the
>>originator immediately. If you are not the intended recipient,
>>you are notified that you are strictly prohibited from using,
>>copying, altering, or disclosing the contents of this message.
>>FSL accepts no responsibility for loss or damage arising from
>>the use of the information transmitted by this email including
>>damage from virus.
>>***************************************************************************
>>
>>***************************************************************************
>>This message is proprietary to Future Software Limited (FSL)
>>and is intended solely for the use of the individual to whom it
>>is addressed. It may contain  privileged or confidential information
>>and should not be circulated or used for any purpose other than for
>>what it is intended.
>>
>>If you have received this message in error, please notify the
>>originator immediately. If you are not the intended recipient,
>>you are notified that you are strictly prohibited from using,
>>copying, altering, or disclosing the contents of this message.
>>FSL accepts no responsibility for loss or damage arising from
>>the use of the information transmitted by this email including
>>damage from virus.
>>***************************************************************************
>>
>
>


--
Acee


From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM  Fri Jun  6 00:39:01 2003
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 AAA28391
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 6 Jun 2003 00:39:00 -0400 (EDT)
Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00A0145A@cherry.ease.lsoft.com>; Fri, 6 Jun 2003 0:39:02 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 44859114 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 6 Jun 2003 00:39:02 -0400
Received: from 24.93.67.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 6 Jun 2003 00:39:02 -0400
Received: from redback.com (rdu162-240-050.nc.rr.com [24.162.240.50]) by
          ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id
          h564bOMF014020 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 6 Jun 2003
          00:37:24 -0400 (EDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <E7E13AAF2F3ED41197C100508BD6A328DD43F4@india_exch.corp.mot.com>
            <3EDF9EBA.6070501@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EE01B29.3010303@redback.com>
Date:         Fri, 6 Jun 2003 00:40:09 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: OSPF Capabilities Draft
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Peter Psenak wrote:
> Vishwas,
>
> Manral, Vishwas wrote:
>
>> Hi Acee,
>>
>> Are you talking of some sort of a translation mechanism where you have
>> ABR's
>> send area-scope LSA's into stub/NSSA for each global scope LSA?
>>
>>
> no. We talked with Acee about a case where NSSA ABR  needs to generate
> multiple Capability LSA  - one Type-11 plus one Type-10 per each
> stub/NSSA area attached.
> Similar to Type-5 plus Type-7 LSAs case on NSSA ABR/ASBR.

This seemed reasonable to me for attached NSSA/stubs (even though unattached
NSSA/stubs would not get the advertisements).


>
> thanks,
> Peter
>
>> Thanks,
>> Vishwas
>>
>> -----Original Message-----
>> From: Acee Lindem [mailto:acee@REDBACK.COM]
>> Sent: Monday, June 02, 2003 19:51
>> To: OSPF@PEACH.EASE.LSOFT.COM
>> Subject: Re: OSPF Capabilities Draft
>>
>>
>> I received one comment from Peter Psenack on this draft. A router
>> with attached stub or NSSA areas should also originate an area scoped
>> capability LSAs for these area when the domain wide flooding
>> option is selected. I think this is a good idea.and will add it
>> as we more forward. Any more discussion?
>>
>> Thanks,
>> Acee
>>
>> Acee Lindem wrote:
>>
>>
>>> The draft draft-raggarwal-igp-cap-0x.txt has been discussed at the
>>> last three IETFs. At the last two IETFs, there was mild support and
>>> we agreed to take the discussion to the OSPF WG list. In order to remove
>>> one of the barriers to making this draft a WG document, I have split out
>>> the OSPF specific portion into a separate draft. Rahul has done the same
>>> for ISIS.
>>>
>>> <Speaking as a WG Member>
>>>
>>> I beleive the time has come to accept this as a WG document. The
>>> described mechanism is consistent with other OSPF features and is
>>> backward compatible. All the OSPF options been have been allocated and
>>> new proposal will be able to make use of this mechanism without
>>> solving the option bit problem. One example is
>>> draft-vasseur-mpls-ospf-te-cap-00.txt.
>>>
>>> </Speaking as a WG Member>
>>>
>>> Link to draft below:
>>>
>>> http://www.ietf.org/internet-drafts/draft-lindem-ospf-cap-00.txt
>>>
>>> Further discussion? Any opposition to accepting this draft as a WG
>>> document?
>>>
>>> Thanks,
>>> --
>>> Acee
>>>
>>>
>>>
>>
>>
>> --
>> Acee
>>
>>
>>
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun  6 11:57:28 2003
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 LAA29645
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 6 Jun 2003 11:57:28 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00A02E19@cherry.ease.lsoft.com>; Fri, 6 Jun 2003 11:57:27 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 44810766 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 6 Jun 2003 11:57:26 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 6 Jun 2003 11:47:26 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id LAA29171; Fri, 6 Jun 2003 11:47:21
          -0400 (EDT)
Message-ID:  <200306061547.LAA29171@ietf.org>
Date:         Fri, 6 Jun 2003 11:47:21 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: The IESG <iesg-secretary@ietf.org>
Subject: Last Call: Graceful OSPF Restart to Proposed Standard
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

The IESG has received a request from the Open Shortest Path First
IGP Working Group to consider Graceful OSPF Restart
<draft-ietf-ospf-hitless-restart-07.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-20.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-07.txt


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun  6 12:52:31 2003
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 MAA02209
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 6 Jun 2003 12:52:29 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00A02DFE@cherry.ease.lsoft.com>; Fri, 6 Jun 2003 12:52:22 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 44814944 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 6 Jun 2003 12:52:21 -0400
Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Fri, 6 Jun 2003 12:52:21 -0400
Received: (qmail 2803 invoked from network); 6 Jun 2003 16:52:20 -0000
Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP;
          6 Jun 2003 16:52:20 -0000
Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by
          bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id MAA20192 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 6 Jun 2003 12:52:20 -0400
X-Mailer: exmh version 2.1.1 10/15/1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <200306061652.MAA20192@bigbird.xebeo.com>
Date:         Fri, 6 Jun 2003 12:52:20 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Rohit Dube <rohit@XEBEO.COM>
Subject: ospf archives
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Howdy,

The ospf archives at peach.ease.lsoft.com are now available
thanks to David Whipple.

You can access all three OSPF archives via
http://rtg.ietf.org/ospf

Enjoy,
--rohit.


From owner-ospf@PEACH.EASE.LSOFT.COM  Sat Jun  7 04:41:35 2003
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 EAA08943
	for <ospf-archive@LISTS.IETF.ORG>; Sat, 7 Jun 2003 04:41:34 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00A04A7A@cherry.ease.lsoft.com>; Sat, 7 Jun 2003 4:41:34 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 44897631 for OSPF@PEACH.EASE.LSOFT.COM;
          Sat, 7 Jun 2003 04:41:32 -0400
Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Sat, 7 Jun 2003 04:41:31 -0400
Received: from kailash.future.futsoft.com (unverified) by
          fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with
          ESMTP id <B0006163649@fsnt.future.futsoft.com> for
          <OSPF@peach.ease.lsoft.com>; Sat, 07 Jun 2003 14:21:49 +0530
Received: from vivekd (vivekd.future.futsoft.com [10.20.6.77]) by
          kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id
          h578cQ7j030579 for <OSPF@peach.ease.lsoft.com>; Sat, 7 Jun 2003
          14:08:26 +0530
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID:  <000001c32cd0$d12fdb20$4d06140a@future.futsoft.com>
Date:         Sat, 7 Jun 2003 14:13:05 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vivek Dubey <vivekd@FUTURE.FUTSOFT.COM>
Subject: Re: Detecting Inactive Neighbors over OSPF - repost
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <3EDFB2C6.9090904@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Acee, Roy:

Section 3.0 in draft-ietf-ospf-hitless-restart-07.txt :
======================================================
"This means that Y's LSAs continue to list an adjacency
to X over network segment S,regardless of the adjacency's
current synchronization state. "

Section 2.1 draft-ietf-ospf-dc-06.txt
======================================
If no acknowledgement (explicit or implicit) is received for a
predefined period of time, the probing router should treat this as
evidence of the neighbor's unreachability (proving wrong the
assumption of reachability used in [RFC1793]) and should bring the
adjacency down.

Agreeing that "graceful restart" at helper
should "override" the Nbr dead, detected by
"Nbr probing" at helper.

But my concern was, this is not very clear from
draft itself.....implementors might miss it....
so it would be better if it is explicitly mentioned
somewhere.....

But leaving it to discretion of authors.

thanks,
vivek



-----Original Message-----
From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Acee
Lindem
Sent: Friday, 6 June 2003 2:45 AM
To: OSPF@peach.ease.lsoft.com
Subject: Re: Detecting Inactive Neighbors over OSPF - repost


Abhay Roy wrote:
> Vivek,
>
> I discussed this with my co-authors.. And we think that this
> should work just fine if the router supports (and is doing)
> graceful restart..
>
> The Grace LSA tells us to continue announcing the adjacency even
> if it goes down. The restarting router will _reset_ its
> adjacencies anyways, and we are going to see this. If the probe
> goes out and fails before, the grace period should cover it.


Roy,

I was meaning to make the same point but got tied up today.

Vivek,

Look at section 3.0 in draft-ietf-ospf-hitless-restart-07.txt. Note
that the neighbor going to DOWN state doesn't necessary cause
the helper to exit graceful restart.

Thanks,
Acee


>
> Regards,
> -Roy-
>
> On 06/05/03+0530 at 4:45pm, Vivek Dubey writes:
>
>
>>if lost in flood of mails ......
>>
>>
>>-----Original Message-----
>>From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Vivek
>>Dubey
>>Sent: Saturday, 31 May 2003 12:43 PM
>>To: OSPF@peach.ease.lsoft.com
>>Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
>>Demand
>>
>>
>>Roy,
>>Adjacency will be restored up again but
>>won't the purpose of "graceful restart" somewhat
>>defeated then (NBR is needlessly considered dead -
>>though it is trying graceful restart).
>>
>>Won't it be better, if it is explicitly mentioned:
>>1)Generally graceful restart techniques should finish well before
>>  the probe retries (configurable) are finished(as you said in reply).
>>OR
>>2)If the router has received grace LSA from other end
>>  point.... delay "Nbr probing" till "graceful restart"
>>  process completes.
>>
>>thanks,
>>vivek
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Abhay
>>Roy
>>Sent: Saturday, 31 May 2003 1:17 AM
>>To: OSPF@peach.ease.lsoft.com
>>Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
>>Demand
>>
>>
>>Vivek,
>>
>>Generally graceful restart techniques should finish well before
>>the probe retries (configurable) are finished. If it does not,
>>then yes, we will consider the neighbor dead. But it's not a big
>>problem, because the adjacency will come right back up.
>>
>>I guess implementations could choose to factor in the grace period
>>to 'delay' probes.
>>
>>Regards,
>>-Roy-
>>
>>On 05/30/03+0530 at 8:48pm, Vivek Dubey writes:
>>
>>
>>>Roy,
>>>Suppose the time "Nbr probing" starts, the Ospf at the
>>>other end is undergoing "graceful restart"...(grace period
>>>1800 sec).....
>>>while probing fails at this end.....
>>>should we consdier NBR dead or there is some "safeguard"
>>>in RFC 1793 - graceful restart - and Nbr probing draft, for such
scenario.
>>>
>>>
>>>
>>>thanks,
>>>vivek
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Abhay
>>>Roy
>>>Sent: Friday, 30 May 2003 2:06 PM
>>>To: OSPF@peach.ease.lsoft.com
>>>Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
>>>Demand
>>>
>>>
>>>Mitchell,
>>>
>>>The important point to note here is that: If the originator is
>>>'reachable', DoNotAge LSA's can stay forever.
>>>
>>>Regards,
>>>-Roy-
>>>
>>>On 05/30/03-0700 at 12:20am, Erblichs writes:
>>>
>>>
>>>>Lets cover two stones with one throw..
>>>>
>>>>        Lets try part of this again..
>>>>
>>>>        In the 1793 RFC which deals with demand circuits,
>>>>        there is a 2.3 - 2) section that mentions MaxAge
>>>>        seconds, aka 3600 seconds or 1 hr.
>>>>
>>>>To ensure that these LSAs are eventually
>>>>      flushed from the routing domain, and that the size of the link
>>>>      state database doesn't grow without bound, routers are required to
>>>>      flush a DoNotAge LSA if BOTH of the following conditions are met:
>>>>
>>>>(2) The originator of the LSA has been unreachable (according to
>>>>    the routing calculations specified by Section 16 of [1]) for
>>>>            at least MaxAge seconds.
>>>>
>>>>        If probe exceeds 1 hr then LSAs are most likely
>>>>        dropped and LSAs need to be originated. Thus, tell
>>>>        me why you would want to allow LSAs to be forced
>>>>        to be re-originated in favor of a longer probe.
>>>>
>>>>        I also think you may get a dead nbr, but that is
>>>>        a different discussion point..
>>>>
>>>>        Mitchell Erblich
>>>>        Sr Software Engineer
>>>>        ---------------------
>>>>
>>>>
>>>>Mitchell,
>>>>
>>>>In case of 'always up' DC links, it does turn out to be periodic
>>>>probing. But in case of 'on demand' DC links, (if there is no data
>>>>traffic) it's of no use to bring up the link just to send probes.
>>>>So it makes sense to piggy back this event on the link coming up
>>>>event, and keep doing it periodically till the time line remains
>>>>up (due to data traffic).
>>>>
>>>>Regards,
>>>>-Roy-
>>>>
>>>>
>>>>
>>>>Abhay Roy wrote:
>>>>
>>>>>Mitchell,
>>>>>
>>>>>Why it MUST not exceed 1hr? Today it's infinity, so in theory any
>>>>>interval (including absurdly high ones) should be allowed.
>>>>>
>>>>>Regards,
>>>>>-Roy-
>>>>>
>>>>>On 05/28/03-0700 at 1:06pm, Erblichs writes:
>>>>>
>>>>>
>>>>>>Sorry group,
>>>>>>
>>>>>>        I forgot..
>>>>>>
>>>>>>        E) If ..ProbeInterval is kept, its max value MUST not exceed
>>>>>>           1 hr..
>>>>>>
>>>>>>        I think this follows that if we haven't heard from our
>>>>>>        nbr in 1 hr "he" is considered dead.
>>>>>>
>>>>>>        Mitchell Erblich
>>>>>>        -------------------
>>>>>
>>>
>>**************************************************************************
*
>>
>>>This message is proprietary to Future Software Limited (FSL)
>>>and is intended solely for the use of the individual to whom it
>>>is addressed. It may contain  privileged or confidential information
>>>and should not be circulated or used for any purpose other than for
>>>what it is intended.
>>>
>>>If you have received this message in error, please notify the
>>>originator immediately. If you are not the intended recipient,
>>>you are notified that you are strictly prohibited from using,
>>>copying, altering, or disclosing the contents of this message.
>>>FSL accepts no responsibility for loss or damage arising from
>>>the use of the information transmitted by this email including
>>>damage from virus.
>>>
>>
>>**************************************************************************
*
>>
>>**************************************************************************
*
>>This message is proprietary to Future Software Limited (FSL)
>>and is intended solely for the use of the individual to whom it
>>is addressed. It may contain  privileged or confidential information
>>and should not be circulated or used for any purpose other than for
>>what it is intended.
>>
>>If you have received this message in error, please notify the
>>originator immediately. If you are not the intended recipient,
>>you are notified that you are strictly prohibited from using,
>>copying, altering, or disclosing the contents of this message.
>>FSL accepts no responsibility for loss or damage arising from
>>the use of the information transmitted by this email including
>>damage from virus.
>>**************************************************************************
*
>>
>>**************************************************************************
*
>>This message is proprietary to Future Software Limited (FSL)
>>and is intended solely for the use of the individual to whom it
>>is addressed. It may contain  privileged or confidential information
>>and should not be circulated or used for any purpose other than for
>>what it is intended.
>>
>>If you have received this message in error, please notify the
>>originator immediately. If you are not the intended recipient,
>>you are notified that you are strictly prohibited from using,
>>copying, altering, or disclosing the contents of this message.
>>FSL accepts no responsibility for loss or damage arising from
>>the use of the information transmitted by this email including
>>damage from virus.
>>**************************************************************************
*
>>
>
>


--
Acee

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun  9 12:28:36 2003
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 MAA10628
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 Jun 2003 12:28:36 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00A0815E@cherry.ease.lsoft.com>; Mon, 9 Jun 2003 12:28:36 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45066535 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 9 Jun 2003 12:28:35 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Mon, 9 Jun 2003 12:18:35 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id MAA10314; Mon, 9 Jun 2003 12:18:31
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200306091618.MAA10314@ietf.org>
Date:         Mon, 9 Jun 2003 12:18:31 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-mirtorabi-ospf-tunnel-adjacency-00.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : OSPF Tunnel Adjacency
        Author(s)       : S. Mirtorabi, P. Psenak
        Filename        : draft-mirtorabi-ospf-tunnel-adjacency-00.txt
        Pages           : 11
        Date            : 2003-5-27

OSPF specification requires that intra-area paths are always
preferred over Inter-area paths regardless of the path's cost. This
document describes a solution that will remedy this limitation
without introducing any significant change to the current
specification. Further, this solution provides some other benefits
such as automatic partition repair described in application section.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunnel-adjacency-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-mirtorabi-ospf-tunnel-adjacency-00.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-mirtorabi-ospf-tunnel-adjacency-00.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:     <2003-6-9123503.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-mirtorabi-ospf-tunnel-adjacency-00.txt

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

Content-Type: text/plain
Content-ID:     <2003-6-9123503.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 10 11:02:03 2003
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 LAA04530
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Jun 2003 11:02:02 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00A0A2DE@cherry.ease.lsoft.com>; Tue, 10 Jun 2003 11:01:58 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45163024 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 10 Jun 2003 11:01:55 -0400
Received: from 192.75.23.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 10 Jun 2003 11:01:55 -0400
Received: (qmail 28815 invoked from network); 10 Jun 2003 15:04:30 -0000
Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by
          kanmx2.ca.alcatel.com with SMTP; 10 Jun 2003 15:04:30 -0000
Received: from alcatel.com ([138.120.62.63]) by camail03.ca.alcatel.com
          (Netscape Messaging Server 4.15) with ESMTP id HG9TR600.IVS; Tue, 10
          Jun 2003 11:01:54 -0400
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3EE5F2DD.9794A0F@alcatel.com>
Date:         Tue, 10 Jun 2003 11:01:49 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Cheng-Yin Lee <Cheng-Yin.Lee@ALCATEL.COM>
Subject: Inconsistent view of routers over a LAN
Comments: cc: isis-wg@ietf.org
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hello,
What happens if for some reason Router A can't reach Router B, but
Router C can reach A & B (and vice-versa), when Router A,B,C are
connected over a broadcast network or LAN.

E.g. in the case for (OSPF and IS-IS) where:
i) C is the DR
ii) B is the DR


Thanks
Cheng-Yin


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 10 11:54:07 2003
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 LAA06443
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Jun 2003 11:54:07 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A0A3A3@cherry.ease.lsoft.com>; Tue, 10 Jun 2003 11:54:07 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45168320 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 10 Jun 2003 11:54:05 -0400
Received: from 192.75.23.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 10 Jun 2003 11:54:04 -0400
Received: (qmail 26685 invoked from network); 10 Jun 2003 15:55:01 -0000
Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by
          kanmx2.ca.alcatel.com with SMTP; 10 Jun 2003 15:55:01 -0000
Received: from alcatel.com ([138.120.62.63]) by camail03.ca.alcatel.com
          (Netscape Messaging Server 4.15) with ESMTP id HG9W3C00.KYM; Tue, 10
          Jun 2003 11:52:24 -0400
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <3EE5F2DD.9794A0F@alcatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3EE5FEB3.156FB9E3@alcatel.com>
Date:         Tue, 10 Jun 2003 11:52:19 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Cheng-Yin Lee <Cheng-Yin.Lee@ALCATEL.COM>
Subject: Re: Inconsistent view of routers over a LAN
Comments: cc: isis-wg@ietf.org
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hello,
Just got some private responses, perhaps I should clarify.
This is in context of an emulated LAN, and I am not looking for a fix in
routing protocols.

Thanks
Cheng-Yin

Cheng-Yin Lee wrote:
>
> Hello,
> What happens if for some reason Router A can't reach Router B, but
> Router C can reach A & B (and vice-versa), when Router A,B,C are
> connected over a broadcast network or LAN.
>
> E.g. in the case for (OSPF and IS-IS) where:
> i) C is the DR
> ii) B is the DR
>
> Thanks
> Cheng-Yin


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 10 13:15:57 2003
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 NAA09656
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Jun 2003 13:15:56 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00A0A87D@cherry.ease.lsoft.com>; Tue, 10 Jun 2003 13:15:56 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45185648 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 10 Jun 2003 13:15:55 -0400
Received: from 24.93.67.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 10 Jun 2003 13:15:55 -0400
Received: from redback.com (rdu162-240-050.nc.rr.com [24.162.240.50]) by
          ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id
          h5AHAOTp000722 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 10 Jun 2003
          13:10:24 -0400 (EDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <3EE5F2DD.9794A0F@alcatel.com> <3EE5FEB3.156FB9E3@alcatel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EE61252.5020304@redback.com>
Date:         Tue, 10 Jun 2003 13:16:02 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Inconsistent view of routers over a LAN
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Cheng-Yin Lee wrote:
> Hello,
> Just got some private responses, perhaps I should clarify.
> This is in context of an emulated LAN, and I am not looking for a fix in
> routing protocols.

Hi Cheng-Yin,

What I've recommended in the past for these situations is to force
the routing protocol to view the underlying network as a P2MP
(Point-to-Multi-Point) network. Many vendors support this. For
example, in our implementation you'd simply configure:

   router ospf 1
    area 0
     interface backbone
      network-type point-to-multipoint
               o
               o
          < the rest of the OSPF config>
               o

Good Luck,
Acee


>
> Thanks
> Cheng-Yin
>
> Cheng-Yin Lee wrote:
>
>>Hello,
>>What happens if for some reason Router A can't reach Router B, but
>>Router C can reach A & B (and vice-versa), when Router A,B,C are
>>connected over a broadcast network or LAN.
>>
>>E.g. in the case for (OSPF and IS-IS) where:
>>i) C is the DR
>>ii) B is the DR
>>
>>Thanks
>>Cheng-Yin
>
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 10 16:07:41 2003
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 QAA15587
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Jun 2003 16:07:41 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A0AD28@cherry.ease.lsoft.com>; Tue, 10 Jun 2003 16:07:40 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45200914 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 10 Jun 2003 16:07:36 -0400
Received: from 24.93.67.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 10 Jun 2003 16:07:35 -0400
Received: from redback.com (rdu162-240-050.nc.rr.com [24.162.240.50]) by
          ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id
          h5AK5u8V029608 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 10 Jun 2003
          16:05:57 -0400 (EDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EE63A8C.80104@redback.com>
Date:         Tue, 10 Jun 2003 16:07:40 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Address Family Support in OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

At the last IETF, the draft draft-mirtorabi-ospfv3-AF-00.txt was
presented. It proposes to make some protocol changes to OSPFv3 now
in case we ever want to support multiple address families (e.g.,
permutations of IPv4, IPv6, unicast, and multicast).

The draft raised a moderate level of technical discussion (mainly
centered on the proposal's backward compatibility mechanism). The
big question is whether or not there is a real requirement for this?
We all know this is done in ISIS but that doesn't necessarily mean
there is a requirement. And if there is, could the requirement better
be satisfied with multiple OSPFv3 instances. On the other hand, we
really want to get the protocol changes in as early as possible if
we ever want to support multiple address families.

Comments? I have some additional considerations that I will put
in a separate E-mail.

--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 10 16:43:22 2003
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 QAA16980
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Jun 2003 16:43:21 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00A0AEE0@cherry.ease.lsoft.com>; Tue, 10 Jun 2003 16:43:22 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45203764 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 10 Jun 2003 16:43:20 -0400
Received: from 192.75.23.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 10 Jun 2003 16:43:20 -0400
Received: (qmail 18800 invoked from network); 10 Jun 2003 20:53:01 -0000
Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by
          kanmx1.ca.alcatel.com with SMTP; 10 Jun 2003 20:53:01 -0000
Received: from alcatel.com ([138.120.62.63]) by camail03.ca.alcatel.com
          (Netscape Messaging Server 4.15) with ESMTP id HGA9K500.H6D; Tue, 10
          Jun 2003 16:43:17 -0400
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <D2EC481073504E498A8DB9C0687E8CAF0731FE9A@EXCHANGE0-0.na.procket.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3EE642E0.F617107F@alcatel.com>
Date:         Tue, 10 Jun 2003 16:43:12 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Cheng-Yin Lee <Cheng-Yin.Lee@ALCATEL.COM>
Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN
Comments: To: Tony Li <Tony.Li@procket.com>
Comments: cc: Jeff Learman <jlearman@cisco.com>,
          isis-wg@ietf.org, Acee Lindem <acee@REDBACK.COM>, l2vpn@ietf.org
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Jeff, Tony, Acee,
Thanks for your clarification.
L2VPN WG is defining emulated LAN (and broadcast network for IP traffic)
service over IP/MPLS network and some of the mechanims being defined can
result in loss of communication among a subset of routers on the
emulated LAN (even if all the nodes in the underlying IP/MPLS transport
network are reachable).
Some of the discussions have been how tolerable are routing protocols to
this type of problem, if it is worth fixing some L2VPN WG mechanisms to
prevent this problem, how feasible are these L2VPN solutions, are these
not well-known problems ...

I hope the L2VPN WG would consider these issues and requirements in the
L2VPN solutions.
Perhaps a more detailed understanding of how things work/don't work may
help L2VPN WG develop/appreciate solutios that will work well with
routers for e.g, in case of (i) below, what would an emulated LAN user
observe in the routed network (is this predictable/unpredictable?)

Thanks
Cheng-Yin
p.s I have cced l2vpn, but pls feel free to respond only to the relevant
WG as is appropriate.

Tony Li wrote:
>
> We should also point out that in case i) things are truly broken and
> in case ii) the DR will not form an adjacency with A and the protocols
> will be able to tell that things are broken.
>
> Tony
>
> |    -----Original Message-----
> |    From: Jeff Learman [mailto:jlearman@cisco.com]
> |    Sent: Tuesday, June 10, 2003 9:29 AM
> |    To: Cheng-Yin.Lee@alcatel.com
> |    Cc: Mailing List; isis-wg@ietf.org
> |    Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN
> |
> |
> |
> |    This violates the transitivity requirement stated in ISO 10589.
> |    You can't run ISIS on a subnetwork where this happens.
> |    At least, that's the theory ;)
> |
> |    At 11:52 AM 6/10/2003, Cheng-Yin Lee wrote:
> |    >Hello,
> |    >Just got some private responses, perhaps I should clarify.
> |    >This is in context of an emulated LAN, and I am not
> |    looking for a fix in
> |    >routing protocols.
> |    >
> |    >Thanks
> |    >Cheng-Yin
> |    >
> |    >Cheng-Yin Lee wrote:
> |    >>
> |    >> Hello,
> |    >> What happens if for some reason Router A can't reach
> |    Router B, but
> |    >> Router C can reach A & B (and vice-versa), when Router A,B,C are
> |    >> connected over a broadcast network or LAN.
> |    >>
> |    >> E.g. in the case for (OSPF and IS-IS) where:
> |    >> i) C is the DR
> |    >> ii) B is the DR
> |    >>
> |    >> Thanks
> |    >> Cheng-Yin


> Hi Cheng-Yin,
>
> What I've recommended in the past for these situations is to force
> the routing protocol to view the underlying network as a P2MP
> (Point-to-Multi-Point) network. Many vendors support this. For
> example, in our implementation you'd simply configure:
>
>    router ospf 1
>     area 0
>      interface backbone
>       network-type point-to-multipoint
>                o
>                o
>           < the rest of the OSPF config>
>                o
>
> Good Luck,
> Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 10 17:14:25 2003
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 RAA18229
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Jun 2003 17:14:24 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00A0AF08@cherry.ease.lsoft.com>; Tue, 10 Jun 2003 17:14:24 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45206850 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 10 Jun 2003 17:14:23 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 10 Jun 2003 17:14:21 -0400
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by
          prattle.redback.com (Postfix) with ESMTP id 78EA01498EB; Tue, 10 Jun
          2003 14:14:20 -0700 (PDT)
Message-ID:  <20030610211420.78EA01498EB@prattle.redback.com>
Date:         Tue, 10 Jun 2003 14:14:20 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Naiming Shen <naiming@REDBACK.COM>
Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN
Comments: To: Cheng-Yin.Lee@alcatel.com
Comments: cc: Tony Li <Tony.Li@procket.com>, Jeff Learman <jlearman@cisco.com>,
          isis-wg@ietf.org, Acee Lindem <acee@redback.com>, l2vpn@ietf.org
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  Mail from "Cheng-Yin Lee" <Cheng-Yin.Lee@alcatel.com> dated Tue,
              10 Jun 2003 16:43:12 EDT <3EE642E0.F617107F@alcatel.com>
Precedence: list

i don't think l2vpn wg needs to do much. when use link-state igp
in those places, ALWAYS assume it's unreliable. just use p2p. period.

 ] Jeff, Tony, Acee,
 ] Thanks for your clarification.
 ] L2VPN WG is defining emulated LAN (and broadcast network for IP traffic)
 ] service over IP/MPLS network and some of the mechanims being defined can
 ] result in loss of communication among a subset of routers on the
 ] emulated LAN (even if all the nodes in the underlying IP/MPLS transport
 ] network are reachable).
 ] Some of the discussions have been how tolerable are routing protocols to
 ] this type of problem, if it is worth fixing some L2VPN WG mechanisms to
 ] prevent this problem, how feasible are these L2VPN solutions, are these
 ] not well-known problems ...
 ]
 ] I hope the L2VPN WG would consider these issues and requirements in the
 ] L2VPN solutions.
 ] Perhaps a more detailed understanding of how things work/don't work may
 ] help L2VPN WG develop/appreciate solutios that will work well with
 ] routers for e.g, in case of (i) below, what would an emulated LAN user
 ] observe in the routed network (is this predictable/unpredictable?)
 ]
 ] Thanks
 ] Cheng-Yin
 ] p.s I have cced l2vpn, but pls feel free to respond only to the relevant
 ] WG as is appropriate.
 ]
 ] Tony Li wrote:
 ] >
 ] > We should also point out that in case i) things are truly broken and
 ] > in case ii) the DR will not form an adjacency with A and the protocols
 ] > will be able to tell that things are broken.
 ] >
 ] > Tony
 ] >
 ] > |    -----Original Message-----
 ] > |    From: Jeff Learman [mailto:jlearman@cisco.com]
 ] > |    Sent: Tuesday, June 10, 2003 9:29 AM
 ] > |    To: Cheng-Yin.Lee@alcatel.com
 ] > |    Cc: Mailing List; isis-wg@ietf.org
 ] > |    Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN
 ] > |
 ] > |
 ] > |
 ] > |    This violates the transitivity requirement stated in ISO 10589.
 ] > |    You can't run ISIS on a subnetwork where this happens.
 ] > |    At least, that's the theory ;)
 ] > |
 ] > |    At 11:52 AM 6/10/2003, Cheng-Yin Lee wrote:
 ] > |    >Hello,
 ] > |    >Just got some private responses, perhaps I should clarify.
 ] > |    >This is in context of an emulated LAN, and I am not
 ] > |    looking for a fix in
 ] > |    >routing protocols.
 ] > |    >
 ] > |    >Thanks
 ] > |    >Cheng-Yin
 ] > |    >
 ] > |    >Cheng-Yin Lee wrote:
 ] > |    >>
 ] > |    >> Hello,
 ] > |    >> What happens if for some reason Router A can't reach
 ] > |    Router B, but
 ] > |    >> Router C can reach A & B (and vice-versa), when Router A,B,C are
 ] > |    >> connected over a broadcast network or LAN.
 ] > |    >>
 ] > |    >> E.g. in the case for (OSPF and IS-IS) where:
 ] > |    >> i) C is the DR
 ] > |    >> ii) B is the DR
 ] > |    >>
 ] > |    >> Thanks
 ] > |    >> Cheng-Yin
 ]
 ]
 ] > Hi Cheng-Yin,
 ] >
 ] > What I've recommended in the past for these situations is to force
 ] > the routing protocol to view the underlying network as a P2MP
 ] > (Point-to-Multi-Point) network. Many vendors support this. For
 ] > example, in our implementation you'd simply configure:
 ] >
 ] >    router ospf 1
 ] >     area 0
 ] >      interface backbone
 ] >       network-type point-to-multipoint
 ] >                o
 ] >                o
 ] >           < the rest of the OSPF config>
 ] >                o
 ] >
 ] > Good Luck,
 ] > Acee
 ] _______________________________________________
 ] Isis-wg mailing list
 ] Isis-wg@ietf.org
 ] https://www1.ietf.org/mailman/listinfo/isis-wg

- Naiming


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 10 19:29:10 2003
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 TAA22805
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Jun 2003 19:29:10 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A0B31C@cherry.ease.lsoft.com>; Tue, 10 Jun 2003 19:29:11 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45216078 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 10 Jun 2003 19:29:10 -0400
Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Tue, 10 Jun 2003 19:29:09 -0400
Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp
          (Postfix) with ESMTP id 6196D3741; Wed, 11 Jun 2003 08:29:07 +0900
          (JST)
References: <20030605124150.51373.qmail@web9504.mail.yahoo.com>
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <20030611.082906.09627731.yasu@sfc.wide.ad.jp>
Date:         Wed, 11 Jun 2003 08:29:06 +0900
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Yasuhiro Ohara <yasu@SFC.WIDE.AD.JP>
Subject: Re: MOSPF can't determine the receiving interface exactly - In John Moy's book OSPF Anatomy of a Routing Protocol
Comments: To: ijpotts_lists@YAHOO.CO.UK
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <20030605124150.51373.qmail@web9504.mail.yahoo.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi, I try to explain.

Even in your example, actually you don't determine the receiving half
of the point-to-point link. You can only know the receiving interface
of the other router by *guessing*, and you can guess only because
they don't have any other links to the same router.

Let's suppose your example have two point-to-point links between
Router 1 and Router 2 as it will be easier to understand.
(The book also mentions that configuration, "when multiple
point-to-point links connect the router to the neighbor"
in the same section)

The Router-LSAs in the database will be like below.

Router 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 144.141.252.254
     (Link Data) Router Interface address: 144.128.254.138
      Number of TOS metrics: 0
       TOS 0 Metrics: 1000

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 144.141.252.254
     (Link Data) Router Interface address: 10.1.1.1 (or whatever)
      Number of TOS metrics: 0
       TOS 0 Metrics: 10000 (or whatever)

Router 2

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 144.141.89.2
     (Link Data) Router Interface address: 144.128.254.137
      Number of TOS metrics: 0
       TOS 0 Metrics: 1000

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 144.141.89.2
     (Link Data) Router Interface address: 192.168.0.1 (or whatever)
      Number of TOS metrics: 0
       TOS 0 Metrics: 10000 (or whatever)

Then, can you illustrate the network configuration, specifically
which interface of Router 1 is connected to the interface which is
described as Link-Description #1 in the Router 2's Router-LSA ?
Why ?

Note that point-to-point link can be configured not to share the
IP-subnet. So Router 1's interface having address 144.128.254.138
may not necessarily be connected to the Router 2's interface having
address 144.128.254.137.

For the multicast forwarding of direction from Router 1 to Router 2,
both router can calculate that Router 1 should send the datagrams
on the interface #1 (having address 144.128.254.138), because it has
lower cost. But neither router can determine which interface the
Router 2 will receive that datagram on.

This problem is resolved in OSPFv3 as each single Link Description in
Router-LSA describes both sending and receiving halves (by describing
both side of IfIndex). OSPFv2's Link Description only describes sending
half and the *Router-ID* of receiving router. It doesn't describe
receiving half (interface) of receiving router.

Hope this helps.

regards,
yasu

From: Ian Potts <ijpotts_lists@YAHOO.CO.UK>
Subject: MOSPF can't determine the receiving interface exactly - In John Moy's book OSPF Anatomy of a Routing Protocol
Date: Thu, 5 Jun 2003 13:41:50 +0100

> Hello,
>
> In John Moy's excellent book, Anatomy of an Internet
> Routing Protocol, on page 195 (section 10.3.1 The
> Multicast Forwarding Cache), it states that a router
> does the RPF check in MOSPF on the router's ID, and
> not on the incoming interface, since MOSPF can't
> determine the receiving interface exactly, since there
> is insufficient information in the OSPF lsdb to match
> the sending and receiving halves.
>
> Can someone please explain this to me since I am
> confused.  Looking at the router LSAs given below,
> can't the router first work out the router-id, then
> consult the routing table to find the interface?
>
> Many Thanks
> Ian
>
> Router 1
>
>     Link connected to: another Router (point-to-point)
>      (Link ID) Neighboring Router ID: 144.141.252.254
>      (Link Data) Router Interface address: 144.128.254.138
>       Number of TOS metrics: 0
>        TOS 0 Metrics: 1000
>
>     Link connected to: a Stub Network
>      (Link ID) Network/subnet number: 144.128.254.136
>      (Link Data) Network Mask: 255.255.255.248
>       Number of TOS metrics: 0
>        TOS 0 Metrics: 1000
>
> Router 2
>
> Link connected to: another Router (point-to-point)
>      (Link ID) Neighboring Router ID: 144.141.89.2
>      (Link Data) Router Interface address: 144.128.254.137
>       Number of TOS metrics: 0
>        TOS 0 Metrics: 1000
>
>     Link connected to: a Stub Network
>      (Link ID) Network/subnet number: 144.128.254.136
>      (Link Data) Network Mask: 255.255.255.248
>       Number of TOS metrics: 0
>        TOS 0 Metrics: 1000
>
>
>
>
> __________________________________________________
> Yahoo! Plus - For a better Internet experience
> http://uk.promotions.yahoo.com/yplus/yoffer.html


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 11 07:23:51 2003
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 HAA02681
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Jun 2003 07:23:50 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00A0D250@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 7:23:49 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45293249 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 11 Jun 2003 07:23:48 -0400
Received: from 203.199.83.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Wed, 11 Jun 2003 07:23:47 -0400
Received: (qmail 29953 invoked by uid 510); 11 Jun 2003 11:23:43 -0000
Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 11 jun
          2003 11:23:43 -0000
MIME-Version: 1.0
Content-type: text/plain; format=flowed
Content-Disposition: inline
Message-ID:  <20030611112343.29951.qmail@webmail27.rediffmail.com>
Date:         Wed, 11 Jun 2003 11:23:43 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Krishna Rao <ospf_query@REDIFFMAIL.COM>
Subject: Secondary IP address
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi,
       Secondary IP address usage in OSPF is little shaddy. Should
we allow secondary address to be advertised in point-to-point and
point-to-multipoint?

Regards,
Krishna
___________________________________________________
Get email that means BUSINESS! me @ mycompany.com.
Just Rs.1499/year.
To start, click http://www.rediffmailpro.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 11 09:12:45 2003
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 JAA07592
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Jun 2003 09:12:45 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A0D7AA@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 9:12:44 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45299259 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 11 Jun 2003 09:11:47 -0400
Received: from 24.93.67.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Wed, 11 Jun 2003 09:11:45 -0400
Received: from redback.com (rdu162-240-050.nc.rr.com [24.162.240.50]) by
          ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id
          h5BD93UD003776 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 11 Jun 2003
          09:09:04 -0400 (EDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <20030611112343.29951.qmail@webmail27.rediffmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EE72A8C.4060904@redback.com>
Date:         Wed, 11 Jun 2003 09:11:40 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Secondary IP address
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Krishna,

Krishna Rao wrote:
> Hi,
>       Secondary IP address usage in OSPF is little shaddy.

Paraphrasing Mark Twain, "The rumors of the lack of OSPF
support for secondary addresses are greatly exaggerated."

OSPFv2 runs a subnet and makes no distinction as to whether or
not the subnet is primary or secondary. There is at least one
heavily deployed implementation that doesn't support OSPF on
secondary addresses.

 From section 1.2 of RFC 2328:

         Network
             In this memo, an IP network/subnet/supernet.  It is possible
             for one physical network to be assigned multiple IP
             network/subnet numbers.  We consider these to be separate
             networks.  Point-to-point physical networks are an exception
             - they are considered a single network no matter how many
             (if any at all) IP network/subnet numbers are assigned to
             them.

         Interface
             The connection between a router and one of its attached
             networks.  An interface has state information associated
             with it, which is obtained from the underlying lower level
             protocols and the routing protocol itself.  An interface to
             a network has associated with it a single IP address and
             mask (unless the network is an unnumbered point-to-point
             network).  An interface is sometimes also referred to as a
             link.

> Should
> we allow secondary address to be advertised in point-to-point and
> point-to-multipoint?

 From the above, it seems the answer should be yes for P2MP and no
for P2P. However, in our implementation we do allow OSPF
to be configured on multiple subnets on a P2P interface. This
allows the P2P interface to be an intra-area link in more than one
area.

>
> Regards,
> Krishna
> ___________________________________________________
> Get email that means BUSINESS! me @ mycompany.com.
> Just Rs.1499/year.
> To start, click http://www.rediffmailpro.com
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 11 15:30:25 2003
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 PAA23942
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Jun 2003 15:30:25 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00A0E4E1@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 15:30:24 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45327364 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 11 Jun 2003 15:30:23 -0400
Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Wed, 11 Jun 2003 15:30:23 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <12.00A0E377@cherry.ease.lsoft.com>;
          Wed, 11 Jun 2003 15:30:22 -0400
Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Wed, 11 Jun 2003 15:30:22 -0400
Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by
          mail4.nec.com (/) with ESMTP id h5BJUJmX010093 for
          <osPF@discuss.microsoft.com>; Wed, 11 Jun 2003 12:30:19 -0700 (PDT)
Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by
          netkeeper.sj.nec.com (/) with ESMTP id h5BJUEfh010966 for
          <osPF@discuss.microsoft.com>; Wed, 11 Jun 2003 12:30:14 -0700 (PDT)
Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by
          necsun.tdd.sj.nec.com (8.12.9/8.12.9) with ESMTP id h5BJJODp025273
          for <osPF@discuss.microsoft.com>; Wed, 11 Jun 2003 12:19:24 -0700
          (PDT)
Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com
          (8.12.9/8.12.9) with SMTP id h5BJJM8C006101 for
          <osPF@discuss.microsoft.com>; Wed, 11 Jun 2003 12:19:22 -0700 (PDT)
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Message-ID:  <004f01c33050$f54c6f90$1105f183@b90.tdd.sj.nec.com>
Date:         Wed, 11 Jun 2003 12:37:56 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: kamatchi soundaram <kamatchi@TDD.SJ.NEC.COM>
Subject: DR Election! clarification
Comments: To: osPF@discuss.microsoft.com
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi,

  Lets assume there are three routers R1, R2 and R3 are connected to LAN
(broadcast network -- N1). Assume priority of all routers R1, R2 and R3's
interface connecting to N1 is 1.

Assume, presently R1 is DR and R2 is BDR.

My Question follows:

If i dynamically change the priority of R3's interface to 2, what would be
the expected operation of OSPF as per RFC.

1) Will R3 becomes New DR or BDR??
or 2) There will not be any change in the interface state machine??

Thanks,
Kamatchi.


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 11 16:08:00 2003
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 QAA24320
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Jun 2003 16:08:00 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00A0E598@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 16:08:01 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45330429 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 11 Jun 2003 16:07:59 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Wed, 11 Jun 2003 16:07:59 -0400
Received: from redback.com (montreal.redback.com [155.53.42.143]) by
          prattle.redback.com (Postfix) with ESMTP id E33E29C4611 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 11 Jun 2003 13:07:58 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.1) Gecko/20020829
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <004f01c33050$f54c6f90$1105f183@b90.tdd.sj.nec.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EE78C1E.4070003@redback.com>
Date:         Wed, 11 Jun 2003 13:07:58 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Rikki Nguyen <rikki@REDBACK.COM>
Subject: Re: DR Election! clarification
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

no change.

the router priority change will cause all routers to re-perform
the DR election.  but since there is exactly one DR and one BDR,
the same routers will be re-elected.  the router priority only
comes into play when multiple or no routers declare themsleves
DR/BDR.

kamatchi soundaram wrote:
> Hi,
>
>   Lets assume there are three routers R1, R2 and R3 are connected to LAN
> (broadcast network -- N1). Assume priority of all routers R1, R2 and R3's
> interface connecting to N1 is 1.
>
> Assume, presently R1 is DR and R2 is BDR.
>
> My Question follows:
>
> If i dynamically change the priority of R3's interface to 2, what would be
> the expected operation of OSPF as per RFC.
>
> 1) Will R3 becomes New DR or BDR??
> or 2) There will not be any change in the interface state machine??
>
> Thanks,
> Kamatchi.
>


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 11 16:09:14 2003
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 QAA26271
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Jun 2003 16:09:14 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00A0E346@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 16:09:15 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45330501 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 11 Jun 2003 16:09:13 -0400
Received: from 207.217.120.126 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Wed, 11 Jun 2003 16:09:13 -0400
Received: from user-38ldvsd.dialup.mindspring.com ([209.86.255.141]
          helo=earthlink.net) by turkey.mail.pas.earthlink.net with esmtp (Exim
          3.33 #1) id 19QBuC-0005h7-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11
          Jun 2003 13:09:12 -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: <004f01c33050$f54c6f90$1105f183@b90.tdd.sj.nec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3EE788E8.21377305@earthlink.net>
Date:         Wed, 11 Jun 2003 12:54:16 -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! clarification
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Kamatchi,

        Once a DR and/or a BDR is elected on a
        interface in OSPF, it doesn't change
        unless either vacates itself as the DR
        and/or BDR OR sometime in the future
        their is announcement that a 2nd DR/BDR
        is also present.

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

kamatchi soundaram wrote:
>
> Hi,
>
>   Lets assume there are three routers R1, R2 and R3 are connected to LAN
> (broadcast network -- N1). Assume priority of all routers R1, R2 and R3's
> interface connecting to N1 is 1.
>
> Assume, presently R1 is DR and R2 is BDR.
>
> My Question follows:
>
> If i dynamically change the priority of R3's interface to 2, what would be
> the expected operation of OSPF as per RFC.
>
> 1) Will R3 becomes New DR or BDR??
> or 2) There will not be any change in the interface state machine??
>
> Thanks,
> Kamatchi.


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 11 18:29:16 2003
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 SAA07268
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Jun 2003 18:29:15 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00A0EBFC@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 18:29:15 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45342252 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 11 Jun 2003 18:29:12 -0400
Received: from 192.75.23.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Wed, 11 Jun 2003 18:29:12 -0400
Received: (qmail 3390 invoked from network); 11 Jun 2003 22:31:47 -0000
Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by
          kanmx2.ca.alcatel.com with SMTP; 11 Jun 2003 22:31:47 -0000
Received: from alcatel.com ([138.120.62.63]) by camail03.ca.alcatel.com
          (Netscape Messaging Server 4.15) with ESMTP id HGC94M00.5RB; Wed, 11
          Jun 2003 18:29:10 -0400
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <D2EC481073504E498A8DB9C0687E8CAF067D31A6@EXCHANGE0-0.na.procket.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3EE7AD2E.B9773CEF@alcatel.com>
Date:         Wed, 11 Jun 2003 18:29:02 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Cheng-Yin Lee <Cheng-Yin.Lee@ALCATEL.COM>
Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN
Comments: To: Tony Li <Tony.Li@procket.com>
Comments: cc: Jeff Learman <jlearman@cisco.com>,
          isis-wg@ietf.org, Acee Lindem <acee@redback.com>, l2vpn@ietf.org
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Tony, Naiming,
Thanks for clarifying this further and providing suggestions.

I would agree that it's better to use point-to-point links (or OSPF's
multipoint) when there are such problems.
As known, this is not a problem in a real LAN segment or emulated LAN
segment, provided by a bridged LAN (bridging over real LAN segments) or
bridging over circuits.
As has been brought up in the OSPF/IS-IS mailing lists, it is when the
emulated LAN (broadcast network) uses an approach whereby a full-meshed
of communication is required and there is a requirement that every
communication channel is working that this becomes a problem for routing
(and for bridges too).

There have been some proposals to overcome the problems in the
full-meshed approach, e.g. disabling the emulated LAN when one or more
connectivity loss is detected or artificially partitioning the emulated
LAN, or engineer the transport network in such a way that communication
failure never/rarely happens from the perspective of the user of the
service (e.g. routers).
More protocol mechanisms (and perhaps some heuristics) may be used to
emulate a proper LAN failure, but I think it not easy to get this
working (it also raises the question, is this the only compelling way),
in particular because of race/timing issues.
Can an operator engineer a network such that the pseudo-wire or
communications never or "rarely" fail from the perspective of
routers/bridges? What is the cost and effectiveness (backup and
rerouting pseudo-wire may not be sufficient as there can be many other
reasons why communication is lost) in this case?

I hope the L2VPN WG would consider these service issues as carefully as
L2VPN discovery protocols because even the best L2VPN discovery
protocols cannot help if the L2VPN service itself does not work well
with routers and bridges.

Thanks
Cheng-Yin

Tony Li wrote:
>
> Folks,
>
> In particular, if there is a disconnect on a broadcast medium
> between two routers and neither is the DR, then the two routers
> will present a black hole between them.  This problem has been
> seen before in real life and is Not Pretty.
>
> For this reason alone, I would encourage you to model any L2
> solution as a number of point-to-point links.
>
> Regards,
> Tony


Naiming Shen wrote:
>
> i don't think l2vpn wg needs to do much. when use link-state igp
> in those places, ALWAYS assume it's unreliable. just use p2p. period.
>

>
> |    -----Original Message-----
> |    From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com]
> |    Sent: Tuesday, June 10, 2003 1:43 PM
> |    To: Tony Li
> |    Cc: Jeff Learman; Mailing List; isis-wg@ietf.org; Acee
> |    Lindem; l2vpn@ietf.org
> |    Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN
> |
> |
> |    Jeff, Tony, Acee,
> |    Thanks for your clarification.
> |    L2VPN WG is defining emulated LAN (and broadcast network
> |    for IP traffic)
> |    service over IP/MPLS network and some of the mechanims
> |    being defined can
> |    result in loss of communication among a subset of routers on the
> |    emulated LAN (even if all the nodes in the underlying
> |    IP/MPLS transport
> |    network are reachable).
> |    Some of the discussions have been how tolerable are
> |    routing protocols to
> |    this type of problem, if it is worth fixing some L2VPN WG
> |    mechanisms to
> |    prevent this problem, how feasible are these L2VPN
> |    solutions, are these
> |    not well-known problems ...
> |
> |    I hope the L2VPN WG would consider these issues and
> |    requirements in the
> |    L2VPN solutions.
> |    Perhaps a more detailed understanding of how things
> |    work/don't work may
> |    help L2VPN WG develop/appreciate solutios that will work well with
> |    routers for e.g, in case of (i) below, what would an
> |    emulated LAN user
> |    observe in the routed network (is this predictable/unpredictable?)
> |
> |    Thanks
> |    Cheng-Yin
> |    p.s I have cced l2vpn, but pls feel free to respond only
> |    to the relevant
> |    WG as is appropriate.
> |
> |    Tony Li wrote:
> |    >
> |    > We should also point out that in case i) things are
> |    truly broken and
> |    > in case ii) the DR will not form an adjacency with A and
> |    the protocols
> |    > will be able to tell that things are broken.
> |    >
> |    > Tony
> |    >
> |    > |    -----Original Message-----
> |    > |    From: Jeff Learman [mailto:jlearman@cisco.com]
> |    > |    Sent: Tuesday, June 10, 2003 9:29 AM
> |    > |    To: Cheng-Yin.Lee@alcatel.com
> |    > |    Cc: Mailing List; isis-wg@ietf.org
> |    > |    Subject: Re: [Isis-wg] Re: Inconsistent view of
> |    routers over a LAN
> |    > |
> |    > |
> |    > |
> |    > |    This violates the transitivity requirement stated
> |    in ISO 10589.
> |    > |    You can't run ISIS on a subnetwork where this happens.
> |    > |    At least, that's the theory ;)
> |    > |
> |    > |    At 11:52 AM 6/10/2003, Cheng-Yin Lee wrote:
> |    > |    >Hello,
> |    > |    >Just got some private responses, perhaps I should clarify.
> |    > |    >This is in context of an emulated LAN, and I am not
> |    > |    looking for a fix in
> |    > |    >routing protocols.
> |    > |    >
> |    > |    >Thanks
> |    > |    >Cheng-Yin
> |    > |    >
> |    > |    >Cheng-Yin Lee wrote:
> |    > |    >>
> |    > |    >> Hello,
> |    > |    >> What happens if for some reason Router A can't reach
> |    > |    Router B, but
> |    > |    >> Router C can reach A & B (and vice-versa), when
> |    Router A,B,C are
> |    > |    >> connected over a broadcast network or LAN.
> |    > |    >>
> |    > |    >> E.g. in the case for (OSPF and IS-IS) where:
> |    > |    >> i) C is the DR
> |    > |    >> ii) B is the DR
> |    > |    >>
> |    > |    >> Thanks
> |    > |    >> Cheng-Yin
> |
> |
> |    > Hi Cheng-Yin,
> |    >
> |    > What I've recommended in the past for these situations
> |    is to force
> |    > the routing protocol to view the underlying network as a P2MP
> |    > (Point-to-Multi-Point) network. Many vendors support this. For
> |    > example, in our implementation you'd simply configure:
> |    >
> |    >    router ospf 1
> |    >     area 0
> |    >      interface backbone
> |    >       network-type point-to-multipoint
> |    >                o
> |    >                o
> |    >           < the rest of the OSPF config>
> |    >                o
> |    >
> |    > Good Luck,
> |    > Acee
> |
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www1.ietf.org/mailman/listinfo/isis-wg


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 11 18:55:52 2003
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 SAA08317
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Jun 2003 18:55:52 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00A0EB2F@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 18:55:53 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45344013 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 11 Jun 2003 18:55:52 -0400
Received: from 203.14.180.204 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Wed, 11 Jun 2003 18:55:52 -0400
Received: (qmail 6070 invoked from network); 11 Jun 2003 23:15:23 -0000
Received: from mailmon2.aapt.com.au (172.19.200.193) by 0 with SMTP; 11 Jun
          2003 23:15:23 -0000
Received: from QMAIL-Message_Server by aapt-gwia2.aapt.com.au with
          Novell_GroupWise; Thu, 12 Jun 2003 08:55:49 +1000
X-Mailer: Novell GroupWise 5.5.4
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Message-ID:  <see84015.009@aapt-gwia2.aapt.com.au>
Date:         Thu, 12 Jun 2003 08:55:34 +1000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Paresh Khatri <pkhatri@AAPT.COM.AU>
Subject: Clarification on Flooding
Comments: To: OSPF@.EASE.LSOFT.COM
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA08317

HI all,

Would someone be able to explain the following clause in RFC2328 to me ?

This is in Section 13. Flooding Procedure:

    Page 145
    (6) Else, if there is an instance of the LSA on the sending
        neighbor's Link state request list, an error has occurred in the
        Database Exchange process.  In this case, restart the Database
        Exchange process by generating the neighbor event BadLSReq for
        the sending neighbor and stop processing the Link State Update
        packet.

Why is this an error ?  If the LSA is on the Link state request list for the neighbor, are we not expecting that
LSA from that neighbor ?

All responses appreciated.
Paresh Khatri.


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 11 19:29:51 2003
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 TAA09338
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Jun 2003 19:29:51 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00A0ECC0@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 19:29:51 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45346950 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 11 Jun 2003 19:29:49 -0400
Received: from 207.159.120.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Wed, 11 Jun 2003 19:29:42 -0400
Received: by xmxpita.excite.com (Postfix, from userid 110) id CAC2E3D25; Wed,
          11 Jun 2003 19:29:40 -0400 (EDT)
Received: from [64.47.48.10] by xprdmailfe10.nwk.excite.com via HTTP; Wed, 11
          Jun 2003 19:29:40 EST
X-AntiAbuse: This header was added to track abuse,
             please include it with any abuse report
X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4
MIME-Version: 1.0
X-Sender: dgoodspe@excite.com
X-Mailer: PHP
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <20030611232940.CAC2E3D25@xmxpita.excite.com>
Date:         Wed, 11 Jun 2003 19:29:40 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Don Goodspeed <dgoodspe@EXCITE.COM>
Subject: Re: I-D ACTION:draft-mirtorabi-ospf-tunnel-adjacency-00.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Sina, Peter,

Just got done reading the draft and had a few questions/comments.
On the whole, this looks like a solid proposal.

1. Encapsulation (section 4): Should section a) be a "should"?
Could it be acceptable to always encapsulate?

2. Section 4 clause b, last sentence.  "all implementation" should
be plural.

3. Areas: clarify what to call the area that is not the transit area.
In section 5, call out that the TA is announced as an unnum p2p link
in <insert term here>, as opposed to the TTA as it could be read.
Maybe "associated area" or "native area"?

4. Section 5, Link Data - is this the IP address used to transmit
the TA data over, or could it be a loopback interface?

5. Should we call out that the TTA and the "native area" cannot
be the same area?  I did not see this prohibition anywhere.

6. Cost of the TA - for using the TTA intra-area cost, do you propose
using a special metric setting (zero?) or a separate field/toggle for
allowing this (admin cost/oper cost?).

7. Consistency in sections 6 thru 9 in reference to [1].  Section 6
does not even contain a reference.  In all sections, should you call
out section numbers?  Do you intend the interface and adjacency FSMs
to adhere to the regular ones or the virtual ones?

Thanks,
Don

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 11 19:43:17 2003
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 TAA09639
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Jun 2003 19:43:17 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00A0EC55@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 19:43:18 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45347176 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 11 Jun 2003 19:43:17 -0400
Received: from 63.231.195.115 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Wed, 11 Jun 2003 19:33:15 -0400
Received: (qmail 19736 invoked by uid 0); 11 Jun 2003 23:33:14 -0000
Received: from mpls-pop-08.inet.qwest.net (63.231.195.8) by
          mpls-qmqp-04.inet.qwest.net with QMQP; 11 Jun 2003 23:33:14 -0000
Received: from 0-1pool174-4.nas18.minneapolis1.mn.us.da.qwest.net (HELO
          charita) (67.4.174.4) by mpls-pop-08.inet.qwest.net with SMTP; 11 Jun
          2003 23:33:14 -0000
References:  <see84015.009@aapt-gwia2.aapt.com.au>
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 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <052101c33071$e0a42f80$cbc8c8c8@sdksoft.com>
Date:         Wed, 11 Jun 2003 18:33:35 -0500
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Parag Deshpande <paragdeshpande@SDKSOFT.COM>
Subject: Re: Clarification on Flooding
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

From my understanding this is what it means -
A router requests an lsa when either the lsa is not present in its db or the
db copy is older.
When router receives a DD packet that contains a new/newer lsa it would
request that lsa from the nbr.

In this case the nbr sent an lsa which is either same or older which either
means that the request
created was incorrect or the nbr misbehaved, hence the Database exchange
must restart.

Parag


----- Original Message -----
From: Paresh Khatri <pkhatri@AAPT.COM.AU>
To: <OSPF@PEACH.EASE.LSOFT.COM>
Sent: Wednesday, June 11, 2003 5:55 PM
Subject: Clarification on Flooding


HI all,

Would someone be able to explain the following clause in RFC2328 to me ?

This is in Section 13. Flooding Procedure:

    Page 145
    (6) Else, if there is an instance of the LSA on the sending
        neighbor's Link state request list, an error has occurred in the
        Database Exchange process.  In this case, restart the Database
        Exchange process by generating the neighbor event BadLSReq for
        the sending neighbor and stop processing the Link State Update
        packet.

Why is this an error ?  If the LSA is on the Link state request list for the
neighbor, are we not expecting that
LSA from that neighbor ?

All responses appreciated.
Paresh Khatri.


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 11 23:58:45 2003
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 XAA13528
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Jun 2003 23:58:44 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A0F97A@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 23:58:44 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45369856 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 11 Jun 2003 23:58:42 -0400
Received: from 212.17.36.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Wed, 11 Jun 2003 23:48:42 -0400
Received: from fogarty.jakma.org
          (IDENT:tvLFaxw4kwSdw3NOrS3AP8MP7+vvXD/Z@fogarty.jakma.org
          [192.168.0.4]) by hibernia.jakma.org (8.11.6/8.11.6) with ESMTP id
          h5C3meA30713 for <OSPF@peach.ease.lsoft.com>; Thu, 12 Jun 2003
          04:48:40 +0100
X-X-Sender: paul@fogarty.jakma.org
X-NSA: iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt
       mustard gas
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.LNX.4.44.0306120431120.31577-100000@fogarty.jakma.org>
Date:         Thu, 12 Jun 2003 04:48:40 +0100
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Paul Jakma <paul@CLUBI.IE>
Subject: NSSA NP option bit clarification
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

hi,

I have a question regarding the use of the NP bit in the options
field, specifically with respect to its use in the Database
Description header.

From RFC3101, Appendix A, The NP bit is used in:

options field in Hello, DD and Type-7 LSAs. Its use is described as:

- Hello header, to indicate whether router is Type7 capable. (N bit
semantics)

- Type-7 LSA, to indicate whether the LSA should or should not be
translated to Type-5, default is clear. (P bit semantics)

The usage in the DD header options field is not specified. Hence one
presumes OSPFv2 semantics hold, DD options must match Hello options
(ie current neighbour state wrt to options, but change in options
usually results in neighour state going back to at least ExStart,
iirc).

However, we have noticed in testing that there is an OSPF
NSSA implementation from a major vendor which does /not/ set the P
bit in the DD header, even though N bit in Hello and in neighbour
state is set, and it is sending Type-7 LSAs.

Is there an explanation for this? Or is this implementation wrong?

(at the moment we have hacked the implementation we have tested,
zebra ospfd, against this vendor's implementation to simply set the
NP bit in the DD header if N bit is set in neighbour-state to allow
the DD to be processed, as zebra ospfd will otherwise drop DD packets
where DD options do not match current neighbour state.)

thanks in advance.

regards,
--
Paul Jakma      paul@clubi.ie   paul@jakma.org  Key ID: 64A2FF6A
        warning: do not ever send email to spam@dishone.st
Fortune:
/usr/news/gotcha


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 12 00:51:12 2003
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 AAA14620
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Jun 2003 00:51:12 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00A0FAB0@cherry.ease.lsoft.com>; Thu, 12 Jun 2003 0:51:14 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45384094 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 12 Jun 2003 00:51:11 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 12 Jun 2003 00:51:11 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id 64DA5870AEC for
          <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 11 Jun 2003 21:51:10 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <see84015.009@aapt-gwia2.aapt.com.au>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EE806B2.50101@redback.com>
Date:         Thu, 12 Jun 2003 00:50:58 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Clarification on Flooding
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Paresh Khatri wrote:
> HI all,

Hi Paresh,

>
> Would someone be able to explain the following clause in RFC2328 to me ?
>
> This is in Section 13. Flooding Procedure:
>
>     Page 145
>     (6) Else, if there is an instance of the LSA on the sending
>         neighbor's Link state request list, an error has occurred in the
>         Database Exchange process.  In this case, restart the Database
>         Exchange process by generating the neighbor event BadLSReq for
>         the sending neighbor and stop processing the Link State Update
>         packet.
>
> Why is this an error ?  If the LSA is on the Link state request list for the neighbor, are we not expecting that
> LSA from that neighbor ?

Yes - but in this case the instance is the same as the one that is
already in your database. Note that in step (5) (b) it says to
immediately flood a new LSA out some subset of the router's interface.

When this happens the corresponding LSA instance should be removed
from all neighbor's link state request lists (see step (1) (b) on
page 149).

Note that an implemenation may have to make accomodations if LSA
flooding is not immediate. In any case, the specification is correct.


> All responses appreciated.
> Paresh Khatri.
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 12 01:32:01 2003
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 BAA15366
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Jun 2003 01:32:01 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A0FD3F@cherry.ease.lsoft.com>; Thu, 12 Jun 2003 1:31:57 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45386293 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 12 Jun 2003 01:31:36 -0400
Received: from 203.14.180.204 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Thu, 12 Jun 2003 01:31:36 -0400
Received: (qmail 28810 invoked from network); 12 Jun 2003 05:51:06 -0000
Received: from mailmon2.aapt.com.au (172.19.200.193) by 0 with SMTP; 12 Jun
          2003 05:51:06 -0000
Received: from QMAIL-Message_Server by aapt-gwia2.aapt.com.au with
          Novell_GroupWise; Thu, 12 Jun 2003 15:31:34 +1000
X-Mailer: Novell GroupWise 5.5.4
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Message-ID:  <see89cd6.089@aapt-gwia2.aapt.com.au>
Date:         Thu, 12 Jun 2003 15:31:17 +1000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Paresh Khatri <pkhatri@AAPT.COM.AU>
Subject: Re: Clarification on Flooding
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA15366

Thanks Acee,

I had overlooked the fact that we would not get to this step if the previous step had been carried out.

Paresh.

>>> acee@REDBACK.COM 06/12/03 02:50PM >>>
Paresh Khatri wrote:
> HI all,

Hi Paresh,

>
> Would someone be able to explain the following clause in RFC2328 to me ?
>
> This is in Section 13. Flooding Procedure:
>
>     Page 145
>     (6) Else, if there is an instance of the LSA on the sending
>         neighbor's Link state request list, an error has occurred in the
>         Database Exchange process.  In this case, restart the Database
>         Exchange process by generating the neighbor event BadLSReq for
>         the sending neighbor and stop processing the Link State Update
>         packet.
>
> Why is this an error ?  If the LSA is on the Link state request list for the neighbor, are we not expecting that
> LSA from that neighbor ?

Yes - but in this case the instance is the same as the one that is
already in your database. Note that in step (5) (b) it says to
immediately flood a new LSA out some subset of the router's interface.

When this happens the corresponding LSA instance should be removed
from all neighbor's link state request lists (see step (1) (b) on
page 149).

Note that an implemenation may have to make accomodations if LSA
flooding is not immediate. In any case, the specification is correct.


> All responses appreciated.
> Paresh Khatri.
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 12 02:38:03 2003
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 CAA28263
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Jun 2003 02:38:03 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00A1004A@cherry.ease.lsoft.com>; Thu, 12 Jun 2003 2:38:02 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45390948 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 12 Jun 2003 02:38:01 -0400
Received: from 67.17.166.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 12 Jun 2003 02:38:01 -0400
Received: from CallSciences (unverified [172.21.6.74]) by ucmmail.com
          (Rockliffe SMTPRA 5.2.5) with SMTP id
          <B2005927282@vljcms02.ucmretail.internal.callsciences.com> for
          <OSPF@peach.ease.lsoft.com>; Thu, 12 Jun 2003 02:38:00 -0400
Content-Type: text/plain; charset=US-ASCII
Message-ID:  <B2005927282@vljcms02.ucmretail.internal.callsciences.com>
Date:         Thu, 12 Jun 2003 02:38:00 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: farshad@ONEBOX.COM
Subject: Re: NSSA NP option bit clarification
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Paul,

From what I understand, setting that bit in the DD after it is verified in the hello packets is optional. I remember a discussion about that a couple of years ago. I also remember a switching company that didnt carry that bit in their implementation and had incompatibility issues with another switching company (I dont want to name companies and make them look bad or good when they are all actually RFC complient)

Just remember, if the area changes from NSSA to say transit, the new hello packets will have different options carried in them, and therefore the router will not neighbor with the NSSA routers.

Personally, I think it makes more sense if the DD packets match the hello packets in the options field, but I also understand why that is not a requirement.

Hope that helps,

Farshad


-----Original Message-----
From:     Paul Jakma <paul@CLUBI.IE>
Sent:     Thu, 12 Jun 2003 04:48:40 +0100
To:       OSPF@PEACH.EASE.LSOFT.COM
Subject:  NSSA NP option bit clarification

hi,

I have a question regarding the use of the NP bit in the options
field, specifically with respect to its use in the Database
Description header.

From RFC3101, Appendix A, The NP bit is used in:

options field in Hello, DD and Type-7 LSAs. Its use is described as:

- Hello header, to indicate whether router is Type7 capable. (N bit
semantics)

- Type-7 LSA, to indicate whether the LSA should or should not be
translated to Type-5, default is clear. (P bit semantics)

The usage in the DD header options field is not specified. Hence one
presumes OSPFv2 semantics hold, DD options must match Hello options
(ie current neighbour state wrt to options, but change in options
usually results in neighour state going back to at least ExStart,
iirc).

However, we have noticed in testing that there is an OSPF
NSSA implementation from a major vendor which does /not/ set the P
bit in the DD header, even though N bit in Hello and in neighbour
state is set, and it is sending Type-7 LSAs.

Is there an explanation for this? Or is this implementation wrong?

(at the moment we have hacked the implementation we have tested,
zebra ospfd, against this vendor's implementation to simply set the
NP bit in the DD header if N bit is set in neighbour-state to allow
the DD to be processed, as zebra ospfd will otherwise drop DD packets
where DD options do not match current neighbour state.)

thanks in advance.

regards,
--
Paul Jakma      paul@clubi.ie   paul@jakma.org  Key ID: 64A2FF6A
        warning: do not ever send email to spam@dishone.st
Fortune:
/usr/news/gotcha


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 12 07:29:51 2003
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 HAA04043
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Jun 2003 07:29:50 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00A10512@cherry.ease.lsoft.com>; Thu, 12 Jun 2003 7:29:49 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45414550 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 12 Jun 2003 07:29:47 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 12 Jun 2003 07:19:47 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id HAA03688; Thu, 12 Jun 2003 07:19:45
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200306121119.HAA03688@ietf.org>
Date:         Thu, 12 Jun 2003 07:19:45 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-pillay-esnault-ospf-flooding-06.txt
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 Refresh and Flooding Reduction in Stable
                          Topologies
        Author(s)       : P. Pillay-Esnault
        Filename        : draft-pillay-esnault-ospf-flooding-06.txt
        Pages           : 5
        Date            : 2003-6-11

This document describes an extension to the OSPF protocol to
reduce periodic flooding of Link State Advertisements in
stable topologies.
The OSPF current behavior requires that all LSAs other than DoNotAge
LSAs to be refreshed every 30 minutes. This document proposes to
generalize the use of DoNotAge LSAs to reduce protocol traffic in
stable topologies

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pillay-esnault-ospf-flooding-06.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-pillay-esnault-ospf-flooding-06.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-pillay-esnault-ospf-flooding-06.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:     <2003-6-11134833.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-pillay-esnault-ospf-flooding-06.txt

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

Content-Type: text/plain
Content-ID:     <2003-6-11134833.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 12 10:33:38 2003
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 KAA13845
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Jun 2003 10:33:37 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00A1083D@cherry.ease.lsoft.com>; Thu, 12 Jun 2003 10:33:37 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45422130 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 12 Jun 2003 10:33:35 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 12 Jun 2003 10:33:35 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id 84B0A1F6C4E for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 12 Jun 2003 07:33:34 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <B2005927282@vljcms02.ucmretail.internal.callsciences.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EE88F2C.2070507@redback.com>
Date:         Thu, 12 Jun 2003 10:33:16 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: NSSA NP option bit clarification
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Paul,

farshad@ONEBOX.COM wrote:
> Paul,
>>From what I understand, setting that bit in the DD after it is verified in the hello
> packets is optional. I remember a discussion about that a couple of years ago.
> I also remember a switching company that didnt carry that bit in their implementation
 > and had incompatibility issues with another switching company (I dont want to name
 > companies and make them look bad or good when they are all actually RFC complient)

This is correct. I checked RFC 2328 and the only requirement is that the
options carried in DD packets do not change during the database exchange.
There no checking to assure the options match the area configuration or the
options in the hello packet.

> Just remember, if the area changes from NSSA to say transit, the new hello packets
 > will have different options carried in them, and therefore the router will
 > not neighbor with the NSSA routers. Personally, I think it makes more sense if
 > the DD packets match the hello packets in the options field,

I agree. I set the NSSA options in both the hello and DD packets.

> but I also understand why that is not a requirement.

I'm sure I do. They both describe the same set of options
as described in appendix A.2. I think this may have been an
oversight.

Thanks,
Acee

>
> Hope that helps,
>
> Farshad
>
>
> -----Original Message-----
> From:     Paul Jakma <paul@CLUBI.IE>
> Sent:     Thu, 12 Jun 2003 04:48:40 +0100
> To:       OSPF@PEACH.EASE.LSOFT.COM
> Subject:  NSSA NP option bit clarification
>
> hi,
>
> I have a question regarding the use of the NP bit in the options
> field, specifically with respect to its use in the Database
> Description header.
>
>>From RFC3101, Appendix A, The NP bit is used in:
>
> options field in Hello, DD and Type-7 LSAs. Its use is described as:
>
> - Hello header, to indicate whether router is Type7 capable. (N bit
> semantics)
>
> - Type-7 LSA, to indicate whether the LSA should or should not be
> translated to Type-5, default is clear. (P bit semantics)
>
> The usage in the DD header options field is not specified. Hence one
> presumes OSPFv2 semantics hold, DD options must match Hello options
> (ie current neighbour state wrt to options, but change in options
> usually results in neighour state going back to at least ExStart,
> iirc).
>
> However, we have noticed in testing that there is an OSPF
> NSSA implementation from a major vendor which does /not/ set the P
> bit in the DD header, even though N bit in Hello and in neighbour
> state is set, and it is sending Type-7 LSAs.
>
> Is there an explanation for this? Or is this implementation wrong?
>
> (at the moment we have hacked the implementation we have tested,
> zebra ospfd, against this vendor's implementation to simply set the
> NP bit in the DD header if N bit is set in neighbour-state to allow
> the DD to be processed, as zebra ospfd will otherwise drop DD packets
> where DD options do not match current neighbour state.)
>
> thanks in advance.
>
> regards,
> --
> Paul Jakma      paul@clubi.ie   paul@jakma.org  Key ID: 64A2FF6A
>         warning: do not ever send email to spam@dishone.st
> Fortune:
> /usr/news/gotcha
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 12 12:18:22 2003
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 MAA17287
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Jun 2003 12:18:21 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00A10A6E@cherry.ease.lsoft.com>; Thu, 12 Jun 2003 12:09:53 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45429791 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 12 Jun 2003 12:09:47 -0400
Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 12 Jun 2003 12:09:46 -0400
Received: from smirtoraw2k03 (sjc-vpn4-120.cisco.com [10.21.80.120]) by
          fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h5CG9f014319 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 12 Jun 2003 09:09:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
Message-ID:  <016a01c330fd$07d2a3d0$386545ab@amer.cisco.com>
Date:         Thu, 12 Jun 2003 09:09:40 -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: I-D ACTION:draft-mirtorabi-ospf-tunnel-adjacency-00.txt
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <20030611232940.CAC2E3D25@xmxpita.excite.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Don

Thanks for the comments, please see in line

->-----Original Message-----
->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On
->Behalf Of Don Goodspeed
->Sent: Wednesday, June 11, 2003 4:30 PM
->To: OSPF@PEACH.EASE.LSOFT.COM
->Subject: Re: I-D ACTION:draft-mirtorabi-ospf-tunnel-adjacency-00.txt
->
->
->Sina, Peter,
->
->Just got done reading the draft and had a few
->questions/comments. On the whole, this looks like a solid proposal.
->
->1. Encapsulation (section 4): Should section a) be a
->"should"? Could it be acceptable to always encapsulate?

It could be acceptable

->
->2. Section 4 clause b, last sentence.  "all implementation"
->should be plural.

yes

->
->3. Areas: clarify what to call the area that is not the
->transit area. In section 5, call out that the TA is announced
->as an unnum p2p link in <insert term here>, as opposed to the
->TTA as it could be read. Maybe "associated area" or "native area"?

Yes we can use "associated area", that is the area for which TA is
configured

->
->4. Section 5, Link Data - is this the IP address used to
->transmit the TA data over, or could it be a loopback interface?

As for VL, Link Data is set to the virtual interface's IP address, which
is the interface through which TA control packet are sent, however I
would imagine that if one set it to a loopback ( as long as it belongs
to transit area ) it should be fine

->
->5. Should we call out that the TTA and the "native area"
->cannot be the same area?  I did not see this prohibition anywhere.

Yes it need to be explicitly mentioned

->
->6. Cost of the TA - for using the TTA intra-area cost, do you
->propose using a special metric setting (zero?) or a separate
->field/toggle for allowing this (admin cost/oper cost?).

By default the advertised cost of the TA is the intra-area cost to TA
endpoint, if you manually set the cost you will overwrite this cost and
advertise this configured cost for your TA adjacency. As for any
interface the cost must be greater than zero.

->7. Consistency in sections 6 thru 9 in reference to [1].
->Section 6 does not even contain a reference.  In all
->sections, should you call out section numbers?

Yes, we can mention this in the next version

-> Do you intend
->the interface and adjacency FSMs to adhere to the regular
->ones or the virtual ones?

Virtual

Thanks
Sina
->
->Thanks,
->Don
->
->_______________________________________________
->Join Excite! - http://www.excite.com
->The most personalized portal on the Web!
->


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 12 12:25:40 2003
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 MAA17532
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Jun 2003 12:25:39 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00A10B54@cherry.ease.lsoft.com>; Thu, 12 Jun 2003 12:25:40 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45430788 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 12 Jun 2003 12:25:39 -0400
Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 12 Jun 2003 12:25:39 -0400
Received: from smirtoraw2k03 (sjc-vpn4-120.cisco.com [10.21.80.120]) by
          fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h5CGPa009469 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 12 Jun 2003 09:25:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
Message-ID:  <017401c330ff$42228c60$386545ab@amer.cisco.com>
Date:         Thu, 12 Jun 2003 09:25:36 -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: NSSA NP option bit clarification
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <Pine.LNX.4.44.0306120431120.31577-100000@fogarty.jakma.org>
Precedence: list
Content-Transfer-Encoding: 7bit

Paul,

->-----Original Message-----
->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On
->Behalf Of Paul Jakma
->Sent: Wednesday, June 11, 2003 8:49 PM
->To: OSPF@PEACH.EASE.LSOFT.COM
->Subject: NSSA NP option bit clarification
->
->
->hi,
->
->I have a question regarding the use of the NP bit in the
->options field, specifically with respect to its use in the
->Database Description header.
->
->>From RFC3101, Appendix A, The NP bit is used in:
->
->options field in Hello, DD and Type-7 LSAs. Its use is described as:

Could you indicate where it says so?
Actually it says that the "option fields" is present in Hello, DD and
LSA

->
->- Hello header, to indicate whether router is Type7 capable. (N bit
->semantics)
->
->- Type-7 LSA, to indicate whether the LSA should or should
->not be translated to Type-5, default is clear. (P bit semantics)
->
->The usage in the DD header options field is not specified.

Appendix A, RFC 3101
-----
N-bit:        The N-bit describes the router's NSSA capability.  The N-
              bit is ##used only in Hello packets## and ensures that all
              members of an NSSA agree on that area's configuration.
              When the N-bit is set in the Hello packet that is sent out
              a particular interface, it means that the router will send
              and receive Type-7 LSAs on that interface.  Two routers
              will not form an adjacency unless they agree on the state
              of the N-bit.  If the N-bit is set in the options field,
              the E-bit must be clear.

P-bit:        The P-bit is ##used only in the Type-7 LSA header##.  It
flags
              the NSSA border router to translate the Type-7 LSA into a
              Type-5 LSA.  The default setting for the P-bit is clear.
-----

Above implies that N/P bit is not used in DD packet

->Hence one presumes OSPFv2 semantics hold, DD options must
->match Hello options

The above presumption is not correct

->(ie current neighbour state wrt to
->options, but change in options usually results in neighour
->state going back to at least ExStart, iirc).

Change in the option _during_ DD exchange result to going back to
Exstart and not if there is a mismatch between Hello and DD Option

->
->However, we have noticed in testing that there is an OSPF
->NSSA implementation from a major vendor which does /not/ set
->the P bit in the DD header, even though N bit in Hello and in
->neighbour state is set, and it is sending Type-7 LSAs.

As mentioned before and according to RFC 3101, N/P bit is Not used for
DD packet so the presence / absence of this bit in DD option packet
should be ignored

Sina

->
->Is there an explanation for this? Or is this implementation wrong?
->
->(at the moment we have hacked the implementation we have
->tested, zebra ospfd, against this vendor's implementation to
->simply set the NP bit in the DD header if N bit is set in
->neighbour-state to allow the DD to be processed, as zebra
->ospfd will otherwise drop DD packets where DD options do not
->match current neighbour state.)
->
->thanks in advance.
->
->regards,
->--
->Paul Jakma      paul@clubi.ie   paul@jakma.org  Key ID: 64A2FF6A
->        warning: do not ever send email to spam@dishone.st
->Fortune:
->/usr/news/gotcha
->


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 12 17:10:54 2003
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 RAA27152
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Jun 2003 17:10:52 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00A11729@cherry.ease.lsoft.com>; Thu, 12 Jun 2003 17:10:49 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45453703 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 12 Jun 2003 17:10:47 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 12 Jun 2003 17:10:47 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id 8DA3E37C2A6 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 12 Jun 2003 14:09:34 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <017401c330ff$42228c60$386545ab@amer.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EE8EBF9.8010105@redback.com>
Date:         Thu, 12 Jun 2003 17:09:13 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: NSSA NP option bit clarification
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

I'm not sure why this N bit/Hello text was introduced for NSSA. It seems
rather odd since one would want a neighbor exchange to start over if
the area type changes to/from NSSA. RFC 2328 does say the analogous
E bit should be set in the DD description options (from section 10.8):

         The router's optional OSPF capabilities (see Section 4.5) are
         transmitted to the neighbor in the Options field of the Database
         Description packet.  The router should maintain the same set of
         optional capabilities throughout the Database Exchange and
         flooding procedures.  If for some reason the router's optional
         capabilities change, the Database Exchange procedure should be
         restarted by reverting to neighbor state ExStart.  One optional
         capability is defined in this specification (see Sections 4.5
         and A.2). The E-bit should be set if and only if the attached
         network belongs to a non-stub area. Unrecognized bits in the
         Options field should be set to zero.

 From a position of hindsight, there should be three separate options
definitions: one for LSA options, one for hello options, and one for
DD options. Or, better yet, the options should be stored in the neighbor
structure during hello processing and not even included in the DD packet.



Sina Mirtorabi wrote:
> Paul,
>
> ->-----Original Message-----
> ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On
> ->Behalf Of Paul Jakma
> ->Sent: Wednesday, June 11, 2003 8:49 PM
> ->To: OSPF@PEACH.EASE.LSOFT.COM
> ->Subject: NSSA NP option bit clarification
> ->
> ->
> ->hi,
> ->
> ->I have a question regarding the use of the NP bit in the
> ->options field, specifically with respect to its use in the
> ->Database Description header.
> ->
> ->>From RFC3101, Appendix A, The NP bit is used in:
> ->
> ->options field in Hello, DD and Type-7 LSAs. Its use is described as:
>
> Could you indicate where it says so?
> Actually it says that the "option fields" is present in Hello, DD and
> LSA
>
> ->
> ->- Hello header, to indicate whether router is Type7 capable. (N bit
> ->semantics)
> ->
> ->- Type-7 LSA, to indicate whether the LSA should or should
> ->not be translated to Type-5, default is clear. (P bit semantics)
> ->
> ->The usage in the DD header options field is not specified.
>
> Appendix A, RFC 3101
> -----
> N-bit:        The N-bit describes the router's NSSA capability.  The N-
>               bit is ##used only in Hello packets## and ensures that all
>               members of an NSSA agree on that area's configuration.
>               When the N-bit is set in the Hello packet that is sent out
>               a particular interface, it means that the router will send
>               and receive Type-7 LSAs on that interface.  Two routers
>               will not form an adjacency unless they agree on the state
>               of the N-bit.  If the N-bit is set in the options field,
>               the E-bit must be clear.
>
> P-bit:        The P-bit is ##used only in the Type-7 LSA header##.  It
> flags
>               the NSSA border router to translate the Type-7 LSA into a
>               Type-5 LSA.  The default setting for the P-bit is clear.
> -----
>
> Above implies that N/P bit is not used in DD packet
>
> ->Hence one presumes OSPFv2 semantics hold, DD options must
> ->match Hello options
>
> The above presumption is not correct
>
> ->(ie current neighbour state wrt to
> ->options, but change in options usually results in neighour
> ->state going back to at least ExStart, iirc).
>
> Change in the option _during_ DD exchange result to going back to
> Exstart and not if there is a mismatch between Hello and DD Option
>
> ->
> ->However, we have noticed in testing that there is an OSPF
> ->NSSA implementation from a major vendor which does /not/ set
> ->the P bit in the DD header, even though N bit in Hello and in
> ->neighbour state is set, and it is sending Type-7 LSAs.
>
> As mentioned before and according to RFC 3101, N/P bit is Not used for
> DD packet so the presence / absence of this bit in DD option packet
> should be ignored
>
> Sina
>
> ->
> ->Is there an explanation for this? Or is this implementation wrong?
> ->
> ->(at the moment we have hacked the implementation we have
> ->tested, zebra ospfd, against this vendor's implementation to
> ->simply set the NP bit in the DD header if N bit is set in
> ->neighbour-state to allow the DD to be processed, as zebra
> ->ospfd will otherwise drop DD packets where DD options do not
> ->match current neighbour state.)
> ->
> ->thanks in advance.
> ->
> ->regards,
> ->--
> ->Paul Jakma      paul@clubi.ie   paul@jakma.org  Key ID: 64A2FF6A
> ->        warning: do not ever send email to spam@dishone.st
> ->Fortune:
> ->/usr/news/gotcha
> ->
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 12 17:40:10 2003
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 RAA27875
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Jun 2003 17:40:09 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00A11548@cherry.ease.lsoft.com>; Thu, 12 Jun 2003 17:40:08 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45456295 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 12 Jun 2003 17:40:06 -0400
Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 12 Jun 2003 17:40:05 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392)
          id <01KX0E8NHR1O8WY6ZE@omega7.wr.usgs.gov> for
          OSPF@PEACH.EASE.LSOFT.COM; Thu, 12 Jun 2003 14:40:04 -0700 (PDT)
X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM
X-VMS-Cc: PMURPHY
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Message-ID:  <01KX0E8NHR1Q8WY6ZE@omega7.wr.usgs.gov>
Date:         Thu, 12 Jun 2003 14:40:04 -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: NSSA NP option bit clarification
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

I am inclined to agree with Acee, namely

>From a position of hindsight, there should be three separate options
>definitions: one for LSA options, one for hello options, and one for
>DD options. Or, better yet, the options should be stored in the neighbor
>structure during hello processing and not even included in the DD packet.

Early on I questioned this RFC 1587 text

      N-bit:  The N-bit describes the the router's NSSA
              capability.  The N-bit is used only in Hello
              packets and ensures that all members of an NSSA
              agree on that area's configuration.

Late in the game of getting RFC 3101 published it stopped being an issue
with me. I was not around when this text was written this way and can't
shed any light on the exact intentions of Rob and Vince. My guess is they
were simply trying to distinguish the use of this bit in the Hello Packet
versus its use in the Type-7 LSA option field, and that it had nothing at
all to do with how the bit was used in the DD packet.  I suppose its too
late now to make this text a little clearer. I do recommend that you don't
read too much into it.

Pat


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 13 06:24:10 2003
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 GAA27497
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Jun 2003 06:24:10 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00A1294C@cherry.ease.lsoft.com>; Fri, 13 Jun 2003 6:24:09 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45527480 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 13 Jun 2003 06:24:03 -0400
Received: from 203.199.83.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 13 Jun 2003 06:24:02 -0400
Received: (qmail 21480 invoked by uid 510); 13 Jun 2003 10:23:50 -0000
Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 13 jun
          2003 10:23:50 -0000
MIME-Version: 1.0
Content-type: multipart/mixed;
              boundary="Next_1055499830---0-203.199.83.26-21444"
Message-ID:  <20030613102350.21479.qmail@webmail16.rediffmail.com>
Date:         Fri, 13 Jun 2003 10:23:50 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Krishna Rao <ospf_query@REDIFFMAIL.COM>
Subject: Clarification in size of Rtr and network LSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

 This is a multipart mime message


--Next_1055499830---0-203.199.83.26-21444
Content-type: text/plain;
        charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,=0A      This is w.r.to the size of the Router LSA to be generated. We c=
an not predict the size of the router LSA initially in the process of formi=
ng the Router LSA. Usually we allocate  (Max MTU size - (OSPF header size  =
+ IP header size + MD5 authentication size) --> 1500 - (28 + 20 + 16)=3D 14=
36) and start filling the LSA. For Point to point interface we add two link=
s and need 24 bytes for each point to point interface. That results in supp=
orting only 59 interfaces in a single area. Is this an acceptable argument?=
 or Should we design such that OSPF sends a LSA more than MTU size and gets=
 fragmented in IP. =0AWhat is the scalabilty figure for Number of interface=
s in a area for popular routers?=0A=0AThanks in advance,=0ARegards,=0AKrish=
na
--Next_1055499830---0-203.199.83.26-21444
Content-type: text/html;
        charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<a href=3D"http://www.herohonda.com/karizma" target=3D"_blank">=0A<img src=
=3D"http://immail.rediff.com/icons/rediff_mail_gold/hhsignature_12062003.gi=
f" width=3D"496" height=3D"75" border=3D"0">=0A</a>=0A
--Next_1055499830---0-203.199.83.26-21444--


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 13 09:17:20 2003
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 JAA02517
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Jun 2003 09:17:19 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00A12D70@cherry.ease.lsoft.com>; Fri, 13 Jun 2003 9:17:17 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45535321 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 13 Jun 2003 09:17:15 -0400
Received: from 32.97.110.133 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 13 Jun 2003 09:17:15 -0400
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com
          [9.17.193.32]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id
          h5DDHC2R213748 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 13 Jun 2003
          09:17:13 -0400
Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82])
          by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id
          h5DDH90m152340 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 13 Jun 2003
          07:17:11 -0600
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|May
             21, 2003) at 06/13/2003 07:17:10
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Message-ID:  <OF98E391D3.19DFF603-ON85256D44.0047AE33-85256D44.00489EAA@us.ibm.com>
Date:         Fri, 13 Jun 2003 09:17:08 -0400
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: Re: Clarification in size of Rtr and network LSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Krishna Rao wrote:

Hi,
> Usually we allocate
> (Max MTU size - (OSPF header size  + IP header size +
> MD5 authentication size) --> 1500 - (28 + 20 + 16)= 1436
> and start filling the LSA. For Point to point interface we add two
> links and need 24 bytes for each point to point interface. That results
> in supporting only 59 interfaces in a single area. Is this an acceptable
argument?
> or Should we design such that OSPF sends a LSA more than MTU size and
gets fragmented in IP.
> What is the scalabilty figure for Number of interfaces in a area for
popular routers?

Krishna,

We have been facing this problem for years.  Our platform supports virtual
interfaces (VIPA) and they can run into the hundreds on one host.  We have
found ourselves having to build router LSAs that are much larger than the
largest MTU size.  While you like to avoid IP fragmentation when you can,
in this case you simply can't.  However, as RFC 2328 makes clear in
Appendix A.1, Encapsulation of OSPF Packets, you can build any OSPF packet
including the router LSA up to 65535 bytes (including all headers) in size.
In our experience not all the OSPF implementations support this properly,
but I think the word is getting out and more of them are as time goes by.

Also note that this problem is solved in OSPFv3, where router LSAs are not
required to flow as one packet.

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


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 13 11:04:01 2003
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 LAA09050
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Jun 2003 11:04:00 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00A12FF6@cherry.ease.lsoft.com>; Fri, 13 Jun 2003 11:04:00 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45540226 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 13 Jun 2003 11:03:59 -0400
Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Fri, 13 Jun 2003 11:03:59 -0400
Received: (qmail 23470 invoked from network); 13 Jun 2003 15:03:58 -0000
Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP;
          13 Jun 2003 15:03:58 -0000
Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by
          bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id LAA13624; Fri, 13 Jun
          2003 11:03:58 -0400
Message-ID:  <200306131503.LAA13624@bigbird.xebeo.com>
Date:         Fri, 13 Jun 2003 11:03:58 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Rohit Dube <rohit@XEBEO.COM>
Subject: Re: Working Group Last Call for draft-ietf-ospf-scalability-05.txt
Comments: cc: zinin@psg.com, fenner@research.att.com
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  Your message of "Fri, 30 May 2003 10:22:20 EDT." 
              <200305301422.KAA11165@bigbird.xebeo.com>
Precedence: list

This last call has ended and I am forwarding the draft to
the ADs for review.

--rohit.

On Fri, 30 May 2003 10:22:20 -0400 Rohit Dube writes:
=>This is the start of a Working Group last call for
=>Prioritized Treatment of Specific OSPF Packets and
=>Congestion Avoidance (draft-ietf-ospf-scalability-05.txt).
=>All comments be received by Friday, June 13, 2003.
=>
=>The draft can be found at
=>http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-05.txt
=>
=>--rohit.
___


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 13 11:13:22 2003
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 LAA09263
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Jun 2003 11:13:21 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00A13121@cherry.ease.lsoft.com>; Fri, 13 Jun 2003 11:13:20 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45540746 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 13 Jun 2003 11:13:17 -0400
Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 13 Jun 2003 11:13:17 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <6.00A130A9@cherry.ease.lsoft.com>;
          Fri, 13 Jun 2003 11:13:16 -0400
Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Fri, 13 Jun 2003 11:13:16 -0400
Received: (qmail 23861 invoked from network); 13 Jun 2003 15:13:16 -0000
Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP;
          13 Jun 2003 15:13:16 -0000
Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by
          bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id LAA13712 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 13 Jun 2003 11:13:16 -0400
Message-ID:  <200306131513.LAA13712@bigbird.xebeo.com>
Date:         Fri, 13 Jun 2003 11:13:16 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Rohit Dube <rohit@XEBEO.COM>
Subject: Re: 57th IETF OSPF WG Meeting
Comments: To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  Your message of "Tue, 20 May 2003 19:39:27 EDT." 
              <200305202339.TAA10433@bigbird.xebeo.com>
Precedence: list

The meeting is currently scheduled for Tuesday 1415-1515. Please email,
proposals for agenda items to me and Acee.

Thanks,
--rohit.


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 13 12:52:39 2003
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 MAA11776
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Jun 2003 12:52:39 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00A133E4@cherry.ease.lsoft.com>; Fri, 13 Jun 2003 12:52:39 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45546362 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 13 Jun 2003 12:52:38 -0400
Received: from 207.217.120.46 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Fri, 13 Jun 2003 12:52:38 -0400
Received: from user-2ivfj0k.dialup.mindspring.com ([165.247.204.20]
          helo=earthlink.net) by grebe.mail.pas.earthlink.net with esmtp (Exim
          3.33 #1) id 19Qrn2-0007jP-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13
          Jun 2003 09:52:37 -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: <20030613102350.21479.qmail@webmail16.rediffmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3EEA01C1.1DAE8F69@earthlink.net>
Date:         Fri, 13 Jun 2003 09:54: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: Clarification in size of Rtr and network LSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Krishna,

        I myself don't like fragmentation, if just due to the fact
        that any fragment gets dropped, then the whole packet/frame
        needs to be rexmit'ed.

        Additionally, I would expect at least consistency counts for
        each LSA type. This count should be retrieveable before
        you start filling the LSA. With this count you can allocate
        the proper memory size.

        Mitchell Erblich
        Sr Software Engineer
        -------------

Krishna Rao wrote:
>
> Hi,
>       This is w.r.to the size of the Router LSA to be generated. We can not predict the size of the router LSA initially in the process of forming the Router LSA. Usually we allocate  (Max MTU size - (OSPF header size  + IP header size + MD5 authentication size) --> 1500 - (28 + 20 + 16)= 1436) and start filling the LSA. For Point to point interface we add two links and need 24 bytes for each point to point interface. That results in supporting only 59 interfaces in a single area. Is this an acceptable argument? or Should we design such that OSPF sends a LSA more than MTU size and gets fragmented in IP.
> What is the scalabilty figure for Number of interfaces in a area for popular routers?
>
> Thanks in advance,
> Regards,
> Krishna
>
>   ------------------------------------------------------------------------
> [Image]


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 13 14:13:13 2003
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 OAA16496
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Jun 2003 14:13:12 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A13672@cherry.ease.lsoft.com>; Fri, 13 Jun 2003 14:13:10 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45555387 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 13 Jun 2003 14:13:07 -0400
Received: from 207.159.120.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Fri, 13 Jun 2003 14:13:06 -0400
Received: by xmxpita.excite.com (Postfix, from userid 110) id D8385299A8; Fri,
          13 Jun 2003 14:13:04 -0400 (EDT)
Received: from [64.47.48.10] by xprdmailfe22.nwk.excite.com via HTTP; Fri, 13
          Jun 2003 14:13:04 EST
X-AntiAbuse: This header was added to track abuse,
             please include it with any abuse report
X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4
MIME-Version: 1.0
X-Sender: dgoodspe@excite.com
X-Mailer: PHP
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <20030613181304.D8385299A8@xmxpita.excite.com>
Date:         Fri, 13 Jun 2003 14:13:04 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Don Goodspeed <dgoodspe@EXCITE.COM>
Subject: Re: Clarification in size of Rtr and network LSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hmmm.  Would a scheme like ISIS has for extended LSPs
work for the router LSA?  If we could use a range of
router IDs that are not assigned, then maybe.  Or we
could use a non-backward compatible method using opaque
LSAs.  Any ideas?  -don

================================
Krishna,

I myself don't like fragmentation, if just due to the fact
that any fragment gets dropped, then the whole packet/frame
needs to be rexmit'ed.

Additionally, I would expect at least consistency counts for
each LSA type. This count should be retrieveable before
you start filling the LSA. With this count you can allocate
the proper memory size.

Mitchell Erblich
Sr Software Engineer
-------------

Krishna Rao wrote:
>
> Hi,
> This is w.r.to the size of the Router LSA to be generated. We can not predict the size of the router LSA initially in the process of forming the Router LSA. Usually we allocate (Max MTU size - (OSPF header size + IP header size + MD5 authentication size) --> 1500 - (28 + 20 + 16)= 1436) and start filling the LSA. For Point to point interface we add two links and need 24 bytes for each point to point interface. That results in supporting only 59 interfaces in a single area. Is this an acceptable argument? or Should we design such that OSPF sends a LSA more than MTU size and gets fragmented in IP.
> What is the scalabilty figure for Number of interfaces in a area for popular routers?
>
> Thanks in advance,
> Regards,
> Krishna

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 13 14:24:45 2003
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 OAA16784
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Jun 2003 14:24:44 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A135AB@cherry.ease.lsoft.com>; Fri, 13 Jun 2003 14:24:44 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45555616 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 13 Jun 2003 14:24:42 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 13 Jun 2003 14:24:42 -0400
Received: from redback.com (login002.redback.com [155.53.12.54]) by
          prattle.redback.com (Postfix) with ESMTP id 2EC328EAE01 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 13 Jun 2003 11:24:41 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <20030613181304.D8385299A8@xmxpita.excite.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EEA16C8.1020306@redback.com>
Date:         Fri, 13 Jun 2003 14:24:08 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Clarification in size of Rtr and network LSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Don Goodspeed wrote:
> Hmmm.  Would a scheme like ISIS has for extended LSPs
> work for the router LSA?  If we could use a range of
> router IDs that are not assigned, then maybe.  Or we
> could use a non-backward compatible method using opaque
> LSAs.  Any ideas?  -don

Don,

Let's not go there ;^). Every implementation should
support IP fragmentation and reassembly up to a certain
limit (if not the full 64K). This should more than exceed
anybody's requirement for the number of interfaces in a
single area. For example, if one supports IP fragmentation
and reassembly up to 16K (not an unreasonable number since
there are some DLCs that support MTUs this big) one can
support around 1350 numbered P2P interfaces or around
2700 numbered or transit interfaces. Does anyone have
a requirement to support more interfaces
in a single area?

Thanks,
Acee

>
> ================================
> Krishna,
>
> I myself don't like fragmentation, if just due to the fact
> that any fragment gets dropped, then the whole packet/frame
> needs to be rexmit'ed.
>
> Additionally, I would expect at least consistency counts for
> each LSA type. This count should be retrieveable before
> you start filling the LSA. With this count you can allocate
> the proper memory size.
>
> Mitchell Erblich
> Sr Software Engineer
> -------------
>
> Krishna Rao wrote:
>
>>Hi,
>>This is w.r.to the size of the Router LSA to be generated. We can not predict the size of the router LSA initially in the process of forming the Router LSA. Usually we allocate (Max MTU size - (OSPF header size + IP header size + MD5 authentication size) --> 1500 - (28 + 20 + 16)= 1436) and start filling the LSA. For Point to point interface we add two links and need 24 bytes for each point to point interface. That results in supporting only 59 interfaces in a single area. Is this an acceptable argument? or Should we design such that OSPF sends a LSA more than MTU size and gets fragmented in IP.
>>What is the scalabilty figure for Number of interfaces in a area for popular routers?
>>
>>Thanks in advance,
>>Regards,
>>Krishna
>
>
> _______________________________________________
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 13 15:16:27 2003
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 PAA20268
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Jun 2003 15:16:25 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A13830@cherry.ease.lsoft.com>; Fri, 13 Jun 2003 15:16:23 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45560951 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 13 Jun 2003 15:16:20 -0400
Received: from 207.159.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Fri, 13 Jun 2003 15:16:20 -0400
Received: by xmxpita.excite.com (Postfix, from userid 110) id DC7E1F659; Fri,
          13 Jun 2003 15:16:17 -0400 (EDT)
Received: from [64.47.48.10] by xprdmailfe3.nwk.excite.com via HTTP; Fri, 13
          Jun 2003 15:16:17 EST
X-AntiAbuse: This header was added to track abuse,
             please include it with any abuse report
X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4
MIME-Version: 1.0
X-Sender: dgoodspe@excite.com
X-Mailer: PHP
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <20030613191617.DC7E1F659@xmxpita.excite.com>
Date:         Fri, 13 Jun 2003 15:16:17 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Don Goodspeed <dgoodspe@EXCITE.COM>
Subject: Re: Clarification in size of Rtr and network LSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Ok, ok.  I admit I was just stirring the pot a little.

I just wanted people to see that, like it or not,
fragmentation is a way of life in OSPF if you have
more than a 100+ links on a router.

Cheers,
Don

Don Goodspeed wrote:
> Hmmm. Would a scheme like ISIS has for extended LSPs
> work for the router LSA? If we could use a range of
> router IDs that are not assigned, then maybe. Or we
> could use a non-backward compatible method using opaque
> LSAs. Any ideas? -don

Don,

Let's not go there ;^). Every implementation should
support IP fragmentation and reassembly up to a certain
limit (if not the full 64K). This should more than exceed
anybody's requirement for the number of interfaces in a
single area. For example, if one supports IP fragmentation
and reassembly up to 16K (not an unreasonable number since
there are some DLCs that support MTUs this big) one can
support around 1350 numbered P2P interfaces or around
2700 numbered or transit interfaces. Does anyone have
a requirement to support more interfaces
in a single area?

Thanks,
Acee

>
> ================================
> Krishna,
>
> I myself don't like fragmentation, if just due to the fact
> that any fragment gets dropped, then the whole packet/frame
> needs to be rexmit'ed.
>
> Additionally, I would expect at least consistency counts for
> each LSA type. This count should be retrieveable before
> you start filling the LSA. With this count you can allocate
> the proper memory size.
>
> Mitchell Erblich
> Sr Software Engineer
> -------------
>
> Krishna Rao wrote:
>
>>Hi,
>>This is w.r.to the size of the Router LSA to be generated. We can not predict the size of the router LSA initially in the process of forming the Router LSA. Usually we allocate (Max MTU size - (OSPF header size + IP header size + MD5 authentication size) --> 1500 - (28 + 20 + 16)= 1436) and start filling the LSA. For Point to point interface we add two links and need 24 bytes for each point to point interface. That results in supporting only 59 interfaces in a single area. Is this an acceptable argument? or Should we design such that OSPF sends a LSA more than MTU size and gets fragmented in IP.
>>What is the scalabilty figure for Number of interfaces in a area for popular routers?
>>
>>Thanks in advance,
>>Regards,
>>Krishna
>
>
> _______________________________________________
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
>


--
Acee

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 13 16:21:19 2003
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 QAA21964
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Jun 2003 16:21:19 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A139C4@cherry.ease.lsoft.com>; Fri, 13 Jun 2003 16:21:17 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45564560 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 13 Jun 2003 16:21:15 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 13 Jun 2003 16:21:14 -0400
Received: from redback.com (login002.redback.com [155.53.12.54]) by
          prattle.redback.com (Postfix) with ESMTP id C53413FBB22 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 13 Jun 2003 13:21:13 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EEA3217.6090607@redback.com>
Date:         Fri, 13 Jun 2003 16:20:39 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: OSPF Graceful Restart Implementation Report
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

I'm pulling together an implementation report for
draft-ietf-ospf-hitless-restart-07.txt. If you have implemented the
subject draft, please answer the questionaire below. Note that I
do NOT intend to make vendor names public and will not use the
information for any purposes other than the report.

     Vendor:     ________________________

     Product(s): ________________________________________

     Shipped (yes/no): __________________________________

     Largest Deployment _________________________________

     This may be very hard to gauge since it is hard to say whether
     or not a particular customer is using it.

     Planned Restart (yes/no): ____

     Unplanned Restart (yes/no): ____

     Interoperability Tested with: ______________________

     Strict LSA Checking (yes/no/configurable): _________

     By this I mean do you terminate helper mode when there is
     a change to any router that will be flooded to the restarting
     router.

     Additional Extensions: _____________________________

     This would include additional delays for route redistribution,
     BGP convergence, etc.

Thanks,
---
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Sat Jun 14 04:52:18 2003
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 EAA21872
	for <ospf-archive@LISTS.IETF.ORG>; Sat, 14 Jun 2003 04:52:18 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00A15FAA@cherry.ease.lsoft.com>; Sat, 14 Jun 2003 4:52:17 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45616519 for OSPF@PEACH.EASE.LSOFT.COM;
          Sat, 14 Jun 2003 04:52:16 -0400
Received: from 203.199.83.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Sat, 14 Jun 2003 04:52:15 -0400
Received: (qmail 9291 invoked by uid 510); 14 Jun 2003 08:51:56 -0000
Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 14 jun
          2003 08:51:56 -0000
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="Next_1055580716---0-203.199.83.26-9284"
Message-ID:  <20030614085156.9290.qmail@webmail16.rediffmail.com>
Date:         Sat, 14 Jun 2003 08:51:56 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vivek Dubey <vivek_ospf@REDIFFMAIL.COM>
Subject: Re: Address Family Support in OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

 This is a multipart mime message


--Next_1055580716---0-203.199.83.26-9284
Content-type: text/plain;
        charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Sounds interesting, as IGP would then not depend=0Aon "address family combi=
nations" supported at IP=0Alevel.=0AHow will multiple OSPFv3 instance will =
provide that=0Asupport?=0A=0A=0A=0AOn Wed, 11 Jun 2003 Acee Lindem wrote :=
=0A>At the last IETF, the draft draft-mirtorabi-ospfv3-AF-00.txt was=0A>pre=
sented. It proposes to make some protocol changes to OSPFv3 now=0A>in case =
we ever want to support multiple address families (e.g.,=0A>permutations of=
 IPv4, IPv6, unicast, and multicast).=0A>=0A>The draft raised a moderate le=
vel of technical discussion (mainly=0A>centered on the proposal's backward =
compatibility mechanism). The=0A>big question is whether or not there is a =
real requirement for this?=0A>We all know this is done in ISIS but that doe=
sn't necessarily mean=0A>there is a requirement. And if there is, could the=
 requirement better=0A>be satisfied with multiple OSPFv3 instances. On the =
other hand, we=0A>really want to get the protocol changes in as early as po=
ssible if=0A>we ever want to support multiple address families.=0A>=0A>Comm=
ents? I have some additional considerations that I will put=0A>in a separat=
e E-mail.=0A>=0A>--=0A>Acee=0A
--Next_1055580716---0-203.199.83.26-9284
Content-type: text/html;
        charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<a href=3D"http://www.herohonda.com/karizma" target=3D"_blank">=0A<img src=
=3D"http://immail.rediff.com/icons/rediff_mail_gold/hhsignature_12062003.gi=
f" width=3D"496" height=3D"75" border=3D"0">=0A</a>=0A
--Next_1055580716---0-203.199.83.26-9284--


From owner-ospf@PEACH.EASE.LSOFT.COM  Sat Jun 14 06:33:31 2003
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 GAA22948
	for <ospf-archive@LISTS.IETF.ORG>; Sat, 14 Jun 2003 06:33:30 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00A16181@cherry.ease.lsoft.com>; Sat, 14 Jun 2003 6:33:28 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45636745 for OSPF@PEACH.EASE.LSOFT.COM;
          Sat, 14 Jun 2003 06:33:24 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Sat, 14 Jun 2003 06:33:24 -0400
Received: from redback.com (login001.redback.com [155.53.12.18]) by
          prattle.redback.com (Postfix) with ESMTP id 5426B63228D for
          <OSPF@PEACH.EASE.LSOFT.COM>; Sat, 14 Jun 2003 03:33:23 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <20030614085156.9290.qmail@webmail16.rediffmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EEAF9C9.8090601@redback.com>
Date:         Sat, 14 Jun 2003 06:32:41 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Address Family Support in OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Vivek Dubey wrote:
> Sounds interesting, as IGP would then not depend
> on "address family combinations" supported at IP
> level.
> How will multiple OSPFv3 instance will provide that
> support?

Alternately, you could also use separate OSPFv3 instances
for each address family. OSPFv3 natively supports multiple
instances of OSPFv3 on a link without using secondary
addresses or multiplexing via a layer 2 encapsulation (e.g.,
802.1q).

For incongruent IPv6 topologies, you'd simply configure
additional OSPFv3 instances using the interfaces you wish
to use for that topology. The OSPFv3 instance would populate
the RIB corresponding to the respective topology. As example
application would be carrying multicast traffic on a separate
topology from unicast traffic.

For other address families (most notably IPv4), we'd still
need new LSAs to carry the non-IPv6 prefixes (independent of
whether you use multiple instances or support multiple address
families in a single instance).

The advantage of supporting multiple address families in
single instance is that you only have a single set of OSPFv3
adjacencies. The disadvantage is complexity we're exerting
on the base protocol. To it right, you really need separate
interface costs, prefix ranges, redistribution policy,
default origination, etc, for each address family. You
already have all this with separate instances.

At the last IETF, there was discussion as to whether or
not there is a strong enough requirement for this to warrent
consideration by the OSPF WG. Much of this discussion focused
on whether or not a provider would ever phase out OSPFv2 in
favor of using OSPFv3 to advertise IPv4 prefixes.

My feeling is that perhaps we should consider the modest
changes to the OSPFv3 protocol now in case we ever want
to support multiple address families.

This E-mail contains the additional considerations I eluded
to in my previous post.

Thanks,
Acee

>
>
>
> On Wed, 11 Jun 2003 Acee Lindem wrote :
>
>>At the last IETF, the draft draft-mirtorabi-ospfv3-AF-00.txt was
>>presented. It proposes to make some protocol changes to OSPFv3 now
>>in case we ever want to support multiple address families (e.g.,
>>permutations of IPv4, IPv6, unicast, and multicast).
>>
>>The draft raised a moderate level of technical discussion (mainly
>>centered on the proposal's backward compatibility mechanism). The
>>big question is whether or not there is a real requirement for this?
>>We all know this is done in ISIS but that doesn't necessarily mean
>>there is a requirement. And if there is, could the requirement better
>>be satisfied with multiple OSPFv3 instances. On the other hand, we
>>really want to get the protocol changes in as early as possible if
>>we ever want to support multiple address families.
>>
>>Comments? I have some additional considerations that I will put
>>in a separate E-mail.
>>
>>--
>>Acee
>>
>>
>> ------------------------------------------------------------------------
>>
>> <http://www.herohonda.com/karizma>
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 16 09:13:08 2003
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 JAA12830
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 Jun 2003 09:13:08 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00A19243@cherry.ease.lsoft.com>; Mon, 16 Jun 2003 9:13:05 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45767187 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 16 Jun 2003 09:13:02 -0400
Received: from 64.4.11.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Mon, 16 Jun 2003 09:03:02 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon,
          16 Jun 2003 06:03:02 -0700
Received: from 203.197.24.195 by by7fd.bay7.hotmail.msn.com with HTTP; Mon, 16
          Jun 2003 13:03:01 GMT
X-Originating-IP: [203.197.24.195]
X-Originating-Email: [ameya_nms@hotmail.com]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 16 Jun 2003 13:03:02.0078 (UTC)
                       FILETIME=[9E3DEDE0:01C33407]
Message-ID:  <BAY7-F53kBbKP7Ie8tl00045857@hotmail.com>
Date:         Mon, 16 Jun 2003 13:03:01 +0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Ameya Pandit <ameya_nms@HOTMAIL.COM>
Subject: OSPF Link State Advertisement
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hello,

I have a query on link State Acknowledgements (LSAck). We know that when a
router receives a link state advertisement (LSA) it sends a LSAck for the
received LSA. I understand that it is possible to couple different
acknowledgements together. However, my question is: how do we determine the
'ifIndex' of the interface on which the router sends the LSAck for the
currently received LSA.
Is there any way we can find out the interface on which the LSAck was sent
knowing the details in the
received LSA (viz. Seq, Checksum et. al.). ?? .  In other words, i need to
know the
interface on which the LSA was received.

More specifically, I have a requirement where in my Network Management
Software needs to know the ifIndex (and eventually the neighbor that sent
(forwarded) the LSA) of the interface on which the LSAck was generated for
the LSA. I have the details of the LSA. I checked the OSPF MIB however there
was no way to get the ifIndex on which the LSA was received.

Any guidance would be helpful.

Regards
-Ameya

_________________________________________________________________
Feeling lost and loneyl? Need a little astro guidance?
http://www.msn.co.in/Astrology/


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 16 13:59:24 2003
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 NAA22921
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 Jun 2003 13:59:23 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00A1996E@cherry.ease.lsoft.com>; Mon, 16 Jun 2003 13:59:22 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45787645 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 16 Jun 2003 13:59:20 -0400
Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Mon, 16 Jun 2003 13:59:20 -0400
Received: from smirtoraw2k03 (dhcp-171-69-101-56.cisco.com [171.69.101.56]) by
          fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h5GHxK023121 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 16 Jun 2003 10:59:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Message-ID:  <001001c33431$02ac8b50$386545ab@amer.cisco.com>
Date:         Mon, 16 Jun 2003 10:59:19 -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: Address Family Support in OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <3EEAF9C9.8090601@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Acee, all


Let me summarize what are the disadvantages of using Instance-ID to run
multiple AF


running multiple instance will

a) require to maintain more adjacencies, in fact to add N AF you may
have to add N adjacencies. This will increase sending and processing of
Hello packet by N for each node

b) require to maintain more LSDB, in fact type 1 & 2 LSA ( which are Not
AF specific) are used again in each instance for each overlapping AF
topology

c) increase the flooding and processing of OSPF packets, this result
from an increase in adjacency and regeneration of type 1&2 LSA within
each instance

D) need a mapping of instance-ID to AF which is user dependent and can
be prone to misconfiguration and increase troubleshooting.

Further other routing protocols ( ISIS, BGP, EIGRP) have adopted AF,
although OSPFv2 -> OSPFv3 transition went with SIN ( ship in the night)
because of inability of v2 to add AF, OSPFv3 separated topology
information and AF specific information and move toward AF integration.
I am not sure we want to fall back to SIN by using instance_ID

Thanks
Sina


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 16 14:07:05 2003
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 OAA23335
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 Jun 2003 14:07:04 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00A19AC3@cherry.ease.lsoft.com>; Mon, 16 Jun 2003 14:07:02 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45789438 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 16 Jun 2003 14:07:00 -0400
Received: from 207.159.120.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Mon, 16 Jun 2003 14:07:00 -0400
Received: by xmxpita.excite.com (Postfix, from userid 110) id 4DEAA299B2; Mon,
          16 Jun 2003 14:06:57 -0400 (EDT)
Received: from [64.47.48.10] by xprdmailfe21.nwk.excite.com via HTTP; Mon, 16
          Jun 2003 14:06:57 EST
X-AntiAbuse: This header was added to track abuse,
             please include it with any abuse report
X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4
MIME-Version: 1.0
X-Sender: dgoodspe@excite.com
X-Mailer: PHP
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <20030616180657.4DEAA299B2@xmxpita.excite.com>
Date:         Mon, 16 Jun 2003 14:06:57 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Don Goodspeed <dgoodspe@EXCITE.COM>
Subject: Re: OSPF Link State Advertisement
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Ameya,

Remember that LSA are global, but a LS-Ack is acknowledging receipt
from a specific neighbor (or a specific DR on a LAN segment), not
for the LSA in general.  Therefore, the interface associated with
that neighbor and/or DR should always be known.

-don

==========================================
Hello,

I have a query on link State Acknowledgements (LSAck). We know that when a
router receives a link state advertisement (LSA) it sends a LSAck for the
received LSA. I understand that it is possible to couple different
acknowledgements together. However, my question is: how do we determine the
'ifIndex' of the interface on which the router sends the LSAck for the
currently received LSA.
Is there any way we can find out the interface on which the LSAck was sent
knowing the details in the
received LSA (viz. Seq, Checksum et. al.). ?? . In other words, i need to
know the
interface on which the LSA was received.

More specifically, I have a requirement where in my Network Management
Software needs to know the ifIndex (and eventually the neighbor that sent
(forwarded) the LSA) of the interface on which the LSAck was generated for
the LSA. I have the details of the LSA. I checked the OSPF MIB however there
was no way to get the ifIndex on which the LSA was received.

Any guidance would be helpful.

Regards
-Ameya

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 17 09:43:18 2003
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 JAA15522
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 Jun 2003 09:43:16 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00A1B7E7@cherry.ease.lsoft.com>; Tue, 17 Jun 2003 9:43:13 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45882999 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 17 Jun 2003 09:43:11 -0400
Received: from 203.199.83.28 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 17 Jun 2003 09:43:10 -0400
Received: (qmail 14932 invoked by uid 510); 17 Jun 2003 13:42:20 -0000
Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 17 jun
          2003 13:42:20 -0000
MIME-Version: 1.0
Content-type: multipart/mixed;
              boundary="Next_1055857340---0-203.199.83.28-14926"
Message-ID:  <20030617134220.14931.qmail@webmail18.rediffmail.com>
Date:         Tue, 17 Jun 2003 13:42:20 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Krishna Rao <ospf_query@REDIFFMAIL.COM>
Subject: Re: Clarification in size of Rtr and network LSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

 This is a multipart mime message


--Next_1055857340---0-203.199.83.28-14926
Content-type: text/plain;
        charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,=0A      If Fragmentation is the way for this, why should we negotiate M=
TU in DDP=0ARegards,=0AKrishna.=0A=0AOn Sat, 14 Jun 2003 Don Goodspeed wrot=
e :=0A>Ok, ok.  I admit I was just stirring the pot a little.=0A>=0A>I just=
 wanted people to see that, like it or not,=0A>fragmentation is a way of li=
fe in OSPF if you have=0A>more than a 100+ links on a router.=0A>=0A>Cheers=
,=0A>Don=0A>=0A>Don Goodspeed wrote:=0A> > Hmmm. Would a scheme like ISIS h=
as for extended LSPs=0A> > work for the router LSA? If we could use a range=
 of=0A> > router IDs that are not assigned, then maybe. Or we=0A> > could u=
se a non-backward compatible method using opaque=0A> > LSAs. Any ideas? -do=
n=0A>=0A>Don,=0A>=0A>Let's not go there ;^). Every implementation should=0A=
>support IP fragmentation and reassembly up to a certain=0A>limit (if not t=
he full 64K). This should more than exceed=0A>anybody's requirement for the=
 number of interfaces in a=0A>single area. For example, if one supports IP =
fragmentation=0A>and reassembly up to 16K (not an unreasonable number since=
=0A>there are some DLCs that support MTUs this big) one can=0A>support arou=
nd 1350 numbered P2P interfaces or around=0A>2700 numbered or transit inter=
faces. Does anyone have=0A>a requirement to support more interfaces=0A>in a=
 single area?=0A>=0A>Thanks,=0A>Acee=0A>=0A> >=0A> > =3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=0A> > Krishna,=0A> >=0A> > I myself don't like fragmentation, if just due =
to the fact=0A> > that any fragment gets dropped, then the whole packet/fra=
me=0A> > needs to be rexmit'ed.=0A> >=0A> > Additionally, I would expect at=
 least consistency counts for=0A> > each LSA type. This count should be ret=
rieveable before=0A> > you start filling the LSA. With this count you can a=
llocate=0A> > the proper memory size.=0A> >=0A> > Mitchell Erblich=0A> > Sr=
 Software Engineer=0A> > -------------=0A> >=0A> > Krishna Rao wrote:=0A> >=
=0A> >>Hi,=0A> >>This is w.r.to the size of the Router LSA to be generated.=
 We can not predict the size of the router LSA initially in the process of =
forming the Router LSA. Usually we allocate (Max MTU size - (OSPF header si=
ze + IP header size + MD5 authentication size) --> 1500 - (28 + 20 + 16)=3D=
 1436) and start filling the LSA. For Point to point interface we add two l=
inks and need 24 bytes for each point to point interface. That results in s=
upporting only 59 interfaces in a single area. Is this an acceptable argume=
nt? or Should we design such that OSPF sends a LSA more than MTU size and g=
ets fragmented in IP.=0A> >>What is the scalabilty figure for Number of int=
erfaces in a area for popular routers?=0A> >>=0A> >>Thanks in advance,=0A> =
>>Regards,=0A> >>Krishna=0A> >=0A> >=0A> > ________________________________=
_______________=0A> > Join Excite! - http://www.excite.com=0A> > The most p=
ersonalized portal on the Web!=0A> >=0A>=0A>=0A>--=0A>Acee=0A>=0A>_________=
______________________________________=0A>Join Excite! - http://www.excite.=
com=0A>The most personalized portal on the Web!=0A
--Next_1055857340---0-203.199.83.28-14926
Content-type: text/html;
        charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<a href=3D"http://www.herohonda.com/karizma" target=3D"_blank">=0A<img src=
=3D"http://immail.rediff.com/icons/rediff_mail_gold/hhsignature_12062003.gi=
f" width=3D"496" height=3D"75" border=3D"0">=0A</a>=0A
--Next_1055857340---0-203.199.83.28-14926--


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 17 09:57:13 2003
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 JAA16113
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 Jun 2003 09:57:12 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00A1B9BA@cherry.ease.lsoft.com>; Tue, 17 Jun 2003 9:57:11 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45883451 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 17 Jun 2003 09:57:08 -0400
Received: from 64.4.11.77 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 17 Jun 2003 09:57:08 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue,
          17 Jun 2003 06:57:07 -0700
Received: from 203.197.24.195 by by7fd.bay7.hotmail.msn.com with HTTP; Tue, 17
          Jun 2003 13:57:06 GMT
X-Originating-IP: [203.197.24.195]
X-Originating-Email: [ameya_nms@hotmail.com]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 17 Jun 2003 13:57:07.0419 (UTC)
                       FILETIME=[57076AB0:01C334D8]
Message-ID:  <BAY7-F77u2lKP12qEKA0000baf3@hotmail.com>
Date:         Tue, 17 Jun 2003 13:57:06 +0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Ameya Pandit <ameya_nms@HOTMAIL.COM>
Subject: Re: OSPF Link State Advertisement
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Thanks for the clarification. I am trying to find out what you ended up
saying. :-). Assume that the network is not Ethernet LAN, but a more general
case (point to point as an example where in we do not have a DR and a BDR).

Is there any user specific table (or any command i can issue) that gives me
the the interface number on which LS-Ack was sent for a particular LSA?. LSA
details are available. I need to know the interface on which LS-Ack was
sent. I searched through OSPF-MIBs for the same. However I could not find
any. Hence my query?

Any ideas are really welcome.

Rgds
Ameya


>From: Don Goodspeed <dgoodspe@EXCITE.COM>
>Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: Re: OSPF Link State Advertisement
>Date: Mon, 16 Jun 2003 14:06:57 -0400
>
>Ameya,
>
>Remember that LSA are global, but a LS-Ack is acknowledging receipt
>from a specific neighbor (or a specific DR on a LAN segment), not
>for the LSA in general.  Therefore, the interface associated with
>that neighbor and/or DR should always be known.
>
>-don
>
>==========================================
>Hello,
>
>I have a query on link State Acknowledgements (LSAck). We know that when a
>router receives a link state advertisement (LSA) it sends a LSAck for the
>received LSA. I understand that it is possible to couple different
>acknowledgements together. However, my question is: how do we determine the
>'ifIndex' of the interface on which the router sends the LSAck for the
>currently received LSA.
>Is there any way we can find out the interface on which the LSAck was sent
>knowing the details in the
>received LSA (viz. Seq, Checksum et. al.). ?? . In other words, i need to
>know the
>interface on which the LSA was received.
>
>More specifically, I have a requirement where in my Network Management
>Software needs to know the ifIndex (and eventually the neighbor that sent
>(forwarded) the LSA) of the interface on which the LSAck was generated for
>the LSA. I have the details of the LSA. I checked the OSPF MIB however
>there
>was no way to get the ifIndex on which the LSA was received.
>
>Any guidance would be helpful.
>
>Regards
>-Ameya
>
>_______________________________________________
>Join Excite! - http://www.excite.com
>The most personalized portal on the Web!

_________________________________________________________________
Wedding blues? Need help? http://www.msn.co.in/Matrimony/


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 17 11:04:12 2003
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 LAA21185
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 Jun 2003 11:04:11 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00A1B96A@cherry.ease.lsoft.com>; Tue, 17 Jun 2003 11:03:54 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45887991 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 17 Jun 2003 11:03:04 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 17 Jun 2003 11:02:59 -0400
Received: from redback.com (login004.redback.com [155.53.12.57]) by
          prattle.redback.com (Postfix) with ESMTP id C469568D9C3 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 17 Jun 2003 08:02:57 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <20030617134220.14931.qmail@webmail18.rediffmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EEF2D4D.3070804@redback.com>
Date:         Tue, 17 Jun 2003 11:01:33 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Clarification in size of Rtr and network LSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Krishna Rao wrote:
> Hi,
>       If Fragmentation is the way for this, why should we negotiate MTU in DDP

Krishna,

I'm assuming you mean database exchange by DDP. If two boxes on the same
network do not agree on the MTU, fragmentation will not be done correctly
and the box with the smaller MTU may not be able to receive a maximum
size packet from the box with larger MTU.

Acee

> Regards,
> Krishna.
>
> On Sat, 14 Jun 2003 Don Goodspeed wrote :
>
>>Ok, ok.  I admit I was just stirring the pot a little.
>>
>>I just wanted people to see that, like it or not,
>>fragmentation is a way of life in OSPF if you have
>>more than a 100+ links on a router.
>>
>>Cheers,
>>Don
>>
>>Don Goodspeed wrote:
>>
>>>Hmmm. Would a scheme like ISIS has for extended LSPs
>>>work for the router LSA? If we could use a range of
>>>router IDs that are not assigned, then maybe. Or we
>>>could use a non-backward compatible method using opaque
>>>LSAs. Any ideas? -don
>>
>>Don,
>>
>>Let's not go there ;^). Every implementation should
>>support IP fragmentation and reassembly up to a certain
>>limit (if not the full 64K). This should more than exceed
>>anybody's requirement for the number of interfaces in a
>>single area. For example, if one supports IP fragmentation
>>and reassembly up to 16K (not an unreasonable number since
>>there are some DLCs that support MTUs this big) one can
>>support around 1350 numbered P2P interfaces or around
>>2700 numbered or transit interfaces. Does anyone have
>>a requirement to support more interfaces
>>in a single area?
>>
>>Thanks,
>>Acee
>>
>>
>>>================================
>>>Krishna,
>>>
>>>I myself don't like fragmentation, if just due to the fact
>>>that any fragment gets dropped, then the whole packet/frame
>>>needs to be rexmit'ed.
>>>
>>>Additionally, I would expect at least consistency counts for
>>>each LSA type. This count should be retrieveable before
>>>you start filling the LSA. With this count you can allocate
>>>the proper memory size.
>>>
>>>Mitchell Erblich
>>>Sr Software Engineer
>>>-------------
>>>
>>>Krishna Rao wrote:
>>>
>>>
>>>>Hi,
>>>>This is w.r.to the size of the Router LSA to be generated. We can not predict the size of the router LSA initially in the process of forming the Router LSA. Usually we allocate (Max MTU size - (OSPF header size + IP header size + MD5 authentication size) --> 1500 - (28 + 20 + 16)= 1436) and start filling the LSA. For Point to point interface we add two links and need 24 bytes for each point to point interface. That results in supporting only 59 interfaces in a single area. Is this an acceptable argument? or Should we design such that OSPF sends a LSA more than MTU size and gets fragmented in IP.
>>>>What is the scalabilty figure for Number of interfaces in a area for popular routers?
>>>>
>>>>Thanks in advance,
>>>>Regards,
>>>>Krishna
>>>
>>>
>>>_______________________________________________
>>>Join Excite! - http://www.excite.com
>>>The most personalized portal on the Web!
>>>
>>
>>
>>--
>>Acee
>>
>>_______________________________________________
>>Join Excite! - http://www.excite.com
>>The most personalized portal on the Web!
>>
>>
>> ------------------------------------------------------------------------
>>
>> <http://www.herohonda.com/karizma>
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 17 11:10:51 2003
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 LAA21614
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 Jun 2003 11:10:50 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A1BC5C@cherry.ease.lsoft.com>; Tue, 17 Jun 2003 11:10:50 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45890688 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 17 Jun 2003 11:10:49 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 17 Jun 2003 11:10:49 -0400
Received: from redback.com (login004.redback.com [155.53.12.57]) by
          prattle.redback.com (Postfix) with ESMTP id D6EF3A5A440 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 17 Jun 2003 08:10:47 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <BAY7-F77u2lKP12qEKA0000baf3@hotmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EEF2F23.9030304@redback.com>
Date:         Tue, 17 Jun 2003 11:09:23 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: OSPF Link State Advertisement
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Ameya Pandit wrote:
> Thanks for the clarification. I am trying to find out what you ended up
> saying. :-). Assume that the network is not Ethernet LAN, but a more
> general
> case (point to point as an example where in we do not have a DR and a BDR).
>
> Is there any user specific table (or any command i can issue) that gives me
> the the interface number on which LS-Ack was sent for a particular LSA?.
> LSA
> details are available. I need to know the interface on which LS-Ack was
> sent. I searched through OSPF-MIBs for the same. However I could not find
> any. Hence my query?

Ameya,

I'm not sure what you are trying to do but the interface(s) on which a
particular LSA was/were ack'ed isn't saved as persistent state informtion.
When a packet is sent on an interface, the determination of the ifIndex
corresponding to that interface is a platform specific detail.

Thanks,
Acee




>
> Any ideas are really welcome.
>
> Rgds
> Ameya
>
>
>> From: Don Goodspeed <dgoodspe@EXCITE.COM>
>> Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
>> To: OSPF@PEACH.EASE.LSOFT.COM
>> Subject: Re: OSPF Link State Advertisement
>> Date: Mon, 16 Jun 2003 14:06:57 -0400
>>
>> Ameya,
>>
>> Remember that LSA are global, but a LS-Ack is acknowledging receipt
>> from a specific neighbor (or a specific DR on a LAN segment), not
>> for the LSA in general.  Therefore, the interface associated with
>> that neighbor and/or DR should always be known.
>>
>> -don
>>
>> ==========================================
>> Hello,
>>
>> I have a query on link State Acknowledgements (LSAck). We know that
>> when a
>> router receives a link state advertisement (LSA) it sends a LSAck for the
>> received LSA. I understand that it is possible to couple different
>> acknowledgements together. However, my question is: how do we
>> determine the
>> 'ifIndex' of the interface on which the router sends the LSAck for the
>> currently received LSA.
>> Is there any way we can find out the interface on which the LSAck was
>> sent
>> knowing the details in the
>> received LSA (viz. Seq, Checksum et. al.). ?? . In other words, i need to
>> know the
>> interface on which the LSA was received.
>>
>> More specifically, I have a requirement where in my Network Management
>> Software needs to know the ifIndex (and eventually the neighbor that sent
>> (forwarded) the LSA) of the interface on which the LSAck was generated
>> for
>> the LSA. I have the details of the LSA. I checked the OSPF MIB however
>> there
>> was no way to get the ifIndex on which the LSA was received.
>>
>> Any guidance would be helpful.
>>
>> Regards
>> -Ameya
>>
>> _______________________________________________
>> Join Excite! - http://www.excite.com
>> The most personalized portal on the Web!
>
>
> _________________________________________________________________
> Wedding blues? Need help? http://www.msn.co.in/Matrimony/
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 18 00:56:19 2003
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 AAA23335
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 18 Jun 2003 00:56:17 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00A1D790@cherry.ease.lsoft.com>; Wed, 18 Jun 2003 0:56:17 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45960776 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 18 Jun 2003 00:56:13 -0400
Received: from 64.4.11.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Wed, 18 Jun 2003 00:56:13 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue,
          17 Jun 2003 21:56:12 -0700
Received: from 203.197.24.195 by by7fd.bay7.hotmail.msn.com with HTTP; Wed, 18
          Jun 2003 04:56:11 GMT
X-Originating-IP: [203.197.24.195]
X-Originating-Email: [ameya_nms@hotmail.com]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 18 Jun 2003 04:56:12.0171 (UTC)
                       FILETIME=[F09B55B0:01C33555]
Message-ID:  <BAY7-F61A2DJxRVVfdY000007e8@hotmail.com>
Date:         Wed, 18 Jun 2003 04:56:11 +0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Ameya Pandit <ameya_nms@HOTMAIL.COM>
Subject: Re: OSPF Link State Advertisement
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Thanks!!  ... the reason i am asking this is because an NMS (Network
Management Software) uses SNMP queries for getting routing specific
information. Hence, whenever the NMS receives a 'trap' message from the
router for a specific LSA (assume an event is configured when an LSA is
received) then i need to get the neighbor that had forwarded the LSA.

Using SNMP and OSPF-MIBs, we can query Object Identifiers (OID) for getting
the details of the LSA. However, I did not find a way of getting the
neighbor from where the LSA was forwarded. One of the workarounds I was
thinking for this was to issue a particular command (if any) to get the
neighbor and thereby the ifIndex. In some manner or the other I need to know
the neighbor that had forwarded the LSA.

Hope i was clear here.

Regards
Ameya


>From: Acee Lindem <acee@REDBACK.COM>
>Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: Re: OSPF Link State Advertisement
>Date: Tue, 17 Jun 2003 11:09:23 -0400
>
>Ameya Pandit wrote:
>>Thanks for the clarification. I am trying to find out what you ended up
>>saying. :-). Assume that the network is not Ethernet LAN, but a more
>>general
>>case (point to point as an example where in we do not have a DR and a
>>BDR).
>>
>>Is there any user specific table (or any command i can issue) that gives
>>me
>>the the interface number on which LS-Ack was sent for a particular LSA?.
>>LSA
>>details are available. I need to know the interface on which LS-Ack was
>>sent. I searched through OSPF-MIBs for the same. However I could not find
>>any. Hence my query?
>
>Ameya,
>
>I'm not sure what you are trying to do but the interface(s) on which a
>particular LSA was/were ack'ed isn't saved as persistent state informtion.
>When a packet is sent on an interface, the determination of the ifIndex
>corresponding to that interface is a platform specific detail.
>
>Thanks,
>Acee
>
>
>
>
>>
>>Any ideas are really welcome.
>>
>>Rgds
>>Ameya
>>
>>
>>>From: Don Goodspeed <dgoodspe@EXCITE.COM>
>>>Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
>>>To: OSPF@PEACH.EASE.LSOFT.COM
>>>Subject: Re: OSPF Link State Advertisement
>>>Date: Mon, 16 Jun 2003 14:06:57 -0400
>>>
>>>Ameya,
>>>
>>>Remember that LSA are global, but a LS-Ack is acknowledging receipt
>>>from a specific neighbor (or a specific DR on a LAN segment), not
>>>for the LSA in general.  Therefore, the interface associated with
>>>that neighbor and/or DR should always be known.
>>>
>>>-don
>>>
>>>==========================================
>>>Hello,
>>>
>>>I have a query on link State Acknowledgements (LSAck). We know that
>>>when a
>>>router receives a link state advertisement (LSA) it sends a LSAck for the
>>>received LSA. I understand that it is possible to couple different
>>>acknowledgements together. However, my question is: how do we
>>>determine the
>>>'ifIndex' of the interface on which the router sends the LSAck for the
>>>currently received LSA.
>>>Is there any way we can find out the interface on which the LSAck was
>>>sent
>>>knowing the details in the
>>>received LSA (viz. Seq, Checksum et. al.). ?? . In other words, i need to
>>>know the
>>>interface on which the LSA was received.
>>>
>>>More specifically, I have a requirement where in my Network Management
>>>Software needs to know the ifIndex (and eventually the neighbor that sent
>>>(forwarded) the LSA) of the interface on which the LSAck was generated
>>>for
>>>the LSA. I have the details of the LSA. I checked the OSPF MIB however
>>>there
>>>was no way to get the ifIndex on which the LSA was received.
>>>
>>>Any guidance would be helpful.
>>>
>>>Regards
>>>-Ameya
>>>
>>>_______________________________________________
>>>Join Excite! - http://www.excite.com
>>>The most personalized portal on the Web!
>>
>>
>>_________________________________________________________________
>>Wedding blues? Need help? http://www.msn.co.in/Matrimony/
>>
>
>
>--
>Acee

_________________________________________________________________
Take this online tour. Win an HCL Beanstalk PC.
http://server1.msn.co.in/sp03/hclbeanstalktour/amazing_winxp.html


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 18 08:04:00 2003
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 IAA28953
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 18 Jun 2003 08:04:00 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00A1E1A0@cherry.ease.lsoft.com>; Wed, 18 Jun 2003 8:03:58 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46006081 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 18 Jun 2003 08:03:57 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Wed, 18 Jun 2003 07:53:57 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id HAA28319; Wed, 18 Jun 2003 07:53:56
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200306181153.HAA28319@ietf.org>
Date:         Wed, 18 Jun 2003 07:53:55 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-pillay-esnault-ospf-flooding-07.txt
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 Refresh and Flooding Reduction in Stable
                          Topologies
        Author(s)       : P. Pillay-Esnault
        Filename        : draft-pillay-esnault-ospf-flooding-07.txt
        Pages           : 5
        Date            : 2003-6-17

This document describes an extension to the OSPF protocol to
reduce periodic flooding of Link State Advertisements in
stable topologies.
The OSPF current behavior requires that all LSAs other than DoNotAge
LSAs to be refreshed every 30 minutes. This document proposes to
generalize the use of DoNotAge LSAs to reduce protocol traffic in
stable topologies

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

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-pillay-esnault-ospf-flooding-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-pillay-esnault-ospf-flooding-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:     <2003-6-17144644.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-pillay-esnault-ospf-flooding-07.txt

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

Content-Type: text/plain
Content-ID:     <2003-6-17144644.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 18 08:48:01 2003
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 IAA01406
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 18 Jun 2003 08:47:59 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A1E252@cherry.ease.lsoft.com>; Wed, 18 Jun 2003 8:47:55 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45805365 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 18 Jun 2003 08:47:45 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Wed, 18 Jun 2003 08:46:08 -0400
Received: from redback.com (login004.redback.com [155.53.12.57]) by
          prattle.redback.com (Postfix) with ESMTP id BD5C87299C0; Wed, 18 Jun
          2003 05:45:39 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EF05E93.3090701@redback.com>
Date:         Wed, 18 Jun 2003 08:44:03 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Working Group Last Call for draft-pillay-esnault-ospf-flooding-07.txt
Comments: To: iesg-secretary <iesg-secretary@ietf.org>
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

This is the start of a Working Group last call for
OSPF Refresh and Flooding Reduction in Stable Topologies
(draft-pillay-esnault-ospf-flooding-07.txt).
All comments must be received by Wednesday, July 2, 2003.

The draft can be found at:

http://www.ietf.org/internet-drafts/draft-pillay-esnault-ospf-flooding-07.txt

Thanks,
--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 18 20:10:01 2003
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 UAA07793
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 18 Jun 2003 20:10:00 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00A1F11D@cherry.ease.lsoft.com>; Wed, 18 Jun 2003 20:09:53 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45861007 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 18 Jun 2003 20:09:51 -0400
Received: from 212.17.36.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Wed, 18 Jun 2003 20:09:50 -0400
Received: from fogarty.jakma.org
          (IDENT:KCqN1ACXtRcBsf6kgYwY00cVlQtWm3ts@fogarty.jakma.org
          [192.168.0.4]) by hibernia.jakma.org (8.11.6/8.11.6) with ESMTP id
          h5J09nA32134 for <OSPF@peach.ease.lsoft.com>; Thu, 19 Jun 2003
          01:09:49 +0100
X-X-Sender: paul@fogarty.jakma.org
X-NSA: iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt
       mustard gas
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.LNX.4.44.0306190101590.16473-100000@fogarty.jakma.org>
Date:         Thu, 19 Jun 2003 01:09:49 +0100
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Paul Jakma <paul@CLUBI.IE>
Subject: Re: NSSA NP option bit clarification
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <017401c330ff$42228c60$386545ab@amer.cisco.com>
Precedence: list

Hi Sina,

On Thu, 12 Jun 2003, Sina Mirtorabi wrote:

> Appendix A, RFC 3101
> -----
> N-bit:        The N-bit describes the router's NSSA capability.  The N-
>               bit is ##used only in Hello packets## and ensures that all
>               members of an NSSA agree on that area's configuration.
>               When the N-bit is set in the Hello packet that is sent out
>               a particular interface, it means that the router will send
>               and receive Type-7 LSAs on that interface.  Two routers
>               will not form an adjacency unless they agree on the state
>               of the N-bit.  If the N-bit is set in the options field,
>               the E-bit must be clear.
>
> P-bit:        The P-bit is ##used only in the Type-7 LSA header##.  It
> flags

ok. that makes it quite clear -> N bit works similarly to E in Hello
packets. What was confusing me was that state of E is usually also
held in DD options.

thank you for clearing up my misunderstanding, and thank you to the
others who also replied with informative comment!

regards,
--
Paul Jakma      paul@clubi.ie   paul@jakma.org  Key ID: 64A2FF6A
        warning: do not ever send email to spam@dishone.st
Fortune:
Before Xerox, five carbons were the maximum extension of anybody's ego.


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 18 20:24:22 2003
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 UAA08355
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 18 Jun 2003 20:24:22 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00A1F271@cherry.ease.lsoft.com>; Wed, 18 Jun 2003 20:24:21 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45861575 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 18 Jun 2003 20:24:20 -0400
Received: from 212.17.36.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Wed, 18 Jun 2003 20:24:19 -0400
Received: from fogarty.jakma.org
          (IDENT:0vwAc/3qZiRupgffoEHBYL48Yhr5I0+W@fogarty.jakma.org
          [192.168.0.4]) by hibernia.jakma.org (8.11.6/8.11.6) with ESMTP id
          h5J0OIA32569 for <OSPF@peach.ease.lsoft.com>; Thu, 19 Jun 2003
          01:24:18 +0100
X-X-Sender: paul@fogarty.jakma.org
X-NSA: iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt
       mustard gas
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.LNX.4.44.0306190114070.16473-100000@fogarty.jakma.org>
Date:         Thu, 19 Jun 2003 01:24:18 +0100
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Paul Jakma <paul@CLUBI.IE>
Subject: Re: NSSA NP option bit clarification
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <01KX0E8NHR1Q8WY6ZE@omega7.wr.usgs.gov>
Precedence: list

On Thu, 12 Jun 2003, Pat Murphy - (650)329-4044 wrote:

>       N-bit:  The N-bit describes the the router's NSSA
>               capability.  The N-bit is used only in Hello
>               packets and ensures that all members of an NSSA
>               agree on that area's configuration.
>
> Late in the game of getting RFC 3101 published it stopped being an issue
> with me. I was not around when this text was written this way and can't
> shed any light on the exact intentions of Rob and Vince. My guess is they
> were simply trying to distinguish the use of this bit in the Hello Packet
> versus its use in the Type-7 LSA option field, and that it had nothing at
> all to do with how the bit was used in the DD packet.  I suppose its too
> late now to make this text a little clearer. I do recommend that you don't
> read too much into it.

Yes, its rather unfortunate, as for most other bits you can treat DD
options field as the prime source for neighbour capabilities.
However, N bit leaves it unspecified for DD options it seems, would
have been nice if it had followed E-bit semantics.

> Pat

regards,
--
Paul Jakma      paul@clubi.ie   paul@jakma.org  Key ID: 64A2FF6A
        warning: do not ever send email to spam@dishone.st
Fortune:
Poverty must have its satisfactions, else there would not be so many poor
people.
                -- Don Herold


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 19 07:40:41 2003
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 HAA09798
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Jun 2003 07:40:41 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00A20733@cherry.ease.lsoft.com>; Thu, 19 Jun 2003 7:40:40 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45936262 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 19 Jun 2003 07:40:38 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 19 Jun 2003 07:30:38 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id HAA09156; Thu, 19 Jun 2003 07:30:37
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200306191130.HAA09156@ietf.org>
Date:         Thu, 19 Jun 2003 07:30:36 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-mirtorabi-ospfv3-af-01.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : Support of address families in OSPFv3
        Author(s)       : S. Mirtorabi, M. Barnes, A. Roy
        Filename        : draft-mirtorabi-ospfv3-af-01.txt
        Pages           : 9
        Date            : 2003-6-18

This document describes an extensible mechanism to support Address
Families in OSPFv3. One undefined field in the Router-LSA is used to
define the address-families on a link. A router may participate in
multiple address families on different links. This information needs
to be advertised so that only applicable link are used in the SPF
calculation when building an address family specific shortest path
tree.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mirtorabi-ospfv3-af-01.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-mirtorabi-ospfv3-af-01.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-mirtorabi-ospfv3-af-01.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:     <2003-6-18121918.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-mirtorabi-ospfv3-af-01.txt

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

Content-Type: text/plain
Content-ID:     <2003-6-18121918.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 19 07:41:29 2003
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 HAA09866
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Jun 2003 07:41:28 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00A205D0@cherry.ease.lsoft.com>; Thu, 19 Jun 2003 7:41:28 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45936294 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 19 Jun 2003 07:41:27 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 19 Jun 2003 07:31:27 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id HAA09353; Thu, 19 Jun 2003 07:31:25
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200306191131.HAA09353@ietf.org>
Date:         Thu, 19 Jun 2003 07:31:25 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-katz-yeung-ospf-traffic-10.txt
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 2
        Author(s)       : D. Katz, D. Yeung, K. Kompella
        Filename        : draft-katz-yeung-ospf-traffic-10.txt
        Pages           : 15
        Date            : 2003-6-18

This document describes extensions to the OSPF protocol version 2 to
support intra-area Traffic Engineering, using Opaque Link State
Advertisements.

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

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-katz-yeung-ospf-traffic-10.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-katz-yeung-ospf-traffic-10.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:     <2003-6-18122046.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-katz-yeung-ospf-traffic-10.txt

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

Content-Type: text/plain
Content-ID:     <2003-6-18122046.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 19 09:12:31 2003
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 JAA16493
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Jun 2003 09:12:31 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00A20ADD@cherry.ease.lsoft.com>; Thu, 19 Jun 2003 9:12:30 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45941797 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 19 Jun 2003 09:12:18 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 19 Jun 2003 09:12:18 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id EF1DD1E744D for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 Jun 2003 06:10:23 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <BAY7-F61A2DJxRVVfdY000007e8@hotmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EF1B5D2.2010304@redback.com>
Date:         Thu, 19 Jun 2003 09:08:34 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: OSPF Link State Advertisement
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Ameya,

Ameya Pandit wrote:
> Thanks!!  ... the reason i am asking this is because an NMS (Network
> Management Software) uses SNMP queries for getting routing specific
> information. Hence, whenever the NMS receives a 'trap' message from the
> router for a specific LSA (assume an event is configured when an LSA is
> received) then i need to get the neighbor that had forwarded the LSA.

The OSPF MIB doesn't have a trap defined for reception of an LSA. The
OSPF flooding process should be precede very quickly and, IMHO,
it doesn't really make sense to try and monitor it using SNMP.


>
> Using SNMP and OSPF-MIBs, we can query Object Identifiers (OID) for getting
> the details of the LSA. However, I did not find a way of getting the
> neighbor from where the LSA was forwarded. One of the workarounds I was
> thinking for this was to issue a particular command (if any) to get the
> neighbor and thereby the ifIndex. In some manner or the other I need to
> know
> the neighbor that had forwarded the LSA.
>
> Hope i was clear here.
>
> Regards
> Ameya
>
>
>> From: Acee Lindem <acee@REDBACK.COM>
>> Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
>> To: OSPF@PEACH.EASE.LSOFT.COM
>> Subject: Re: OSPF Link State Advertisement
>> Date: Tue, 17 Jun 2003 11:09:23 -0400
>>
>> Ameya Pandit wrote:
>>
>>> Thanks for the clarification. I am trying to find out what you ended up
>>> saying. :-). Assume that the network is not Ethernet LAN, but a more
>>> general
>>> case (point to point as an example where in we do not have a DR and a
>>> BDR).
>>>
>>> Is there any user specific table (or any command i can issue) that gives
>>> me
>>> the the interface number on which LS-Ack was sent for a particular LSA?.
>>> LSA
>>> details are available. I need to know the interface on which LS-Ack was
>>> sent. I searched through OSPF-MIBs for the same. However I could not
>>> find
>>> any. Hence my query?
>>
>>
>> Ameya,
>>
>> I'm not sure what you are trying to do but the interface(s) on which a
>> particular LSA was/were ack'ed isn't saved as persistent state
>> informtion.
>> When a packet is sent on an interface, the determination of the ifIndex
>> corresponding to that interface is a platform specific detail.
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>>>
>>> Any ideas are really welcome.
>>>
>>> Rgds
>>> Ameya
>>>
>>>
>>>> From: Don Goodspeed <dgoodspe@EXCITE.COM>
>>>> Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
>>>> To: OSPF@PEACH.EASE.LSOFT.COM
>>>> Subject: Re: OSPF Link State Advertisement
>>>> Date: Mon, 16 Jun 2003 14:06:57 -0400
>>>>
>>>> Ameya,
>>>>
>>>> Remember that LSA are global, but a LS-Ack is acknowledging receipt
>>>> from a specific neighbor (or a specific DR on a LAN segment), not
>>>> for the LSA in general.  Therefore, the interface associated with
>>>> that neighbor and/or DR should always be known.
>>>>
>>>> -don
>>>>
>>>> ==========================================
>>>> Hello,
>>>>
>>>> I have a query on link State Acknowledgements (LSAck). We know that
>>>> when a
>>>> router receives a link state advertisement (LSA) it sends a LSAck
>>>> for the
>>>> received LSA. I understand that it is possible to couple different
>>>> acknowledgements together. However, my question is: how do we
>>>> determine the
>>>> 'ifIndex' of the interface on which the router sends the LSAck for the
>>>> currently received LSA.
>>>> Is there any way we can find out the interface on which the LSAck was
>>>> sent
>>>> knowing the details in the
>>>> received LSA (viz. Seq, Checksum et. al.). ?? . In other words, i
>>>> need to
>>>> know the
>>>> interface on which the LSA was received.
>>>>
>>>> More specifically, I have a requirement where in my Network Management
>>>> Software needs to know the ifIndex (and eventually the neighbor that
>>>> sent
>>>> (forwarded) the LSA) of the interface on which the LSAck was generated
>>>> for
>>>> the LSA. I have the details of the LSA. I checked the OSPF MIB however
>>>> there
>>>> was no way to get the ifIndex on which the LSA was received.
>>>>
>>>> Any guidance would be helpful.
>>>>
>>>> Regards
>>>> -Ameya
>>>>
>>>> _______________________________________________
>>>> Join Excite! - http://www.excite.com
>>>> The most personalized portal on the Web!
>>>
>>>
>>>
>>> _________________________________________________________________
>>> Wedding blues? Need help? http://www.msn.co.in/Matrimony/
>>>
>>
>>
>> --
>> Acee
>
>
> _________________________________________________________________
> Take this online tour. Win an HCL Beanstalk PC.
> http://server1.msn.co.in/sp03/hclbeanstalktour/amazing_winxp.html
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 19 09:40:59 2003
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 JAA17508
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Jun 2003 09:40:57 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00A20A17@cherry.ease.lsoft.com>; Thu, 19 Jun 2003 9:40:56 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45943107 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 19 Jun 2003 09:40:55 -0400
Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Thu, 19 Jun 2003 09:40:55 -0400
Received: (qmail 10618 invoked from network); 19 Jun 2003 13:40:54 -0000
Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP;
          19 Jun 2003 13:40:54 -0000
Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by
          bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id JAA23590 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 Jun 2003 09:40:54 -0400
Message-ID:  <200306191340.JAA23590@bigbird.xebeo.com>
Date:         Thu, 19 Jun 2003 09:40:54 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Rohit Dube <rohit@XEBEO.COM>
Subject: Re: I-D ACTION:draft-katz-yeung-ospf-traffic-10.txt
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  Your message of "Thu, 19 Jun 2003 07:31:25 EDT." 
              <200306191131.HAA09353@ietf.org>
Precedence: list

Folks,

Attached below is the output of
`diff -u draft-katz-yeung-ospf-traffic-09.txt draft-katz-yeung-ospf-traffic-10.txt`
(Apologies in advance for the rather larger attachment created by the
output of diff.)

Please review. Specifically, note the changes in the IANA considerations
section.

Thanks,
--rohit.


--- draft-katz-yeung-ospf-traffic-09.txt        Fri Nov 22 11:13:40 2002
+++ draft-katz-yeung-ospf-traffic-10.txt        Thu Jun 19 09:31:47 2003
@@ -3,14 +3,13 @@



-
 Network Working Group                                            D. Katz
-Internet Draft                                          Juniper Networks
-Category: Standards Track                                       D. Yeung
-Expires: April 2003                                     Procket Networks
-draft-katz-yeung-ospf-traffic-09.txt                         K. Kompella
-                                                        Juniper Networks
-                                                            October 2002
+Internet Draft                                               K. Kompella
+Updates: 2370                                           Juniper Networks
+See Also: 2328                                                  D. Yeung
+Category: Standards Track                               Procket Networks
+Expires: December 2003                                         June 2003
+draft-katz-yeung-ospf-traffic-10.txt


             Traffic Engineering Extensions to OSPF Version 2
@@ -41,7 +40,7 @@

 Copyright Notice

-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.



@@ -57,7 +56,7 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 1]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003


 Abstract
@@ -71,24 +70,24 @@

    (This section to be removed before publication).

-   Per comments from the OSPF WG mailing list, the following changes
-   were made:
-
-    - State that operation over multi-access networks with more than two
-      TE devices is not expressly forbidden.
-    - Fix figure in 2.3.1.
-    - Specify that a Remote Interface IP Address sub-TLV is optional for
-      a multi-access link.
-
-
-
-
-
+   Per comments from the IETF-wide Last Call, section 1 re-emphasizes
+   that this document does not address flooding inter-area.

+   Re-iterated that TE LSAs are to be flooded as per RFC 2370 Type 10
+   LSAs.

+   Also, fixed references: some docs cited as "work in progress" are now
+   RFCs; references for unnumbered interfaces moved to Informative.

+   The IANA Considerations section has been re-written.  There are now
+   three types of ranges: Standards Action, Experimental and unassigned.
+   Values from the last range MUST NOT be assigned until a Standards
+   Track RFC defines the IANA Considerations for that range.

+   Removed reference to OSPF Extensions for GMPLS; adjusted reference
+   numbering.

+   Fixed front page headers.



@@ -113,7 +112,7 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 2]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003


 1. Introduction
@@ -130,7 +129,13 @@
    distributing this information within a given OSPF area.  This
    topology does not necessarily match the regular routed topology,
    though this proposal depends on Network LSAs to describe multiaccess
-   links.
+   links.  This document purposely does not say how the mechanisms
+   described here can be used for traffic engineering across multiple
+   OSPF areas; that task is left to future documents.  Furthermore, no
+   changes have been made to the operation of OSPFv2 flooding; in
+   particular, if non-TE capable nodes exist in the topology, they MUST
+   flood TE LSAs as any other type 10 (area-local scope) Opaque LSAs
+   (see [7]).

 1.1. Applicability

@@ -158,20 +163,20 @@

    In "local constraint-based source routing", a router R can compute a
    path from a source node A to a destination node B; typically, A is R
-   itself, and B is specified by a "router address" (see below).  This
-   path may be subject to various constraints on the attributes of the
-   links and nodes that the path traverses, e.g., use green links that
-   have unreserved bandwidth of at least 10Mbps.  This path could then
-   be used to carry some subset of the traffic from A to B, forming a
-   simple but effective means of traffic engineering.  How the subset of



 Katz, Yeung, Kompella        Standards Track                    [Page 3]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003


+   itself, and B is specified by a "router address" (see below).  This
+   path may be subject to various constraints on the attributes of the
+   links and nodes that the path traverses, e.g., use green links that
+   have unreserved bandwidth of at least 10Mbps.  This path could then
+   be used to carry some subset of the traffic from A to B, forming a
+   simple but effective means of traffic engineering.  How the subset of
    traffic is determined, and how the path is instantiated is beyond the
    scope of this document; suffice it to say that one means of defining
    the subset of traffic is "those packets whose IP destinations were
@@ -204,20 +209,14 @@
    reservation state of multi-access networks is for further study.

    This document also does not support unnumbered links.  This
-   deficiency is addressed in [4]; see also [5] and [6].
+   deficiency will be addressed in future documents; see also [4] and
+   [5].

 1.3. Conventions

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [7].
-
-
-
-
-
-
-
+   document are to be interpreted as described in RFC 2119 [6].



@@ -225,14 +224,14 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 4]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003


 2. LSA Format

 2.1. LSA type

-   This extension makes use of the Opaque LSA [8].
+   This extension makes use of the Opaque LSA [7].

    Three types of Opaque LSAs exist, each of which has different
    flooding scope.  This proposal uses only Type 10 LSAs, which have
@@ -281,7 +280,7 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 5]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003


       0                   1                   2                   3
@@ -309,6 +308,9 @@
      |              Type             |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Value...                           |
+     .                                                               .
+     .                                                               .
+     .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The Length field defines the length of the value portion in octets
@@ -325,10 +327,7 @@

    An LSA contains one top-level TLV.

-   There are two top-level TLVs defined:

-     1 - Router Address
-     2 - Link



@@ -337,8 +336,13 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 6]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003
+

+   There are two top-level TLVs defined:
+
+     1 - Router Address
+     2 - Link

 2.4.1. Router Address TLV

@@ -377,11 +381,6 @@

    The Link TLV is type 2, and the length is variable.

-   The following sub-TLVs are defined:
-
-
-
-



@@ -393,8 +392,10 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 7]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003
+

+   The following sub-TLVs of the Link TLV are defined:

      1 - Link type (1 octet)
      2 - Link ID (4 octets)
@@ -428,7 +429,7 @@
    point in front of it.  Thus the above represents the value
         (-1)**(S) * 2**(Exponent-127) * (1 + Fraction)

-   For more details, refer to [9].
+   For more details, refer to [8].

 2.5. Sub-TLV Details

@@ -445,11 +446,9 @@



-
-
 Katz, Yeung, Kompella        Standards Track                    [Page 8]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003


 2.5.2. Link ID
@@ -505,7 +504,7 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 9]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003


    The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in
@@ -561,7 +560,7 @@

 Katz, Yeung, Kompella        Standards Track                   [Page 10]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003


 3. Elements of Procedure
@@ -594,51 +593,56 @@
    calculated and ought to work.


-5. Normative References
+Normative References
+
+   [1]  Moy, J., "OSPF Version 2", RFC 2328, April 1998.
+
+   [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [7]  Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998.
+
+   [8]  IEEE, "IEEE Standard for Binary Floating-Point Arithmetic",
+        Standard 754-1985, 1985 (ISBN 1-5593-7653-8).

-   [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998.

-   [4] Kompella, K., Rekhter, Y., et al, "OSPF Extensions in Support of
-       Generalized MPLS," work in progress.

-   [6] Kompella, K., and Y. Rekhter, "Signalling Unnumbered Links in
-       RSVP-TE," work in progress.

-   [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
-       Levels", BCP 14, RFC 2119, March 1997.

-   [8] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998.

-   [9] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic",
-       Standard 754-1985, 1985 (ISBN 1-5593-7653-8).




 Katz, Yeung, Kompella        Standards Track                   [Page 11]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003


-6. Informative References
+Informative References

-   [2] Awduche, D., et al, "Requirements for Traffic Engineering Over
-   MPLS," RFC 2702, September 1999.
+   [2]  Awduche, D., et al, "Requirements for Traffic Engineering Over
+        MPLS," RFC 2702, September 1999.

-   [3] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering,"
-   work in progress.
+   [3]  Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering,"
+        work in progress.

-   [5] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling
-   Unnumbered Links in CR-LDP," work in progress.
+   [4]  Kompella, K., and Y. Rekhter, "Signalling Unnumbered Links in
+        Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE),"
+        RFC 3477, January 2003.

-   [10] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA
-   Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.
+   [5]  Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling
+        Unnumbered Links in CR-LDP (Constraint-Routing Label
+        Distribution Protocol)," RFC 3480, February 2003.

-   [11] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital
-   Signatures", RFC 2154, June 1997.
+   [9]  Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital
+        Signatures", RFC 2154, June 1997.
+
+   [10] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.


-7. Security Considerations
+Security Considerations

    This document specifies the contents of Opaque LSAs in OSPFv2.  As
    Opaque LSAs are not used for SPF computation or normal routing, the
@@ -648,39 +652,60 @@
    securing the transmission of normal OSPF LSAs be applied equally to
    all Opaque LSAs, including the TE LSAs specified here.

-   Note that the mechanisms in [1] and [11] apply to Opaque LSAs.  It is
+   Note that the mechanisms in [1] and [9] apply to Opaque LSAs.  It is
    suggested that any future mechanisms proposed to secure/authenticate
    OSPFv2 LSA exchanges be made general enough to be used with Opaque
    LSAs.


-8. IANA Considerations

-   The top level Types in a TE LSA as well as Types for sub-TLVs in a TE
-   Link TLV are to be registered with IANA.

-   Following the guidelines set in [10], top level Types in TE LSAs from
-   3 through 32767 are to be assigned by Expert Review (the said Expert
-   to be decided by the IESG).  Types from 32768 through 65535 are
-   reserved for Private Use.  In all cases, assigned values Types MUST
-   be registered with IANA.
-
-   Also, sub-Types of a TE Link TLV from 10 to 32767 are to be assigned
-   by Expert Review; values from 32768 through 32772 are reserved for
-   Private Use; and values from 32773 through 65535 are to be assigned
+
+
+
+
+
+
+



 Katz, Yeung, Kompella        Standards Track                   [Page 12]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003
+

+IANA Considerations

-   First Come First Served.  In all cases, assigned values are to be
-   registered with IANA.
+   The top level Types in a TE LSA as well as Types for sub-TLVs for
+   each top level Type are to be registered with IANA, except as noted.

+   Here are the guidelines (using terms defined in [10]) for the
+   assignment of top level Types in TE LSAs:
+    o Types in the range 3-32767 are to be assigned via Standards
+      Action.
+    o Types in the range 32768-32777 are for experimental use; these
+      will not be registered with IANA, and MUST NOT be mentioned by
+      RFCs.
+    o Types in the range 32778-65535 are not to be assigned at this
+      time.  Before any assignments can be made in this range, there
+      MUST be a Standards Track RFC that specifies IANA Considerations
+      that covers the range being assigned.
+
+   The guidelines for the assignment of types for sub-TLVs in a TE LSA
+   are as follows:
+    o Types in the range 10-32767 are to be assigned via Standards
+      Action.
+    o Types in the range 32768-32777 are for experimental use; these
+      will not be registered with IANA, and MUST NOT be mentioned by
+      RFCs.
+    o Types in the range 32778-65535 are not to be assigned at this
+      time.  Before any assignments can be made in this range, there
+      MUST be a Standards Track RFC that specifies IANA Considerations
+      that covers the range being assigned.

-9. Authors' Addresses
+
+Authors' Addresses

    Dave Katz
    Juniper Networks
@@ -698,6 +723,14 @@
    Phone:  +1 408 635-7900
    Email: myeung@procket.com

+
+
+
+Katz, Yeung, Kompella        Standards Track                   [Page 13]
+
+Internet Draft           TE Extensions to OSPFv2               June 2003
+
+
    Kireeti Kompella
    Juniper Networks
    1194 N. Mathilda Ave.
@@ -707,7 +740,7 @@
    Email:  kireeti@juniper.net


-10. IPR Notices
+IPR Notice

    The IETF takes no position regarding the validity or scope of any
    intellectual property or other rights that might be claimed to
@@ -724,23 +757,15 @@
    be obtained from the IETF Secretariat.

    The IETF invites any interested party to bring to its attention any
-
-
-
-Katz, Yeung, Kompella        Standards Track                   [Page 13]
-
-Internet Draft           TE Extensions to OSPFv2            October 2002
-
-
    copyrights, patents or patent applications, or other proprietary
    rights which may cover technology that may be required to practice
    this standard.  Please address the information to the IETF Executive
    Director.


-11. Full Copyright Notice
+Full Copyright Notice

-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
@@ -754,6 +779,14 @@
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
+
+
+
+Katz, Yeung, Kompella        Standards Track                   [Page 14]
+
+Internet Draft           TE Extensions to OSPFv2               June 2003
+
+
    English.

    The limited permissions granted above are perpetual and will not be
@@ -767,7 +800,10 @@
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


+Acknowledgement

+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.



@@ -783,5 +819,24 @@



-Katz, Yeung, Kompella        Standards Track                   [Page 14]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Katz, Yeung, Kompella        Standards Track                   [Page 15]



From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 19 10:56:54 2003
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 KAA22834
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Jun 2003 10:56:53 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A20C02@cherry.ease.lsoft.com>; Thu, 19 Jun 2003 10:56:53 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45948503 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 19 Jun 2003 10:56:51 -0400
Received: from 32.97.110.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 19 Jun 2003 10:56:51 -0400
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com
          [9.17.193.32]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id
          h5JEunkj272462 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 Jun 2003
          10:56:49 -0400
Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82])
          by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id
          h5JEulVd081326 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 Jun 2003
          08:56:47 -0600
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|June
             10, 2003) at 06/19/2003 08:56:47
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Message-ID:  <OF8137A05F.EAF3357A-ON85256D4A.00505505-85256D4A.0051BC34@us.ibm.com>
Date:         Thu, 19 Jun 2003 10:56:44 -0400
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: OSPFv3: Source/dest IP address for virtual link
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

The OSPFv3 RFC says to use the first address with the LA-bit set from a
host's set of intra-area prefix LSAs as the destination address of a
virtual link.
Also, draft-ietf-ospf-ospfv3-auth-01.txt says that for the source address a
host should use its own first address with the LA-bit set from its
intra-area prefix LSAs.

With hosts possibly originating multiple intra-area prefix LSAs, what's the
mechanism for choosing which intra-area prefix LSA is first?  We are
thinking of using the one from the host with the lowest LSID,and if an
eligible address is not found, continuing the search at the next-highest
LSID, etc.   We would do the same in picking our virtual link source
address.

But even this has problems.  There's no guarantee that LSAs will arrive in
any order, even if they were sent out consecutively.  Supposed a host with
a virtual link sends an intra-area prefix LSA with LSID of 1, the virtual
link neighbor picks the first LA-bit address out of it, then one arrives
with an LSID of 0 that also has an eligible address in it?    Does the
virtual link get torn down and then rebuilt with the new address?

Also, what about when addresses disappear because of renumbering or are
simply removed?  Suppose we choose address A as the virtual link
destination and then at a later time address A is removed from the LSA
database?

We are considering requiring our customers to configure  source addresses
for  virtual links.  We would then advertise that address in an intra-area
prefix LSA whose LSID is 0.

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


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 19 11:32:46 2003
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 LAA25608
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Jun 2003 11:32:45 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A20D5C@cherry.ease.lsoft.com>; Thu, 19 Jun 2003 11:32:43 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45950586 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 19 Jun 2003 11:32:41 -0400
Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 19 Jun 2003 11:32:41 -0400
Received: from smirtoraw2k03 (sjc-vpn2-333.cisco.com [10.21.113.77]) by
          fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h5JFWe004446 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 Jun 2003 08:32:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
Message-ID:  <001201c33678$04cfab80$f2ce7243@amer.cisco.com>
Date:         Thu, 19 Jun 2003 08:32:39 -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: I-D ACTION:draft-mirtorabi-ospfv3-af-01.txt
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <200306191130.HAA09156@ietf.org>
Precedence: list
Content-Transfer-Encoding: 7bit

All,

Below are the diff between ver *-00 and *-01

o Section 4, Note 1 has been updated
o Section 5, LS type has been changed ( 0xA00A was used by another draft
)
o Section 6 is a new section
o Section 7 has been updated

Thanks
Sina

->-----Original Message-----
->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On
->Behalf Of Internet-Drafts@IETF.ORG
->Sent: Thursday, June 19, 2003 4:31 AM
->To: OSPF@PEACH.EASE.LSOFT.COM
->Subject: I-D ACTION:draft-mirtorabi-ospfv3-af-01.txt
->
->
->A New Internet-Draft is available from the on-line
->Internet-Drafts directories.
->
->
->        Title           : Support of address families in OSPFv3
->        Author(s)       : S. Mirtorabi, M. Barnes, A. Roy
->        Filename        : draft-mirtorabi-ospfv3-af-01.txt
->        Pages           : 9
->        Date            : 2003-6-18
->
->This document describes an extensible mechanism to support
->Address Families in OSPFv3. One undefined field in the
->Router-LSA is used to define the address-families on a link.
->A router may participate in multiple address families on
->different links. This information needs to be advertised so
->that only applicable link are used in the SPF calculation
->when building an address family specific shortest path tree.
->
->A URL for this Internet-Draft is:
->http://www.ietf.org/internet-drafts/draft-->mirtorabi-ospfv3-af-01.txt
->
->To remove yourself from the IETF Announcement list, send a
->message to ietf-announce-request with the word unsubscribe in
->the body of the message.
->
->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-mirtorabi-ospfv3-af-01.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-mirtorabi-ospfv3-af-01.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.


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 20 13:40:15 2003
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 NAA19797
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 Jun 2003 13:40:14 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00A23AC3@cherry.ease.lsoft.com>; Fri, 20 Jun 2003 13:40:11 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46071774 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 20 Jun 2003 13:40:08 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Fri, 20 Jun 2003 13:40:08 -0400
Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h5KHe7u88981 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 20 Jun 2003 10:40:07 -0700 (PDT)
          (envelope-from qv@juniper.net)
Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id
          h5KHe7n38087; Fri, 20 Jun 2003 10:40:07 -0700 (PDT) (envelope-from qv)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <3EEAF9C9.8090601@redback.com>
            <001001c33431$02ac8b50$386545ab@amer.cisco.com>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Message-ID:  <200306201740.h5KHe7n38087@fuinar.juniper.net>
Date:         Fri, 20 Jun 2003 10:40:07 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Quaizar Vohra <qv@JUNIPER.NET>
Subject: Re: Address Family Support in OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <001001c33431$02ac8b50$386545ab@amer.cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Sina,

I like the idea of using instance-ids for multiple address
families rather than adding AF specific changes to the existing LSAs.

Please see my answers inline to all the disadvantages you have
listed to using instance-ids for AFs.


 > Acee, all
 >
 >
 > Let me summarize what are the disadvantages of using Instance-ID to run
 > multiple AF
 >
 >
 > running multiple instance will
 >
 > a) require to maintain more adjacencies, in fact to add N AF you may
 > have to add N adjacencies. This will increase sending and processing of
 > Hello packet by N for each node

I don't think creation and maintanence of extra adjs itself is a
problem, specially if N is 2 or 3. Also there is ongoing development
of IGP independent fast liveness protocols on links (needs only one
hello per link irrespective of whatever other protocols, e.g.  OSPF,
are being run on the link). Given that generally the world is heading
in that direction, it would be okay to run IGP hellos with larger
intervals and so hello maintanence is not a real problem. Even without
that it is not a problem.

 >
 > b) require to maintain more LSDB, in fact type 1 & 2 LSA ( which are Not
 > AF specific) are used again in each instance for each overlapping AF
 > topology
 >
 > c) increase the flooding and processing of OSPF packets, this result
 > from an increase in adjacency and regeneration of type 1&2 LSA within
 > each instance

Flooding and packet processing will be affected by a factor of 2
atmost, as typically the database is dominated by LSAs carrying prefix
information. So the only thing you are saving on is advertising the
same prefix LSAs for unicast and multicast (for IPv4 and IPv6 you will
have to anyway originate different prefix LSAs. If you start carrying
different metric values for different AFs then the savings in the
router LSA is also gone (due to logical fragmentation if your router
LSAs are big and if not then you network is small and this should not
be a problem).

And if you want to advertise different unicast and multicast
topologies, in all likehood the topologies are really different with
some overlap. In that case, the saving is smaller than a factor of 2.
Specially once you get down to summarizing your prefixes, the metric
for each topology will be different and then you will anyway advertise
2 LSAs.

Also if you want to be selective about which prefixes you advertise in
unicast and multicast, or if you want to advertise external LSAs with
different costs in unicast and multicast topologies, the benefits are
even less.

A very similar argument can be made against the savings in the size of
the LSDB.

 >
 > D) need a mapping of instance-ID to AF which is user dependent and can
 > be prone to misconfiguration and increase troubleshooting.

Mapping AF to Instance shouldn't be that difficult. We could reserve
certain instance ids for the well known AFs.

 >
 > Further other routing protocols ( ISIS, BGP, EIGRP) have adopted AF,
 > although OSPFv2 -> OSPFv3 transition went with SIN ( ship in the night)
 > because of inability of v2 to add AF, OSPFv3 separated topology
 > information and AF specific information and move toward AF integration.
 > I am not sure we want to fall back to SIN by using instance_ID

On th other hand, changes like LG election and AF-Functionality LSA or
AF-inter-area-router LSA add significant complexity to code.

As far as changes in ISIS are concerned, the changes there are
more equivalent to using instance-ids then the changes in your
draft. In fact all they do is replicate TLVs, once for each
topology. So they end up advertising proportionately more
LSPs, CSNPS etc. The only saving is in the adjacency formation.

If you still think savings on the adj. is important, than
we could run adjs only within a single instance, shared by
all other AF instances.

The changes you are proposing in the draft are changes to the protocol
itself and are not a gereric or a single high level change which fixes
everything in a clean and complete way. The fear is in the unknown,
i.e. further bandages which will be needed.

Quaizar

 >
 > Thanks
 > Sina


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 20 14:38:26 2003
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 OAA25617
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 Jun 2003 14:38:25 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00A23AF2@cherry.ease.lsoft.com>; Fri, 20 Jun 2003 14:38:23 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46074293 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 20 Jun 2003 14:38:18 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 20 Jun 2003 14:28:17 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id OAA23462; Fri, 20 Jun 2003 14:28:12
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200306201828.OAA23462@ietf.org>
Date:         Fri, 20 Jun 2003 14:28:12 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-nguyen-ospf-lls-03.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : OSPF Link-local Signaling
        Author(s)       : A. Zinin, B. Friedman, A. Roy,
                          L. Nguyen, D. Yeung
        Filename        : draft-nguyen-ospf-lls-03.txt
        Pages           : 7
        Date            : 2003-6-20

OSPF is a link-state intra-domain routing protocol used in IP
networks. OSPF routers exchange information on a link using packets
that follow a well-defined format. The format of OSPF packets is not
flexible enough to enable applications exchange arbitrary data, which
may be necessary in certain situations.  This memo describes a vendor
specific, backward-compatible technique to perform link-local
signaling, i.e., exchange arbitrary data on a link.

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

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-nguyen-ospf-lls-03.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-nguyen-ospf-lls-03.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:     <2003-6-20140445.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-nguyen-ospf-lls-03.txt

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

Content-Type: text/plain
Content-ID:     <2003-6-20140445.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 20 14:38:27 2003
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 OAA25621
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 Jun 2003 14:38:26 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00A23B82@cherry.ease.lsoft.com>; Fri, 20 Jun 2003 14:38:25 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46074296 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 20 Jun 2003 14:38:23 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 20 Jun 2003 14:28:23 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id OAA23494; Fri, 20 Jun 2003 14:28:21
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200306201828.OAA23494@ietf.org>
Date:         Fri, 20 Jun 2003 14:28:21 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-nguyen-ospf-oob-resync-03.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : OSPF Out-of-band LSDB resynchronization
        Author(s)       : A. Zinin, A. Roy, L. Nguyen
        Filename        : draft-nguyen-ospf-oob-resync-03.txt
        Pages           : 7
        Date            : 2003-6-20

OSPF is a link-state intra-domain routing protocol used in IP
networks. LSDB synchronization in OSPF is achieved via two methods--
initial LSDB synchronization when an OSPF router has just been
connected to the network and asynchronous flooding that ensures
continuous LSDB synchronization in the presence of topology changes
after the initial procedure was completed.  It may sometime be
necessary for OSPF routers to resynchronize their LSDBs. OSPF
standard, however, does not allow routers to do so without actually
changing the topology view of the network.  This memo describes a
vendor specific mechanism to perform such form of out-of-band LSDB
synchronization.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-03.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-nguyen-ospf-oob-resync-03.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-nguyen-ospf-oob-resync-03.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:     <2003-6-20140455.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-nguyen-ospf-oob-resync-03.txt

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

Content-Type: text/plain
Content-ID:     <2003-6-20140455.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 20 14:38:35 2003
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 OAA25660
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 Jun 2003 14:38:33 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00A23A52@cherry.ease.lsoft.com>; Fri, 20 Jun 2003 14:38:31 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46074299 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 20 Jun 2003 14:38:29 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 20 Jun 2003 14:28:28 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id OAA23515; Fri, 20 Jun 2003 14:28:26
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200306201828.OAA23515@ietf.org>
Date:         Fri, 20 Jun 2003 14:28:26 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-nguyen-ospf-restart-03.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : OSPF Restart Signaling
        Author(s)       : A. Zinin, A. Roy, L. Nguyen
        Filename        : draft-nguyen-ospf-restart-03.txt
        Pages           : 4
        Date            : 2003-6-20

OSPF is a link-state intra-domain routing protocol used in IP
networks. Routers find new and detect unreachable neighbors via Hello
subprotocol. Hello OSPF packets are also used to ensure two-way
connectivity within time. When a router restarts its OSPF software,
it may not know its neighbors. If such a router sends a hello packet
on an interface, its neighbors are going to reset the adjacency,
which may not be desirable in certain conditions.  This memo
describes a vendor specific mechanism that allows OSPF routers to
inform their neighbors about the restart process.  Note that this
mechanism requires support from neighboring routers.

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

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-nguyen-ospf-restart-03.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-nguyen-ospf-restart-03.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:     <2003-6-20140505.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-nguyen-ospf-restart-03.txt

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

Content-Type: text/plain
Content-ID:     <2003-6-20140505.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@PEACH.EASE.LSOFT.COM  Sat Jun 21 05:37:19 2003
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 FAA04813
	for <ospf-archive@LISTS.IETF.ORG>; Sat, 21 Jun 2003 05:37:18 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00A2503E@cherry.ease.lsoft.com>; Sat, 21 Jun 2003 5:37:18 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46136913 for OSPF@PEACH.EASE.LSOFT.COM;
          Sat, 21 Jun 2003 05:37:17 -0400
Received: from 203.199.83.247 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Sat, 21 Jun 2003 05:37:17 -0400
Received: (qmail 24243 invoked by uid 510); 21 Jun 2003 09:37:12 -0000
Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 21 jun
          2003 09:37:12 -0000
MIME-Version: 1.0
Content-type: multipart/alternative;
              boundary="Next_1056188232---0-203.199.83.247-24238"
Message-ID:  <20030621093712.24242.qmail@mailweb34.rediffmail.com>
Date:         Sat, 21 Jun 2003 09:37:12 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vivek Dubey <vivek_ospf@REDIFFMAIL.COM>
Subject: ospf-tunnel-adjacency-00.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

 This is a multipart mime message


--Next_1056188232---0-203.199.83.247-24238
Content-type: text/html;
        charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<P>=0AHi,<BR>=0A<BR>=0A1)Section 2 and Section 4<BR>=0A--------------------=
------<BR>=0AData packet forwarding between the two ABRs is different from =
a <BR>=0AVL in that the packets are tunneled if the TA path spans multiple =
hops.&nbsp; <BR>=0AThis removes the requirement for routers internal to the=
 transit area <BR>=0Ato have the TA area's unsummarised intra-area routes.<=
BR>=0A<BR>=0AWhy was tunneling chosen over this requirement ?<BR>=0AAny spe=
cific advantage?<BR>=0A<BR>=0A2)Section 5<BR>=0A-----------<BR>=0ATA is ann=
ounced as an unnumbered point-to-point link<BR>=0A<BR>=0AIf TA is unnumbere=
d point to point why Link Data is not <BR>=0A&quot;interface's&nbsp; &nbsp;=
 &nbsp;MIB-II ifIndex value&quot;<BR>=0A<BR>=0AOn a hindsight &quot;why was=
 virtual link itself described<BR>=0Aas unnumbered point to point?&quot;<BR=
>=0ACould have been numbered point to point ??<BR>=0AAny specific advantage=
 because of that ?<BR>=0A<BR>=0A3)Section 10<BR>=0A------------<BR>=0AIf th=
ere is not at least one IP address belonging to<BR>=0ATransit area or TTA a=
nd the virtual link or TA is configured, a<BR>=0Arouter could advertise any=
 of its attached IP address as a stub link<BR>=0A(Link ID set to the router=
's own IP interface address, Link Data set<BR>=0Ato the mask 0xffffffff) to=
 the transit area.<BR>=0A<BR>=0ANot very clear? Why was this required?<BR>=
=0A<BR>=0Athanks,<BR>=0Avivek<BR>=0A<BR>=0A=0A</P>=0A<br><br>=0A<a href=3D"=
http://www.herohonda.com/karizma?rediffmail" target=3D"_blank"><IMG SRC=3D"=
http://ads.rediff.com/RealMedia/ads/adstream_nx.ads/www.rediffmail.com/inbo=
x.htm@Bottom" border=3D0></a>=0A
--Next_1056188232---0-203.199.83.247-24238
Content-type: text/plain;
        charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,=0A=0A1)Section 2 and Section 4=0A--------------------------=0AData pack=
et forwarding between the two ABRs is different from a =0AVL in that the pa=
ckets are tunneled if the TA path spans multiple hops.  =0AThis removes the=
 requirement for routers internal to the transit area =0Ato have the TA are=
a's unsummarised intra-area routes.=0A=0AWhy was tunneling chosen over this=
 requirement ?=0AAny specific advantage?=0A=0A2)Section 5=0A-----------=0AT=
A is announced as an unnumbered point-to-point link=0A=0AIf TA is unnumbere=
d point to point why Link Data is not =0A"interface's   MIB-II ifIndex value"=
=0A=0AOn a hindsight "why was virtual link itself described=0Aas unnumbered=
 point to point?"=0ACould have been numbered point to point ??=0AAny specif=
ic advantage because of that ?=0A=0A3)Section 10=0A------------=0AIf there =
is not at least one IP address belonging to=0ATransit area or TTA and the v=
irtual link or TA is configured, a=0Arouter could advertise any of its atta=
ched IP address as a stub link=0A(Link ID set to the router's own IP interf=
ace address, Link Data set=0Ato the mask 0xffffffff) to the transit area.=
=0A=0ANot very clear? Why was this required?=0A=0Athanks,=0Avivek=0A=0A
--Next_1056188232---0-203.199.83.247-24238--


From owner-ospf@PEACH.EASE.LSOFT.COM  Sun Jun 22 08:25:51 2003
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 IAA10333
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 22 Jun 2003 08:25:36 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A28598@cherry.ease.lsoft.com>; 22 Jun 2003 8:25:04 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46226421 for OSPF@PEACH.EASE.LSOFT.COM;
          Sun, 22 Jun 2003 08:24:57 -0400
Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Sun, 22 Jun 2003 08:24:57 -0400
Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com
          (LSMTP for Digital Unix v1.1b) with SMTP id
          <6.00A28577@cherry.ease.lsoft.com>; 22 Jun 2003 8:24:57 -0400
Message-ID:  <LISTSERV%2003062208245157@PEACH.EASE.LSOFT.COM>
Date:         Sun, 22 Jun 2003 08:24:51 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Igor Miroshnik <IgorM@RADLAN.COM>
Subject: Zero as ospfIfRetransInterval
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

All,

Can anybody clarify the physical sense of assigning ospfIfRetransInterval
to zero? RFC1850 allows such an assignment.

Thanks


From owner-ospf@PEACH.EASE.LSOFT.COM  Sun Jun 22 13:55:15 2003
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 NAA14651
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 22 Jun 2003 13:55:14 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A28D41@cherry.ease.lsoft.com>; 22 Jun 2003 13:55:12 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46244037 for OSPF@PEACH.EASE.LSOFT.COM;
          Sun, 22 Jun 2003 13:55:11 -0400
Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Sun, 22 Jun 2003 13:55:10 -0400
Received: from smirtoraw2k03 (dhcp-171-69-101-56.cisco.com [171.69.101.56]) by
          fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h5MHtAT13787 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Sun, 22 Jun 2003 10:55:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Message-ID:  <000001c338e7$6c50a090$386545ab@amer.cisco.com>
Date:         Sun, 22 Jun 2003 10:55:10 -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: Address Family Support in OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <200306201740.h5KHe7n38087@fuinar.juniper.net>
Precedence: list
Content-Transfer-Encoding: 7bit

Quaizar,

->I don't think creation and maintanence of extra adjs itself
->is a problem, specially if N is 2 or 3. Also there is ongoing
->development of IGP independent fast liveness protocols on
->links (needs only one hello per link irrespective of whatever
->other protocols, e.g.  OSPF, are being run on the link).
->Given that generally the world is heading in that direction,
->it would be okay to run IGP hellos with larger intervals and
->so hello maintanence is not a real problem. Even without that
->it is not a problem.

Independently of a fast liveliness protocols, you would have to send and
process Hellos.
Depending on the number of adj and topology, your N = 2/3 multiplied by
the number of adjacency could be significant. For example say you have a
Hub and Spoke with Hub router having 300 adj, if all Spoke participate
in say two other AF you would end up adding 600 more adj which is
unnecessary and significant

->Flooding and packet processing will be affected by a factor
->of 2 atmost, as typically the database is dominated by LSAs
->carrying prefix information.

Again it all depends on your topology and environment,  in case of AF
proposal not only type 1/2 but also intra-area-prefix will be optimized
since you carry more than one prefix within the intra-area-prefix-LSA (
see below )

If you are in an environment that you are doing summarization then the
dominant LSA can be type 1/2 & intra-area-prefix-lsa therefore you could
gain more than a factor 2. In any case even a factor 2 multiplied by X
number of LSA could be significant

->So the only thing you are saving
->on is advertising the same prefix LSAs for unicast and
->multicast (for IPv4 and IPv6 you will have to anyway
->originate different prefix LSAs. If you start carrying
->different metric values for different AFs then the savings in
->the router LSA is also gone (due to logical fragmentation if
->your router LSAs are big and if not then you network is small
->and this should not be a problem).

In v3 each prefix is defined by  { Prefix, Prefix length, Prefix Options
}, therefore you can add bits in Prefix Options to say to which AF a
prefix belongs and since you want to be backward compatible you can use
the NU bit to exclude the prefix from IPv6 unicast AF ( A short draft
will be available soon to demonstrate that for multicast AF)

This mean that the prefix LSA encoding is flexible enough to carry
prefixes of different lengths (IPv6, IPv4 or whatever), as long as we
can distinguish the correct AF, by say looking at some Prefix Options
bits

-> > D) need a mapping of instance-ID to AF which is user
->dependent and can  > be prone to misconfiguration and
->increase troubleshooting.
->
->Mapping AF to Instance shouldn't be that difficult. We could
->reserve certain instance ids for the well known AFs.

It is not sufficient to reserve some values, what happen if some of your
routers does not understand the given reserved values and you compute
the path through them ?

->On th other hand, changes like LG election and
->AF-Functionality LSA or AF-inter-area-router LSA add
->significant complexity to code.

Significant? I do not believe adding two new LSA add significant
complexity. Further those LSA will be used by _all_ AF and are _generic_

->
->As far as changes in ISIS are concerned, the changes there
->are more equivalent to using instance-ids then the changes in
->your draft.
->In fact all they do is replicate TLVs, once for
->each topology. So they end up advertising proportionately
->more LSPs, CSNPS etc.

Not really, the _same_ LSP is advertised _once_ to sets of neighbors and
a neighbor use whatever TLV it needs. There is no extra adjacency and
extra-flooding because of different AF neighbor

In fact in case of our proposal the LSA flooding is even more optimized
( than ISIS) because type 1/2 are common to all AF further for prefix
information we can use the _same_  prefix LSA and add prefix specific AF
to the existing LSA so it is similar to adding TLV specific AF inside
LSP as in ISIS

->The only saving is in the adjacency formation.

You save also in maintaining LSDB multiple times, further saving in
adjacency leads to saving of flooding LSDB multiple times ( once for
each AF ) and decrease in packet processing

->The changes you are proposing in the draft are changes to the
->protocol itself and are not a generic or a single high level
->change which fixes everything in a clean and complete way.
->The fear is in the unknown, i.e. further bandages which will
->be needed.

The way OSPFv3 was defined, it allows to separate topology information
from prefix information, further prefix LSA information are defined in a
flexible way which could be used for other AF

Therefore the proposed draft leverage and optimize the current OSPFv3
allowing to integrate different AF within OSPFv3, the addition is 2 new
LSAs which are generic to all AF and not a big deal.

I would like to ask WG to debate if they want to go with an integrated
approach or SIN, as OSPFv3 is in the initial deployment phase and a
decision need to be made.

Sina


From owner-ospf@PEACH.EASE.LSOFT.COM  Sun Jun 22 14:24:11 2003
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 OAA15086
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 22 Jun 2003 14:24:11 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A28EAF@cherry.ease.lsoft.com>; 22 Jun 2003 14:24:10 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46245640 for OSPF@PEACH.EASE.LSOFT.COM;
          Sun, 22 Jun 2003 14:24:08 -0400
Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Sun, 22 Jun 2003 14:24:07 -0400
Received: from smirtoraw2k03 (sjc-vpn4-827.cisco.com [10.21.83.58]) by
          fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h5MIO6T05001 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Sun, 22 Jun 2003 11:24:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Message-ID:  <000101c338eb$770f0950$f2ce7243@amer.cisco.com>
Date:         Sun, 22 Jun 2003 11:24: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: ospf-tunnel-adjacency-00.txt
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <000c01c33821$21c6f8b0$f2ce7243@amer.cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Vivek,

->
->Hi,
->
->1)Section 2 and Section 4
->--------------------------
->Data packet forwarding between the two ABRs is different from a
->VL in that the packets are tunneled if the TA path spans
->multiple hops.
->
->This removes the requirement for routers internal to the transit area
->to have the TA area's unsummarised intra-area routes.
->
->Why was tunneling chosen over this requirement ?

Because of summarization.

->Any specific advantage?

In case of TransitCapability type solution your summarization over
transit area need to be ignored. For VL this may not be a big deal as VL
can be only through non-backbone area therefore, not summarizing
internal-backbone area into a transit area is not important ( internal
backbone route are small compared to other areas and it _only_ affect
the transit area )

In case of TA your transit area can be backbone therefore you will lose
all the advantage of summarization of a non-backbone area into the
backbone area which will further affect all other areas

->
->2)Section 5
->-----------
->TA is announced as an unnumbered point-to-point link
->
->If TA is unnumbered point to point why Link Data is not
->"interface's     MIB-II ifIndex value"

There might be confusion regarding unnumbered vs numbered

When you have numbered link that means you assign an IP address to this
link this would translate while announcing adj to add a _stub_ link with
{ Link-ID = IP address & Link Data = IP mask }

As in VL, It is not because you set the Link Data in your adjacency to
an IP address ( vs ifIndex) that your link become numbered

->On a hindsight "why was virtual link itself described
->as unnumbered point to point?"
->Could have been numbered point to point ??
->Any specific advantage because of that ?

The link is unnumbered because you do not have any IP address assign
hence you do Not add a Stub link information in your adjacency.

VL does have an associated IP address ( used as source of IP address for
sending control packet and discovered once you find an intra-area path
to the other end of VL) and the neighbor associated IP address which is
used to send control packet to the other end of VL.

->
->3)Section 10
->------------
->If there is not at least one IP address belonging to
->Transit area or TTA and the virtual link or TA is configured,
->a router could advertise any of its attached IP address as a
->stub link (Link ID set to the router's own IP interface
->address, Link Data set to the mask 0xffffffff) to the transit area.
->
->Not very clear? Why was this required?

As for VL, If your ABRs do not have any numbered link in the transit
area, you cannot calculate the virtual interface's IP address and the
virtual neighbor's IP address which is needed to send unicast control
packet and your VL or TA will fail

If the ABR advertise any of its attached address as /32 into the transit
area you make available an IP address in the transit area for VL or TA
to be operational

thanks
Sina


->
->thanks,
->vivek
->


From owner-ospf@PEACH.EASE.LSOFT.COM  Sun Jun 22 17:23:53 2003
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 RAA19070
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 22 Jun 2003 17:23:52 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00A292EA@cherry.ease.lsoft.com>; 22 Jun 2003 17:23:29 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46250038 for OSPF@PEACH.EASE.LSOFT.COM;
          Sun, 22 Jun 2003 17:23:27 -0400
Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Sun, 22 Jun 2003 17:13:27 -0400
Received: from cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP;
          22 Jun 2003 14:15:16 -0800
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com
          [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id
          h5MLDPRJ014634; Sun, 22 Jun 2003 14:13:25 -0700 (PDT)
Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by
          mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with
          ESMTP id AIJ85358; Sun, 22 Jun 2003 14:06:46 -0700 (PDT)
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------678178BB55F5CABCE438756C"
Message-ID:  <3EF61BF0.3F8C48EC@cisco.com>
Date:         Sun, 22 Jun 2003 23:13:20 +0200
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Robert Raszuk <raszuk@CISCO.COM>
Organization: Signature: http://www.employees.org/~raszuk/sig/
Subject: draft-raszuk-ospf-bgp-peer-discovery-00.txt
Comments: To: internet-drafts@ietf.org
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

This is a multi-part message in MIME format.
--------------678178BB55F5CABCE438756C
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit


--------------678178BB55F5CABCE438756C
Content-Type: text/plain; charset=iso-8859-2;
 name="draft-raszuk-ospf-bgp-peer-discovery-00.txt"
Content-Disposition: inline;
 filename="draft-raszuk-ospf-bgp-peer-discovery-00.txt"
Content-Transfer-Encoding: 7bit







Network Working Group                             Robert Raszuk (Editor)
Internet Draft                                        Cisco Systems, Inc
Category: Standards Track                                      June 2003
Expires: December 2003


                 OSPF Extensions for BGP Peer Discovery
              draft-raszuk-ospf-bgp-peer-discovery-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups. Note that other
   groups may also distribute working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsolete by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This document proposed an extension to OSPF Router Information LSA
   [LINDEM1] to distribute selected information about BGP process on a
   router to other routers in the same area or in the same domain. Such
   information is required for network based auto discovery of IBGP
   peers as described in [IBGP-AM].












Raszuk R.                   Expires Dec 2003                    [Page 1]





Internet Draft        OSPF Ext for IBGP Auto Mesh              June 2003


1. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2. Introduction

   Today all BGP peering configuration is manual and requires action on
   both sides. In IBGP Auto Mesh draft [IBGP-AM] we propose the
   automation of this task for IBGP sessions. As a distribution of
   required information OSPF [RFC2328] native flooding is being
   proposed.

   The information required to be flooded is static and can change only
   by operator's manual configuration.

   It is envisioned that in the future when new and better approaches
   for flooding information are available and deployed BGP Auto
   Discovery TLV could also be migrated from OSPF to be flooded over
   such a new transport.


3. The BGP Auto Discovery TLV

   BGP Auto Discovery TLV is proposed to be flooded inside OSPF Router
   Information LSA.

   The format of OSPF Router Information LSA is indicated for reference
   in Figure 1 as proposed in [LINDEM1]

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |     Options   |   10 or 11    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       4       |                    0                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                            TLVs                             -+
   |                             ...                               |



Raszuk R.                   Expires Dec 2003                    [Page 2]





Internet Draft        OSPF Ext for IBGP Auto Mesh              June 2003


             Figure 1. OSPF Router Information LSA

   For the application of distribution of BGP Auto Discovery TLV only
   area wise flooding scope (code 10) and domain wide flooding scope
   (code 11) are applicable.

   As described in IBGP Auto Mesh document [IBGP-AM] BGP Auto Discovery
   TLV will have the format presented in figure 2.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   TLV Type    |    Length     |     FLOODING RESERVED     |F|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        BGP Identifier                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  FRAG |     BGP  RESERVED     |        16 bit CHECKSUM        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Autonomous System(s) or confederation sub-AS(s) sub-TLV    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             IPv4/IPv6  Peering Address sub-TLV                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             AFI/SAFI for mesh topologies sub-TLV              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AFI/SAFI for reflection topologies sub-TLV           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Old BGP Identifier sub-TLV (opt)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1. BGP Auto Discovery TLV

   Type        One octet set to 2 (to be confirmed).
   Length      One octet indicating the length of the TLV

   Control Flags related to IGP operation:

   Symbol    Capabilities

   F         Flooding scope
   D         Down Bit
   Reserved  Set to all zeros

   "F" {flooding} flooding scope of this TLV, when set domain wide
       flooding scope is required (type 11), when not set TLV should
       not be flooded into other areas or levels (type 10). Default
       "F" not set indicating area wide flooding only (type 10).

   "D" {down} down bit is not relevant to OSPF and should be ignored by



Raszuk R.                   Expires Dec 2003                    [Page 3]





Internet Draft        OSPF Ext for IBGP Auto Mesh              June 2003


       OSPF. It is present in the BGP Auto Discovery TLV to achieve
       identical encapsulation syntax independent from flooding protocol
       being selected by the operator.

   The specific information and encoding of BGP sub-TLVs is discussed in
   [IBGP-AM].


4. Operation

   It should be important to emphasize the fact that OSPF interaction
   with the new information is to remain minimal. BGP component will
   prepare the necessary information to be flooded as well as keep the
   received information in it's own cache. BGP component will also
   inform OSPF about required flooding scope for it's information.

   OSPF role in new information interpretation is limited to selectively
   pass BGP Auto Discovery TLV to BGP component of the router. It is
   assumed that all global LSA comparisons will still take place. On the
   other hand it is not required that OSPF will try to parse and compare
   the TLV itself and based on the result initiate BGP notification or
   not. Added checksum field should make comparison done by BGP itself
   much less CPU intensive.

   Forced reflooding should only take place based on the manual
   configuration change. During normal network operation when BGP
   configuration related to peer maintenance is constant BGP Auto
   Discovery TLV should not cause any extra processing or flooding for
   OSPF.


5. Deployment Considerations

   The new proposed data to be flooded has an informational character.
   Routers which do not understand new information will not be able to
   participate in the IBGP auto mesh.

   Deployment of new code which supports new information can be
   incremental. Also enabling information distribution itself can have
   an incremental character.

   It should be up to operator's decision to switch from informational
   use of BGP Auto Discovery TLV to operational IBGP auto mesh benefits.








Raszuk R.                   Expires Dec 2003                    [Page 4]





Internet Draft        OSPF Ext for IBGP Auto Mesh              June 2003


6. IANA Considerations

   A new opaque LSA type for OSPF Router Information LSA will need to be
   assigned by IANA. Additionally, IANA will need to have registries for
   the OSPF Router Information opaque LSA TLVs.

   The TLV assignee will be responsible for allocation of any sub-TLVs
   for the IANA assigned TLV.


7. Security Considerations

   It is highly encouraged to use existing OSPF security mechanism when
   transporting BGP Auto Discovery TLV [RFC2328]. While addition of new
   information does not present any additional risks injection of not
   authorized OSPF Router Information LSAs containing unreal BGP Auto
   Discovery TLVs could require an implementation of additional
   filtering before attempting to establish IBGP sessions.


8. Acknowledgments

   I would like to express special thanks to Abhay Roy & Peter Psenak
   for their comments.


9. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
       Requirement  Levels", RFC 2119, March 1997.

   [RFC2434]  Narten, T., Alvestrand, H., "Guidelines for Writing an
       IANA Considerations Section in RFCs", RFC 2434, October 1998.


10. Informative References

   [IBGP-AM]  Raszuk, R., "IBGP Auto Mesh", draft-raszuk-ibgp-auto-
       mesh-00.txt, June 2003

   [LINDEM1]  Lindem, A. at all, "Extensions to OSPF for Advertising
       Optional Router Capabilities", draft-lindem-ospf-cap-00.txt, May
       2003

   [RFC2328]  J. Moy. OSPF version 2. Technical Report RFC 2328,
       Internet Engineering Task Force, 1998.





Raszuk R.                   Expires Dec 2003                    [Page 5]





Internet Draft        OSPF Ext for IBGP Auto Mesh              June 2003


11. Authors' Addresses

      Robert Raszuk
      Cisco Systems, Inc.
      Al. Jerozolimskie 146C
      02-305 Warsaw, Poland
      Email: rraszuk@cisco.com



12. IPR Notices

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


13. Terms of Use

   Cisco has a pending patent which relates to the subject matter of
   this Internet Draft.  If a standard relating to this subject matter
   is adopted by IETF and any claims of any issued Cisco patents are
   necessary for practicing this standard, any party will be able to
   obtain a license from Cisco to use any such patent claims under
   openly specified, reasonable, non-discriminatory terms to implement
   and fully comply with the standard.









Raszuk R.                   Expires Dec 2003                    [Page 6]





Internet Draft        OSPF Ext for IBGP Auto Mesh              June 2003


14. Full Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Raszuk R.                   Expires Dec 2003                    [Page 7]



--------------678178BB55F5CABCE438756C--


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 23 09:12:28 2003
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 JAA19251
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Jun 2003 09:12:12 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00A2B205@cherry.ease.lsoft.com>; Mon, 23 Jun 2003 9:11:13 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46330799 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 23 Jun 2003 09:11:06 -0400
Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Mon, 23 Jun 2003 09:11:05 -0400
Received: (qmail 25064 invoked from network); 23 Jun 2003 13:11:05 -0000
Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP;
          23 Jun 2003 13:11:05 -0000
Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by
          bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id JAA22472 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 23 Jun 2003 09:11:05 -0400
X-Mailer: exmh version 2.1.1 10/15/1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <200306231311.JAA22472@bigbird.xebeo.com>
Date:         Mon, 23 Jun 2003 09:11:05 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Rohit Dube <rohit@XEBEO.COM>
Subject: Re: I-D ACTION:draft-katz-yeung-ospf-traffic-10.txt
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  Message from Rohit Dube <rohit@XEBEO.COM> of "Thu, 19 Jun 2003
              09:40:54 EDT." <200306191340.JAA23590@bigbird.xebeo.com>
Precedence: list

Folks,

This draft will be IETF Last-Called shortly (with CC to
OSPF WG) and then submitted for IESG review.

The IANA section has changed significantly from the previous
version as the IESG objected to the Private Use and (my impression)
to a lesser degree with the FCFS range. This has now been fixed
(see diff excerpt below).

If you have comments, now would be the time to make them.

Best,
--rohit.

On Thu, 19 Jun 2003 09:40:54 -0400 Rohit Dube writes:
=>Folks,
=>
=>Attached below is the output of
=>`diff -u draft-katz-yeung-ospf-traffic-09.txt draft-katz-yeung-ospf-traffic-1
>0.txt`
=>(Apologies in advance for the rather larger attachment created by the
=>output of diff.)
=>
=>Please review. Specifically, note the changes in the IANA considerations
=>section.
=>
=>Thanks,
=>--rohit.
=>
=>
=>--- draft-katz-yeung-ospf-traffic-09.txt        Fri Nov 22 11:13:40 2002
=>+++ draft-katz-yeung-ospf-traffic-10.txt        Thu Jun 19 09:31:47 2003
[snip]
=>-8. IANA Considerations
=>
=>-   The top level Types in a TE LSA as well as Types for sub-TLVs in a TE
=>-   Link TLV are to be registered with IANA.
=>
=>-   Following the guidelines set in [10], top level Types in TE LSAs from
=>-   3 through 32767 are to be assigned by Expert Review (the said Expert
=>-   to be decided by the IESG).  Types from 32768 through 65535 are
=>-   reserved for Private Use.  In all cases, assigned values Types MUST
=>-   be registered with IANA.
=>-
=>-   Also, sub-Types of a TE Link TLV from 10 to 32767 are to be assigned
=>-   by Expert Review; values from 32768 through 32772 are reserved for
=>-   Private Use; and values from 32773 through 65535 are to be assigned
=>+
=>+
=>+
=>+
=>+
=>+
=>+
=>
=>
=>
=> Katz, Yeung, Kompella        Standards Track                   [Page 12]
=>
=>-Internet Draft           TE Extensions to OSPFv2            October 2002
=>+Internet Draft           TE Extensions to OSPFv2               June 2003
=>+
=>
=>+IANA Considerations
=>
=>-   First Come First Served.  In all cases, assigned values are to be
=>-   registered with IANA.
=>+   The top level Types in a TE LSA as well as Types for sub-TLVs for
=>+   each top level Type are to be registered with IANA, except as noted.
=>
=>+   Here are the guidelines (using terms defined in [10]) for the
=>+   assignment of top level Types in TE LSAs:
=>+    o Types in the range 3-32767 are to be assigned via Standards
=>+      Action.
=>+    o Types in the range 32768-32777 are for experimental use; these
=>+      will not be registered with IANA, and MUST NOT be mentioned by
=>+      RFCs.
=>+    o Types in the range 32778-65535 are not to be assigned at this
=>+      time.  Before any assignments can be made in this range, there
=>+      MUST be a Standards Track RFC that specifies IANA Considerations
=>+      that covers the range being assigned.
=>+
=>+   The guidelines for the assignment of types for sub-TLVs in a TE LSA
=>+   are as follows:
=>+    o Types in the range 10-32767 are to be assigned via Standards
=>+      Action.
=>+    o Types in the range 32768-32777 are for experimental use; these
=>+      will not be registered with IANA, and MUST NOT be mentioned by
=>+      RFCs.
=>+    o Types in the range 32778-65535 are not to be assigned at this
=>+      time.  Before any assignments can be made in this range, there
=>+      MUST be a Standards Track RFC that specifies IANA Considerations
=>+      that covers the range being assigned.
[snip]


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 23 15:20:16 2003
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 PAA06098
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Jun 2003 15:20:15 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00A2BC78@cherry.ease.lsoft.com>; Mon, 23 Jun 2003 15:16:57 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46357931 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 23 Jun 2003 15:16:42 -0400
Received: from 134.56.3.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Mon, 23 Jun 2003 15:06:37 -0400
Received: from mx01-int.net.com (mx01-int.net.com [134.56.112.13]) by
          mx01.net.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h5NJ8Hb17449
          for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 23 Jun 2003 12:08:17 -0700 (PDT)
Received: from west-mail.net.com (west-mail.net.com [134.56.112.40]) by
          mx01-int.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id
          h5NJ8Hi08763 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 23 Jun 2003
          12:08:17 -0700 (PDT)
Received: from net.com ([134.56.216.89]) by west-mail.net.com (Netscape
          Messaging Server 4.15) with ESMTP id HGY7SE00.IL6 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 23 Jun 2003 12:07:26 -0700
X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en, en-GB, fr, de
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3EF74F8A.22F92D39@net.com>
Date:         Mon, 23 Jun 2003 12:05:46 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: doubt in Figure 5 of RFC 2328
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi all,

In the figure 5 of rfc 2328 "The SPF tree for Router RT6",
there is an extra node between N9 and RT9.

Does that node mean something,or it has been added intentionally.

                                              |   |
                                           N9 o   o N7
                                             /|
                                            / |
                        N11      RT9       /  |RT12
                         o--------o-------o   o--------o H1
                             3                |   10
                                              |2
                                              |
                                              o N10

Thanks,
Mani


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 23 19:09:36 2003
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 TAA14706
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Jun 2003 19:09:36 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A2C920@cherry.ease.lsoft.com>; Mon, 23 Jun 2003 19:09:36 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46384156 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 23 Jun 2003 19:09:35 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Mon, 23 Jun 2003 19:09:35 -0400
Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h5NN9Yu19817 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 23 Jun 2003 16:09:34 -0700 (PDT)
          (envelope-from qv@juniper.net)
Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id
          h5NN9Ye48201; Mon, 23 Jun 2003 16:09:34 -0700 (PDT) (envelope-from qv)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <200306201740.h5KHe7n38087@fuinar.juniper.net>
            <000001c338e7$6c50a090$386545ab@amer.cisco.com>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Message-ID:  <200306232309.h5NN9Ye48201@fuinar.juniper.net>
Date:         Mon, 23 Jun 2003 16:09:34 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Quaizar Vohra <qv@JUNIPER.NET>
Subject: Re: Address Family Support in OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <000001c338e7$6c50a090$386545ab@amer.cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Sina,

Please see my comments inline.

 > Quaizar,
 >
 > ->I don't think creation and maintanence of extra adjs itself
 > ->is a problem, specially if N is 2 or 3. Also there is ongoing
 > ->development of IGP independent fast liveness protocols on
 > ->links (needs only one hello per link irrespective of whatever
 > ->other protocols, e.g.  OSPF, are being run on the link).
 > ->Given that generally the world is heading in that direction,
 > ->it would be okay to run IGP hellos with larger intervals and
 > ->so hello maintanence is not a real problem. Even without that
 > ->it is not a problem.
 >
 > Independently of a fast liveliness protocols, you would have to send and
 > process Hellos.
 > Depending on the number of adj and topology, your N = 2/3 multiplied by
 > the number of adjacency could be significant. For example say you have a
 > Hub and Spoke with Hub router having 300 adj, if all Spoke participate
 > in say two other AF you would end up adding 600 more adj which is
 > unnecessary and significant

300 adjs or 600 adjs with hello interval of 10 seconds, have hardly
had any impact on the CPU on one of the implementations I know about.


 >
 > ->Flooding and packet processing will be affected by a factor
 > ->of 2 atmost, as typically the database is dominated by LSAs
 > ->carrying prefix information.
 >
 > Again it all depends on your topology and environment,  in case of AF
 > proposal not only type 1/2 but also intra-area-prefix will be optimized
 > since you carry more than one prefix within the intra-area-prefix-LSA (
 > see below )
 >
 > If you are in an environment that you are doing summarization then the
 > dominant LSA can be type 1/2 & intra-area-prefix-lsa therefore you could
 > gain more than a factor 2. In any case even a factor 2 multiplied by X
 > number of LSA could be significant

If my dominant LSAs are just type 1/2 and intra-area-prefix, I
wouldn't be very much concerned with a gain of 2, as even in a very
large network, the number of these LSAs won't be very large.
And much of this gain wouldn't even be realized due to
differences in topology.

 >
 > ->So the only thing you are saving
 > ->on is advertising the same prefix LSAs for unicast and
 > ->multicast (for IPv4 and IPv6 you will have to anyway
 > ->originate different prefix LSAs. If you start carrying
 > ->different metric values for different AFs then the savings in
 > ->the router LSA is also gone (due to logical fragmentation if
 > ->your router LSAs are big and if not then you network is small
 > ->and this should not be a problem).
 >
 > In v3 each prefix is defined by  { Prefix, Prefix length, Prefix Options
 > }, therefore you can add bits in Prefix Options to say to which AF a
 > prefix belongs and since you want to be backward compatible you can use
 > the NU bit to exclude the prefix from IPv6 unicast AF ( A short draft
 > will be available soon to demonstrate that for multicast AF)
 >
 > This mean that the prefix LSA encoding is flexible enough to carry
 > prefixes of different lengths (IPv6, IPv4 or whatever), as long as we
 > can distinguish the correct AF, by say looking at some Prefix Options
 > bits

I am sure many of us already understand that. If you you suggesting
that you will carry v4 and v6 prefixes in the same intra-area-prefix
LSA, it is certainly doable with some amount of effort. But I still
don't see any significant benefit out of it. As far as carrying
unicast & multicast prefixes togather, I already counted that in in my
last mail.

 >
 > -> > D) need a mapping of instance-ID to AF which is user
 > ->dependent and can  > be prone to misconfiguration and
 > ->increase troubleshooting.
 > ->
 > ->Mapping AF to Instance shouldn't be that difficult. We could
 > ->reserve certain instance ids for the well known AFs.
 >
 > It is not sufficient to reserve some values, what happen if some of your
 > routers does not understand the given reserved values and you compute
 > the path through them ?

Since even the hello packet will contain the instance-id, the adj
shouldn't come up with a nbr who doesn't understand that instance-id
value. This is nothing but SIN, everything is separate.

 >
 > ->On th other hand, changes like LG election and
 > ->AF-Functionality LSA or AF-inter-area-router LSA add
 > ->significant complexity to code.
 >
 > Significant? I do not believe adding two new LSA add significant
 > complexity. Further those LSA will be used by _all_ AF and are
_generic_

It is not a question of just adding 2 more LSAs, it is a question of
what is involved in generating them and processing them. What other
parts of the code you are going to touch. What about LG election ?
And what other bandages are yet to come ?

 >
 > ->
 > ->As far as changes in ISIS are concerned, the changes there
 > ->are more equivalent to using instance-ids then the changes in
 > ->your draft.
 > ->In fact all they do is replicate TLVs, once for
 > ->each topology. So they end up advertising proportionately
 > ->more LSPs, CSNPS etc.
 >
 > Not really, the _same_ LSP is advertised _once_ to sets of neighbors and
 > a neighbor use whatever TLV it needs. There is no extra adjacency and
 > extra-flooding because of different AF neighbor

I already accepted in my last mail that there is no extra adjacecny.
But there definitely is extra flooding. The more TLVs you add, the
more LSP fragments you have and hence you have more to transmit.  If
for a node, there was only one LSP to advertise and it was
significantly small that adding more TLVs for other AFs didn't
require generating another one, then that is quite a degenerate case
and my topology is significanlty small and I should be hardly
worried with a gain of O(2).


 >
 > In fact in case of our proposal the LSA flooding is even more optimized
 > ( than ISIS) because type 1/2 are common to all AF further for prefix
 > information we can use the _same_  prefix LSA and add prefix specific AF
 > to the existing LSA so it is similar to adding TLV specific AF inside
 > LSP as in ISIS

Yes, you are more optimal than ISIS (or supposedlty) but this
optimality is achived in a significantly different way, i.e.
by adding new functionality into the protocol. While ISIS chose
to be simple and just replicate the TLVs, once for each AF.

My point is the ISIS way and multiple instance ids are far more
equivalent than your proposal. The only commonality between your
proposal and ISIS is saving on formation of adjacencies.

 >
 > ->The only saving is in the adjacency formation.
 >
 > You save also in maintaining LSDB multiple times, further saving in
 > adjacency leads to saving of flooding LSDB multiple times ( once for
 > each AF ) and decrease in packet processing

Not in ISIS. Yes, with your proposal but not siginificantly.


Quaizar

 >
 > ->The changes you are proposing in the draft are changes to the
 > ->protocol itself and are not a generic or a single high level
 > ->change which fixes everything in a clean and complete way.
 > ->The fear is in the unknown, i.e. further bandages which will
 > ->be needed.
 >
 > The way OSPFv3 was defined, it allows to separate topology information
 > from prefix information, further prefix LSA information are defined in a
 > flexible way which could be used for other AF
 >
 > Therefore the proposed draft leverage and optimize the current OSPFv3
 > allowing to integrate different AF within OSPFv3, the addition is 2 new
 > LSAs which are generic to all AF and not a big deal.
 >
 > I would like to ask WG to debate if they want to go with an integrated
 > approach or SIN, as OSPFv3 is in the initial deployment phase and a
 > decision need to be made.
 >
 > Sina


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 23 19:12:11 2003
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 TAA14747
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Jun 2003 19:12:11 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A2C8B6@cherry.ease.lsoft.com>; Mon, 23 Jun 2003 19:12:09 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46382923 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 23 Jun 2003 19:11:20 -0400
Received: from 195.207.101.240 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Mon, 23 Jun 2003 19:01:20 -0400
Received: from Bemail06.net.alcatel.be (bemail06.net.alcatel.be
          [138.203.144.83]) by bt0rjw.god.bel.alcatel.be (8.12.9/8.11.4) with
          ESMTP id h5NN0w3Y029247 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 24 Jun
          2003 01:01:16 +0200 (MEST)
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.11  |July
             24, 2002) at 06/24/2003 01:01:15
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Message-ID:  <OF10A3BEDB.44B219BA-ONC1256D4E.007E6E79-C1256D4E.007E6E7A@net.alcatel.be>
Date:         Tue, 24 Jun 2003 01:00:58 +0200
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Wim.Tavernier@ALCATEL.BE
Subject: Wim TAVERNIER/BE/ALCATEL is out of the office.
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

I will be out of the office from 23/06/2003 until 26/06/2003.

I will respond to your message when I return.


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 23 23:37:47 2003
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 XAA19882
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Jun 2003 23:37:46 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00A2CF97@cherry.ease.lsoft.com>; Mon, 23 Jun 2003 23:37:46 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46401915 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 23 Jun 2003 23:37:45 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Mon, 23 Jun 2003 23:37:43 -0400
Received: from redback.com (login002.redback.com [155.53.12.54]) by
          prattle.redback.com (Postfix) with ESMTP id 412557552A3; Mon, 23 Jun
          2003 20:37:42 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <LISTSERV%2003062208245157@PEACH.EASE.LSOFT.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EF7C6DB.10600@redback.com>
Date:         Mon, 23 Jun 2003 23:34:51 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Zero as ospfIfRetransInterval
Comments: To: Daniel Joyal <djoyal@nortelnetworks.com>
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Igor Miroshnik wrote:
> All,
>
> Can anybody clarify the physical sense of assigning ospfIfRetransInterval
> to zero? RFC1850 allows such an assignment.

I believe UpToMaxAge should range from 1..3600 rather than 0..3600.

Dan - can we change this in the MIB update without deprecating variables?

>
> Thanks
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 23 23:43:11 2003
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 XAA19996
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Jun 2003 23:43:11 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00A2CFC2@cherry.ease.lsoft.com>; Mon, 23 Jun 2003 23:43:12 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46403888 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 23 Jun 2003 23:43:11 -0400
Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Mon, 23 Jun 2003 23:43:11 -0400
Received: from smirtoraw2k03 (sjc-vpn3-406.cisco.com [10.21.65.150]) by
          fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h5O3hAT20653 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 23 Jun 2003 20:43:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Message-ID:  <000001c33a02$bb6d1660$f2ce7243@amer.cisco.com>
Date:         Mon, 23 Jun 2003 20:43:10 -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: Address Family Support in OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <200306232309.h5NN9Ye48201@fuinar.juniper.net>
Precedence: list
Content-Transfer-Encoding: 7bit

Quaizar,

I will avoid going through an endless discussion regarding SIN and
integrated approach optimization

Four comments though

1)
An integrated approach optimize the CPU usage, memory and network
bandwidth utilization which apparently is not your concerns.

2)
It is interesting how you make a believe that Integrated IS-IS is close
to SIN instance ID rather than our proposal. If ISIS had to implement
different instance (or using different process) for different AF then
how would you compare it to SIN?

The fact that you are having more information to transport which is a
_result_ of adding AF is irrelevant to the rapprochement that you are
making between ISIS and SIN instance ID of OSPFv3.

3)
Any optimization can lead to some degree of code complexity,  M-ISIS is
a good example of it.

Defining and processing two new LSA does not look complex to me, as far
LG election, it is pretty close to DR election algorithm but if that
bothers you that much there are other ways to fix it ( forcing the
router that is AF capable to become DR either manually or the router can
declare itself DR and win DR election )

4)
It is not sufficient to have separate instance ID, if a router does not
understand the reserved value for a AF but has the _same_ instance-ID (
router downgraded etc ) then how you make sure that the path is not
through this router ?


Sina


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 03:05:02 2003
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 DAA05770
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 03:04:56 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00A2D47C@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 3:03:55 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46417552 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 03:03:54 -0400
Received: from 192.51.44.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 24 Jun 2003 03:03:53 -0400
Received: from m6.gw.fujitsu.co.jp ([10.0.50.76]) by fgwmail7.fujitsu.co.jp
          (8.12.9/Fujitsu Gateway) id h5O73iM2022055 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 24 Jun 2003 16:03:44 +0900
          (envelope-from sasaki@soft.net.fujitsu.co.jp)
Received: from s4.gw.fujitsu.co.jp by m6.gw.fujitsu.co.jp (8.12.9/Fujitsu
          Domain Master) id h5O73hh1032276 for <OSPF@PEACH.EASE.LSOFT.COM>;
          Tue, 24 Jun 2003 16:03:43 +0900 (envelope-from
          sasaki@soft.net.fujitsu.co.jp)
Received: from incapgw1.fujitsu.co.jp (incapgw.fujitsu.co.jp [10.75.179.5]) by
          s4.gw.fujitsu.co.jp (8.12.9) id h5O73hOd008119 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 24 Jun 2003 16:03:43 +0900
          (envelope-from sasaki@soft.net.fujitsu.co.jp)
Received: from [45.0.8.144] (mogw2.gw.fujitsu.co.jp [10.75.179.52]) by
          incapgw1.fujitsu.co.jp (8.11.6p2/3.7W-0305) id h5O73g113866; Tue, 24
          Jun 2003 16:03:42 +0900 (JST)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.05.06
Message-ID:  <20030624160304.6E7A.SASAKI@soft.net.fujitsu.co.jp>
Date:         Tue, 24 Jun 2003 16:03:09 +0900
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Taisuke Sasaki <sasaki@SOFT.NET.FUJITSU.CO.JP>
Subject: OSPFv3 Point-to-Point interface
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

I have a question about how to advertise its own
point-to-point interface address in its Intra-Area-Prefix-LSAs.

Suppose that a Router A has a point-to-point link
and IPv6 address 3ffe:1::1/64 is assigned.

        point-to-point
  +---+  3ffe:1::/64  +---+
  | A +---------------+ B |
  +---+ ::1       ::2 +---+

I saw some OSPFv3 implementations that Router A advertised
its p2p interface address in an Intra-Area-Prefix-LSA as follows:

     PrefixLength = 128
     PrefixOptions = LA-bit
     Metric = 0
     Address Prefix = 3ffe:1::1

It's no problem from the viewpoint of Routing,
but is this implementation fully compliant with rfc2740 3.4.3.7?

My opinion is the next:
If IPv6 address 3ffe:1::1/128 is assigned to Router A's p2p
interface, it is OK.
But in this case, IPv6 prefix(/64) is assigned to its p2p
interface, so Router A should advertise its interface prefix
as follows:

     PrefixLength = 64
     PrefixOptions = 0
     Metric = 1 ;interface output cost
     Address Prefix = 3ffe:1::

regards.

---
taisuke sasaki


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 06:05:39 2003
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 GAA08854
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 06:05:38 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00A2D9CC@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 6:05:37 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46430321 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 06:05:35 -0400
Received: from 203.199.83.146 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Tue, 24 Jun 2003 06:05:31 -0400
Received: (qmail 8996 invoked by uid 510); 24 Jun 2003 10:05:27 -0000
Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 24 jun
          2003 10:05:27 -0000
MIME-Version: 1.0
Content-type: text/plain; format=flowed
Content-Disposition: inline
Message-ID:  <20030624100527.8995.qmail@webmail24.rediffmail.com>
Date:         Tue, 24 Jun 2003 10:05:27 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vivek Dubey <vivek_ospf@REDIFFMAIL.COM>
Subject: OSPFv3 - Editorial
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

If already taken care pls ignore.


2.1.  Protocol processing per-link, not per-subnet:

should generally be "relaced "
>replaced


2.7.  Packet format changes
Two option bits, the "R-bit" and the "V6-bit", ......
but diagrams belonging to another protocol family may be
forwarded

>datagrams

3.1.2.  The Interface Data structure
Interface ID
and the router-LSA originated by the router-LSA for...

>should be originated by the router for ....



thanks,
vivek
___________________________________________________
Get www. mycompany .com and 5 matching email ids.
Just Rs. 1499/ year.
Click here http://www.rediffmailpro.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 07:26:28 2003
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 HAA12092
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 07:26:27 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00A2DBC6@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 7:21:16 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46450319 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 07:21:15 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 24 Jun 2003 07:11:14 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id HAA11285; Tue, 24 Jun 2003 07:00:42
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200306241100.HAA11285@ietf.org>
Date:         Tue, 24 Jun 2003 07:00:42 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ospf-2547-dnbit-00.txt
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           : Using an LSA Options Bit to Prevent Looping in
                          BGP/MPLS IP VPNs
        Author(s)       : E. Rosen et al.
        Filename        : draft-ietf-ospf-2547-dnbit-00.txt
        Pages           : 6
        Date            : 2003-6-23

[VPN] describes a method by which a Service Provider (SP) may provide
an 'IP VPN' service to its customers.  In VPNs of that sort, a
Customer Edge (CE) Router and a Provider Edge Router become routing
peers, and the customer routes are sent to the SP.  BGP is then used
to carry the customer routes across the SP's backbone to other PE
routers, and the routes are then sent to other CE routers.  Since CE
routers and PE routers are routing peers, it is customary to run a
routing protocol between them.  [VPN] allows a number of different
PE-CE protocols.  If OSPF is used as the PE-CE routing protocol, the
PE must execute additional procedures not specified in [VPN]; these
procedures are specified in [OSPF-VPN].  These additional procedures
translate customer OSPF routes from a CE router into BGP routes.  The
BGP routes are sent to the other PE routers, which translate them
back into OSPF routes, and then distribute them to CE routers.
During this translation, some of the information needed to prevent
loops may be lost.  The procedures specified in this document remedy
this situation by specifying that one of the OSPF options bits be
used to ensure that when a VPN route is sent from a PE to a CE, the
route will be ignored by any PE which receives it back from a CE.

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

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-2547-dnbit-00.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-2547-dnbit-00.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:     <2003-6-23142537.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-2547-dnbit-00.txt

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

Content-Type: text/plain
Content-ID:     <2003-6-23142537.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 08:05:10 2003
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 IAA13073
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 08:05:10 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A2DCC0@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 8:05:09 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46452414 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 08:05:07 -0400
Received: from 47.129.242.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 24 Jun 2003 08:05:07 -0400
Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62])
          by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
          id h5OC54a28931; Tue, 24 Jun 2003 08:05:04 -0400 (EDT)
Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service
          (5.5.2653.19) id <NAFSKRA1>; Tue, 24 Jun 2003 08:05:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C33A48.D832C7AE"
Message-ID:  <6204FDDE129D364D8040A98BCCB290EF05DD8EF8@zbl6c004.corpeast.baynetworks.com>
Date:         Tue, 24 Jun 2003 08:05:03 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Daniel Joyal <djoyal@NORTELNETWORKS.COM>
Subject: Re: Zero as ospfIfRetransInterval
Comments: To: Acee Lindem <acee@redback.com>
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C33A48.D832C7AE
Content-Type: text/plain

You're not allowed to change the syntax unless
it's equivalent to the old syntax. So in this
case, we would need to deprecate/obsolete.

-Dan

> -----Original Message-----
> From: Acee Lindem [mailto:acee@redback.com]
> Sent: Monday, June 23, 2003 11:35 PM
> To: Mailing List; Joyal, Daniel [BL60:NP30:EXCH]
> Subject: Re: Zero as ospfIfRetransInterval
>
>
>
>
> Igor Miroshnik wrote:
> > All,
> >
> > Can anybody clarify the physical sense of assigning
> > ospfIfRetransInterval to zero? RFC1850 allows such an assignment.
>
> I believe UpToMaxAge should range from 1..3600 rather than 0..3600.
>
> Dan - can we change this in the MIB update without
> deprecating variables?
>
> >
> > Thanks
> >
>
>
> --
> Acee
>
>

------_=_NextPart_001_01C33A48.D832C7AE
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2656.31">
<TITLE>RE: Zero as ospfIfRetransInterval</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>You're not allowed to change the syntax unless</FONT>
<BR><FONT SIZE=2>it's equivalent to the old syntax. So in this</FONT>
<BR><FONT SIZE=2>case, we would need to deprecate/obsolete.</FONT>
</P>

<P><FONT SIZE=2>-Dan</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Acee Lindem [<A HREF="mailto:acee@redback.com">mailto:acee@redback.com</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, June 23, 2003 11:35 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Mailing List; Joyal, Daniel [BL60:NP30:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Zero as ospfIfRetransInterval</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Igor Miroshnik wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; All,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Can anybody clarify the physical sense of assigning </FONT>
<BR><FONT SIZE=2>&gt; &gt; ospfIfRetransInterval to zero? RFC1850 allows such an assignment.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I believe UpToMaxAge should range from 1..3600 rather than 0..3600.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dan - can we change this in the MIB update without </FONT>
<BR><FONT SIZE=2>&gt; deprecating variables?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Thanks</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -- </FONT>
<BR><FONT SIZE=2>&gt; Acee</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C33A48.D832C7AE--


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 08:51:47 2003
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 IAA14051
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 08:51:47 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00A2DD88@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 8:48:36 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46453595 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 08:48:35 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 24 Jun 2003 08:48:35 -0400
Received: from redback.com (login004.redback.com [155.53.12.57]) by
          prattle.redback.com (Postfix) with ESMTP id F1C647D6CA7; Tue, 24 Jun
          2003 05:48:33 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <6204FDDE129D364D8040A98BCCB290EF05DD8EF8@zbl6c004.corpeast.baynetworks.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EF847F2.1030907@redback.com>
Date:         Tue, 24 Jun 2003 08:45:38 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Zero as ospfIfRetransInterval
Comments: To: Daniel Joyal <djoyal@nortelnetworks.com>
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Dan,

Daniel Joyal wrote:
> You're not allowed to change the syntax unless
> it's equivalent to the old syntax.

Even if the old syntax doesn't match the protocol
specification?


> So in this
> case, we would need to deprecate/obsolete.

Then I don't think it is worth defining
new MIB variables given that ospfIfTransitDelay,
ospfIfRetransInterval, ospfVirtIfTransitDelay, and
ospfVirtIfRetransInterval have served us thus far.

Other opinions are welcome.

Thanks,
Acee

>
> -Dan
>
>  > -----Original Message-----
>  > From: Acee Lindem [mailto:acee@redback.com]
>  > Sent: Monday, June 23, 2003 11:35 PM
>  > To: Mailing List; Joyal, Daniel [BL60:NP30:EXCH]
>  > Subject: Re: Zero as ospfIfRetransInterval
>  >
>  >
>  >
>  >
>  > Igor Miroshnik wrote:
>  > > All,
>  > >
>  > > Can anybody clarify the physical sense of assigning
>  > > ospfIfRetransInterval to zero? RFC1850 allows such an assignment.
>  >
>  > I believe UpToMaxAge should range from 1..3600 rather than 0..3600.
>  >
>  > Dan - can we change this in the MIB update without
>  > deprecating variables?
>  >
>  > >
>  > > Thanks
>  > >
>  >
>  >
>  > --
>  > Acee
>  >
>  >
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 08:53:47 2003
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 IAA14145
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 08:53:47 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00A2DDFD@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 8:53:46 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46453774 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 08:53:45 -0400
Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Tue, 24 Jun 2003 08:53:45 -0400
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by
          motgate.mot.com (Motorola/Motgate) with ESMTP id h5OCrivg012331 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 24 Jun 2003 05:53:44 -0700 (MST)
Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by
          az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h5OCrh0J002153
          for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 24 Jun 2003 07:53:44 -0500
Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id
          <NNKYZB9L>; Tue, 24 Jun 2003 08:53:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328DD4547@india_exch.corp.mot.com>
Date:         Tue, 24 Jun 2003 08:55:15 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: Zero as ospfIfRetransInterval
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi Acee,

If we do not intend to define new variables, we may want to at least put the
limitation of 0, in the object description in the MIB.

Thanks,
Vishwas

-----Original Message-----
From: Acee Lindem [mailto:acee@REDBACK.COM]
Sent: Tuesday, June 24, 2003 18:16
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Zero as ospfIfRetransInterval


Hi Dan,

Daniel Joyal wrote:
> You're not allowed to change the syntax unless
> it's equivalent to the old syntax.

Even if the old syntax doesn't match the protocol
specification?


> So in this
> case, we would need to deprecate/obsolete.

Then I don't think it is worth defining
new MIB variables given that ospfIfTransitDelay,
ospfIfRetransInterval, ospfVirtIfTransitDelay, and
ospfVirtIfRetransInterval have served us thus far.

Other opinions are welcome.

Thanks,
Acee

>
> -Dan
>
>  > -----Original Message-----
>  > From: Acee Lindem [mailto:acee@redback.com]
>  > Sent: Monday, June 23, 2003 11:35 PM
>  > To: Mailing List; Joyal, Daniel [BL60:NP30:EXCH]
>  > Subject: Re: Zero as ospfIfRetransInterval
>  >
>  >
>  >
>  >
>  > Igor Miroshnik wrote:
>  > > All,
>  > >
>  > > Can anybody clarify the physical sense of assigning
>  > > ospfIfRetransInterval to zero? RFC1850 allows such an assignment.
>  >
>  > I believe UpToMaxAge should range from 1..3600 rather than 0..3600.
>  >
>  > Dan - can we change this in the MIB update without
>  > deprecating variables?
>  >
>  > >
>  > > Thanks
>  > >
>  >
>  >
>  > --
>  > Acee
>  >
>  >
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 08:55:51 2003
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 IAA14219
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 08:55:50 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00A2DD7A@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 8:55:50 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46453823 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 08:55:49 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 24 Jun 2003 08:55:44 -0400
Received: from redback.com (login004.redback.com [155.53.12.57]) by
          prattle.redback.com (Postfix) with ESMTP id 712B57D6CA7 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 24 Jun 2003 05:54:26 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <3EF74F8A.22F92D39@net.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EF84952.40803@redback.com>
Date:         Tue, 24 Jun 2003 08:51:30 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: doubt in Figure 5 of RFC 2328
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Mani Devarajan wrote:
> Hi all,
>
> In the figure 5 of rfc 2328 "The SPF tree for Router RT6",
> there is an extra node between N9 and RT9.
>
> Does that node mean something,or it has been added intentionally.
>
>                                               |   |
>                                            N9 o   o N7
>                                              /|
>                                             / |
>                         N11      RT9       /  |RT12
>                          o--------o-------o   o--------o H1
>                              3                |   10
>                                               |2
>                                               |
>                                               o N10

Hi Mani,

The unlabeled "o" has no significance in the OSPF topology. If we
ever respin RFC 2328 it would be better if it were removed.

Thanks,
--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 09:05:44 2003
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 JAA14708
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 09:05:43 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A2DD35@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 9:05:38 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46455352 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 09:04:27 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 24 Jun 2003 09:04:27 -0400
Received: from redback.com (login004.redback.com [155.53.12.57]) by
          prattle.redback.com (Postfix) with ESMTP id D00617D6CB1 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 24 Jun 2003 06:04:25 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <E7E13AAF2F3ED41197C100508BD6A328DD4547@india_exch.corp.mot.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EF84BA9.6090701@redback.com>
Date:         Tue, 24 Jun 2003 09:01:29 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Zero as ospfIfRetransInterval
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Manral, Vishwas wrote:
> Hi Acee,
>
> If we do not intend to define new variables, we may want to at least put the
> limitation of 0, in the object description in the MIB.

Hi Vishwas,

That sounds like a good idea since any implementation that allows
write access to set the variables to 0 is broken.

Thanks,
Acee

>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Acee Lindem [mailto:acee@REDBACK.COM]
> Sent: Tuesday, June 24, 2003 18:16
> To: OSPF@PEACH.EASE.LSOFT.COM
> Subject: Re: Zero as ospfIfRetransInterval
>
>
> Hi Dan,
>
> Daniel Joyal wrote:
>
>>You're not allowed to change the syntax unless
>>it's equivalent to the old syntax.
>
>
> Even if the old syntax doesn't match the protocol
> specification?
>
>
>
>>So in this
>>case, we would need to deprecate/obsolete.
>
>
> Then I don't think it is worth defining
> new MIB variables given that ospfIfTransitDelay,
> ospfIfRetransInterval, ospfVirtIfTransitDelay, and
> ospfVirtIfRetransInterval have served us thus far.
>
> Other opinions are welcome.
>
> Thanks,
> Acee
>
>
>>-Dan
>>
>> > -----Original Message-----
>> > From: Acee Lindem [mailto:acee@redback.com]
>> > Sent: Monday, June 23, 2003 11:35 PM
>> > To: Mailing List; Joyal, Daniel [BL60:NP30:EXCH]
>> > Subject: Re: Zero as ospfIfRetransInterval
>> >
>> >
>> >
>> >
>> > Igor Miroshnik wrote:
>> > > All,
>> > >
>> > > Can anybody clarify the physical sense of assigning
>> > > ospfIfRetransInterval to zero? RFC1850 allows such an assignment.
>> >
>> > I believe UpToMaxAge should range from 1..3600 rather than 0..3600.
>> >
>> > Dan - can we change this in the MIB update without
>> > deprecating variables?
>> >
>> > >
>> > > Thanks
>> > >
>> >
>> >
>> > --
>> > Acee
>> >
>> >
>>
>
>
> --
> Acee
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 09:10:39 2003
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 JAA14949
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 09:10:39 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00A2DD74@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 9:10:39 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46458054 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 09:10:38 -0400
Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Tue, 24 Jun 2003 09:10:38 -0400
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by
          motgate.mot.com (Motorola/Motgate) with ESMTP id h5ODAbvg023216 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 24 Jun 2003 06:10:37 -0700 (MST)
Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by
          az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h5ODAZoT016836
          for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 24 Jun 2003 08:10:36 -0500
Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id
          <NNKYZB0P>; Tue, 24 Jun 2003 09:10:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328DD454A@india_exch.corp.mot.com>
Date:         Tue, 24 Jun 2003 09:11:44 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: OSPFv3 - Editorial
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi Vivek,

I have seen the typos before, but they don't seem them on the errata page
http://www.rfc-editor.org/errata.html .

You can send the corrections to rfc-editor@rfc-editor.org

Thanks,
Vishwas

-----Original Message-----
From: Vivek Dubey [mailto:vivek_ospf@REDIFFMAIL.COM]
Sent: Tuesday, June 24, 2003 15:35
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: OSPFv3 - Editorial


If already taken care pls ignore.


2.1.  Protocol processing per-link, not per-subnet:

should generally be "relaced "
>replaced


2.7.  Packet format changes
Two option bits, the "R-bit" and the "V6-bit", ......
but diagrams belonging to another protocol family may be
forwarded

>datagrams

3.1.2.  The Interface Data structure
Interface ID
and the router-LSA originated by the router-LSA for...

>should be originated by the router for ....



thanks,
vivek
___________________________________________________
Get www. mycompany .com and 5 matching email ids.
Just Rs. 1499/ year.
Click here http://www.rediffmailpro.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 09:25:51 2003
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 JAA15298
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 09:25:36 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00A2DDDE@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 9:25:34 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46459075 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 09:25:33 -0400
Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Tue, 24 Jun 2003 09:25:33 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <EB5FFC72F183D411B38200062957342903ED6080@r2d2.axiowave.com>
Date:         Tue, 24 Jun 2003 09:25:29 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Jeff Parker <jparker@AXIOWAVE.COM>
Subject: Re: Zero as ospfIfRetransInterval
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

You're not allowed to change the syntax unless
it's equivalent to the old syntax. So in this
case, we would need to deprecate/obsolete.
-Dan

Dan -
        You are such a wet blanket


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 09:27:07 2003
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 JAA15359
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 09:27:06 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00A2DDFA@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 9:27:05 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46459135 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 09:27:04 -0400
Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Tue, 24 Jun 2003 09:27:04 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <EB5FFC72F183D411B3820006295734290372D3AB@r2d2.axiowave.com>
Date:         Tue, 24 Jun 2003 09:27:01 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Greg Mirsky <gmirsky@AXIOWAVE.COM>
Subject: Re: Zero as ospfIfRetransInterval
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Jeff,
I don't think the whole list has to know that ;)

Gregory Mirsky             Axiowave Networks, Inc.
SW Engineer                200 Nickerson Road
Phone: (774)348-4664       Marlborough, MA 01752
E-mail: gmirsky@axiowave.com
--------------------------------------------
Adding manpower to a late SW project makes it later


-----Original Message-----
From: Jeff Parker [mailto:jparker@AXIOWAVE.COM]
Sent: Tuesday, June 24, 2003 9:25 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Zero as ospfIfRetransInterval


You're not allowed to change the syntax unless
it's equivalent to the old syntax. So in this
case, we would need to deprecate/obsolete.
-Dan

Dan -
        You are such a wet blanket


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 16:45:49 2003
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 QAA10444
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 16:45:49 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A2EDE5@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 16:45:18 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46500979 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 16:45:16 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 24 Jun 2003 16:35:16 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id QAA09793; Tue, 24 Jun 2003 16:31:17
          -0400 (EDT)
Message-ID:  <200306242031.QAA09793@ietf.org>
Date:         Tue, 24 Jun 2003 16:31:17 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: The IESG <iesg-secretary@ietf.org>
Subject: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

The IESG has received a request from the Open Shortest Path First
IGP Working Group to consider Traffic Engineering Extensions to OSPF
Version 2 <draft-katz-yeung-ospf-traffic-10.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2003-7-8.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-10.txt


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 21:38:55 2003
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 VAA02093
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 21:38:39 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00A2F58A@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 19:33:24 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46515169 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 19:33:23 -0400
Received: from 203.14.180.204 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Tue, 24 Jun 2003 19:33:22 -0400
Received: (qmail 26682 invoked from network); 24 Jun 2003 23:51:35 -0000
Received: from mailmon2.aapt.com.au (172.19.200.193) by 0 with SMTP; 24 Jun
          2003 23:51:35 -0000
Received: from QMAIL-Message_Server by aapt-gwia2.aapt.com.au with
          Novell_GroupWise; Wed, 25 Jun 2003 09:33:20 +1000
X-Mailer: Novell GroupWise 5.5.4
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-ID:  <sef96c60.089@aapt-gwia2.aapt.com.au>
Date:         Wed, 25 Jun 2003 09:32:50 +1000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Paresh Khatri <pkhatri@AAPT.COM.AU>
Subject: Clarification on Cisco OSPF network types
Comments: To: OSPF@.EASE.LSOFT.COM
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

Hi all,

Appreciate if someone could clarify how the various Cisco OSPF modes for =
NBMA networks work.

The command "ip ospf network {broadcast | non-broadcast | {point-to-multipo=
int [non-broadcast] | point-to-point}}" allows you to set an OSPF network =
mode.

I would like to know:
1.  How OSPF packets are transmitted on each of these modes - unicast, =
multicast etc ?
2.  How are neighbors discovered ? =20

All responses appreciated.

Regards,
Paresh.


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 21:56:17 2003
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 VAA02557
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 21:56:17 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00A2F93A@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 21:56:18 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46523337 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 21:56:16 -0400
Received: from 203.14.180.204 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Tue, 24 Jun 2003 21:56:16 -0400
Received: (qmail 5483 invoked from network); 25 Jun 2003 02:14:28 -0000
Received: from mailmon2.aapt.com.au (172.19.200.193) by 0 with SMTP; 25 Jun
          2003 02:14:28 -0000
Received: from QMAIL-Message_Server by aapt-gwia2.aapt.com.au with
          Novell_GroupWise; Wed, 25 Jun 2003 11:56:14 +1000
X-Mailer: Novell GroupWise 5.5.4
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-ID:  <sef98dde.030@aapt-gwia2.aapt.com.au>
Date:         Wed, 25 Jun 2003 11:56:06 +1000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Paresh Khatri <pkhatri@AAPT.COM.AU>
Subject: Re: Clarification on Cisco OSPF network types
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

Thanks you Sina,

This has been very useful.

Regards,
Paresh.

>>> sina@CISCO.COM 06/25/03 11:15AM >>>
Paresh,

->Hi all,
->
->Appreciate if someone could clarify how the various Cisco
->OSPF modes for NBMA networks work.
->
->The command "ip ospf network {broadcast | non-broadcast |
->{point-to-multipoint [non-broadcast] | point-to-point}}"
->allows you to set an OSPF network mode.
->
->I would like to know:
->1.  How OSPF packets are transmitted on each of these modes -
->unicast, multicast etc ?


network \packet type |type 1 | type 2| type 3| type 4| type 5
---------------------|-------|-------|-------|-------|------
p2p                  |  M    |   M   |   M   |   M   |  M
---------------------|-------|-------|-------|-------|------
p2mp non-broadcast   |  U    |   U   |   U   |   U   |  U
---------------------|-------|-------|-------|-------|------
p2mp broadcast       |  M    |   U   |   U   |   U   |  U
---------------------|-------|-------|-------|-------|------
NBMA                 |  U    |   U   |   U   |   U   |  U
---------------------|-------|-------|-------|-------|------
Broadcast            |  M    |   U   |   U   |M /MD *|  M/MD *


U  : unicast ( neighbor IP address )
M  : Multicast AllSPFRouters (224.0.0.5)
MD : Multicast AllDRouters ( 224.0.0.4 )

* For broadcast network, if Interface FSM is DR /BDR type 4 & 5 are sent
to M ( 224.0.0.5) otherwise it is sent to MD ( 224.0.0.4 )


->2.  How are neighbors discovered ?

When the packet ( actually Hello ) is sent to unicast IP address a
manual configuration is required (except for VL which is found
dynamically once there is an intra-area path to the other end-point )

If Hello is sent to Multicast AllSPFRouters address and the link layer
has the broadcast capability ( or packet can be replicated to sent to
different VC ) then the neighbor discovery is dynamic

Sina

->
->All responses appreciated.
->
->Regards,
->Paresh.
->


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 22:27:22 2003
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 VAA02108
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 21:38:55 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A2F84B@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 21:19:57 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46522359 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 21:19:56 -0400
Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 24 Jun 2003 21:19:56 -0400
Received: from smirtoraw2k03 (sjc-vpn3-459.cisco.com [10.21.65.203]) by
          fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h5P1JtT13922 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 24 Jun 2003 18:19:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
Message-ID:  <000401c33ab7$e2ed6220$f2ce7243@amer.cisco.com>
Date:         Tue, 24 Jun 2003 18:19:51 -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: Clarification on Cisco OSPF network types
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <000301c33ab7$59294950$f2ce7243@amer.cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

->MD : Multicast AllDRouters ( 224.0.0.4 )

I meant, 224.0.0.6


From owner-ospf@PEACH.EASE.LSOFT.COM  Tue Jun 24 22:27:22 2003
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 VAA02097
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Jun 2003 21:38:55 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00A2F69E@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 21:16:09 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46522281 for OSPF@PEACH.EASE.LSOFT.COM;
          Tue, 24 Jun 2003 21:16:06 -0400
Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Tue, 24 Jun 2003 21:16:05 -0400
Received: from smirtoraw2k03 (sjc-vpn3-459.cisco.com [10.21.65.203]) by
          fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h5P1FxT09017 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 24 Jun 2003 18:15:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
Message-ID:  <000301c33ab7$59294950$f2ce7243@amer.cisco.com>
Date:         Tue, 24 Jun 2003 18:15:59 -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: Clarification on Cisco OSPF network types
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <sef96c60.089@aapt-gwia2.aapt.com.au>
Precedence: list
Content-Transfer-Encoding: 7bit

Paresh,

->Hi all,
->
->Appreciate if someone could clarify how the various Cisco
->OSPF modes for NBMA networks work.
->
->The command "ip ospf network {broadcast | non-broadcast |
->{point-to-multipoint [non-broadcast] | point-to-point}}"
->allows you to set an OSPF network mode.
->
->I would like to know:
->1.  How OSPF packets are transmitted on each of these modes -
->unicast, multicast etc ?


network \packet type |type 1 | type 2| type 3| type 4| type 5
---------------------|-------|-------|-------|-------|------
p2p                  |  M    |   M   |   M   |   M   |  M
---------------------|-------|-------|-------|-------|------
p2mp non-broadcast   |  U    |   U   |   U   |   U   |  U
---------------------|-------|-------|-------|-------|------
p2mp broadcast       |  M    |   U   |   U   |   U   |  U
---------------------|-------|-------|-------|-------|------
NBMA                 |  U    |   U   |   U   |   U   |  U
---------------------|-------|-------|-------|-------|------
Broadcast            |  M    |   U   |   U   |M /MD *|  M/MD *


U  : unicast ( neighbor IP address )
M  : Multicast AllSPFRouters (224.0.0.5)
MD : Multicast AllDRouters ( 224.0.0.4 )

* For broadcast network, if Interface FSM is DR /BDR type 4 & 5 are sent
to M ( 224.0.0.5) otherwise it is sent to MD ( 224.0.0.4 )


->2.  How are neighbors discovered ?

When the packet ( actually Hello ) is sent to unicast IP address a
manual configuration is required (except for VL which is found
dynamically once there is an intra-area path to the other end-point )

If Hello is sent to Multicast AllSPFRouters address and the link layer
has the broadcast capability ( or packet can be replicated to sent to
different VC ) then the neighbor discovery is dynamic

Sina

->
->All responses appreciated.
->
->Regards,
->Paresh.
->


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 25 11:23:50 2003
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 LAA15156
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 Jun 2003 11:23:49 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00A312C8@cherry.ease.lsoft.com>; Wed, 25 Jun 2003 11:20:13 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46593686 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 25 Jun 2003 11:20:05 -0400
Received: from 12.129.211.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Wed, 25 Jun 2003 11:10:05 -0400
Received: from [65.211.67.100] (helo=GraIyMage.com) by host19.ipowerweb.com
          with asmtp (Exim 3.36 #1) id 19VBu5-0001Pt-00; Wed, 25 Jun 2003
          08:09:45 -0700
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
References: <E7E13AAF2F3ED41197C100508BD6A328DD4547@india_exch.corp.mot.com>
            <3EF84BA9.6090701@redback.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
             please include it with any abuse report
X-AntiAbuse: Primary Hostname - host19.ipowerweb.com
X-AntiAbuse: Original Domain - peach.ease.lsoft.com
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - graiymage.com
Message-ID:  <3EF9BA41.8370DC42@GraIyMage.com>
Date:         Wed, 25 Jun 2003 11:05:37 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Eric Gray <ewgray@GRAIYMAGE.COM>
Subject: Re: Zero as ospfIfRetransInterval
Comments: To: Acee Lindem <acee@redback.com>
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Acee,

    Why would it be wrong to set a retransmit interval to zero?  Usually,
setting a retransmit interval to zero would have the special meaning that
retransmission does not occur (i.e. - the interval is infinite).  Is that not
an intended meaning in this case?

Acee Lindem wrote:

> Manral, Vishwas wrote:
> > Hi Acee,
> >
> > If we do not intend to define new variables, we may want to at least put the
> > limitation of 0, in the object description in the MIB.
>
> Hi Vishwas,
>
> That sounds like a good idea since any implementation that allows
> write access to set the variables to 0 is broken.
>
> Thanks,
> Acee
>
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Acee Lindem [mailto:acee@REDBACK.COM]
> > Sent: Tuesday, June 24, 2003 18:16
> > To: OSPF@PEACH.EASE.LSOFT.COM
> > Subject: Re: Zero as ospfIfRetransInterval
> >
> >
> > Hi Dan,
> >
> > Daniel Joyal wrote:
> >
> >>You're not allowed to change the syntax unless
> >>it's equivalent to the old syntax.
> >
> >
> > Even if the old syntax doesn't match the protocol
> > specification?
> >
> >
> >
> >>So in this
> >>case, we would need to deprecate/obsolete.
> >
> >
> > Then I don't think it is worth defining
> > new MIB variables given that ospfIfTransitDelay,
> > ospfIfRetransInterval, ospfVirtIfTransitDelay, and
> > ospfVirtIfRetransInterval have served us thus far.
> >
> > Other opinions are welcome.
> >
> > Thanks,
> > Acee
> >
> >
> >>-Dan
> >>
> >> > -----Original Message-----
> >> > From: Acee Lindem [mailto:acee@redback.com]
> >> > Sent: Monday, June 23, 2003 11:35 PM
> >> > To: Mailing List; Joyal, Daniel [BL60:NP30:EXCH]
> >> > Subject: Re: Zero as ospfIfRetransInterval
> >> >
> >> >
> >> >
> >> >
> >> > Igor Miroshnik wrote:
> >> > > All,
> >> > >
> >> > > Can anybody clarify the physical sense of assigning
> >> > > ospfIfRetransInterval to zero? RFC1850 allows such an assignment.
> >> >
> >> > I believe UpToMaxAge should range from 1..3600 rather than 0..3600.
> >> >
> >> > Dan - can we change this in the MIB update without
> >> > deprecating variables?
> >> >
> >> > >
> >> > > Thanks
> >> > >
> >> >
> >> >
> >> > --
> >> > Acee
> >> >
> >> >
> >>
> >
> >
> > --
> > Acee
> >
>
> --
> Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Wed Jun 25 13:06:09 2003
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 NAA21421
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 Jun 2003 13:06:08 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00A3173C@cherry.ease.lsoft.com>; Wed, 25 Jun 2003 13:06:09 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46608560 for OSPF@PEACH.EASE.LSOFT.COM;
          Wed, 25 Jun 2003 13:06:08 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Wed, 25 Jun 2003 13:06:08 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id BCAD579EA80; Wed, 25 Jun
          2003 10:06:03 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <E7E13AAF2F3ED41197C100508BD6A328DD4547@india_exch.corp.mot.com>
            <3EF84BA9.6090701@redback.com> <3EF9BA41.8370DC42@GraIyMage.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EF9D5BC.4030805@redback.com>
Date:         Wed, 25 Jun 2003 13:02:52 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Zero as ospfIfRetransInterval
Comments: To: ewgray@GraIyMage.com
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Eric Gray wrote:
> Acee,
>
>     Why would it be wrong to set a retransmit interval to zero?  Usually,
> setting a retransmit interval to zero would have the special meaning that
> retransmission does not occur (i.e. - the interval is infinite).  Is that not
> an intended meaning in this case?

Nope - not retransmitting would make the flooding unreliable and
would violate the base protocol specification (RFC 2328).

>
> Acee Lindem wrote:
>
>
>>Manral, Vishwas wrote:
>>
>>>Hi Acee,
>>>
>>>If we do not intend to define new variables, we may want to at least put the
>>>limitation of 0, in the object description in the MIB.
>>
>>Hi Vishwas,
>>
>>That sounds like a good idea since any implementation that allows
>>write access to set the variables to 0 is broken.
>>
>>Thanks,
>>Acee
>>
>>
>>>Thanks,
>>>Vishwas
>>>
>>>-----Original Message-----
>>>From: Acee Lindem [mailto:acee@REDBACK.COM]
>>>Sent: Tuesday, June 24, 2003 18:16
>>>To: OSPF@PEACH.EASE.LSOFT.COM
>>>Subject: Re: Zero as ospfIfRetransInterval
>>>
>>>
>>>Hi Dan,
>>>
>>>Daniel Joyal wrote:
>>>
>>>
>>>>You're not allowed to change the syntax unless
>>>>it's equivalent to the old syntax.
>>>
>>>
>>>Even if the old syntax doesn't match the protocol
>>>specification?
>>>
>>>
>>>
>>>
>>>>So in this
>>>>case, we would need to deprecate/obsolete.
>>>
>>>
>>>Then I don't think it is worth defining
>>>new MIB variables given that ospfIfTransitDelay,
>>>ospfIfRetransInterval, ospfVirtIfTransitDelay, and
>>>ospfVirtIfRetransInterval have served us thus far.
>>>
>>>Other opinions are welcome.
>>>
>>>Thanks,
>>>Acee
>>>
>>>
>>>
>>>>-Dan
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Acee Lindem [mailto:acee@redback.com]
>>>>>Sent: Monday, June 23, 2003 11:35 PM
>>>>>To: Mailing List; Joyal, Daniel [BL60:NP30:EXCH]
>>>>>Subject: Re: Zero as ospfIfRetransInterval
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Igor Miroshnik wrote:
>>>>>
>>>>>>All,
>>>>>>
>>>>>>Can anybody clarify the physical sense of assigning
>>>>>>ospfIfRetransInterval to zero? RFC1850 allows such an assignment.
>>>>>
>>>>>I believe UpToMaxAge should range from 1..3600 rather than 0..3600.
>>>>>
>>>>>Dan - can we change this in the MIB update without
>>>>>deprecating variables?
>>>>>
>>>>>
>>>>>>Thanks
>>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>Acee
>>>>>
>>>>>
>>>>
>>>
>>>--
>>>Acee
>>>
>>
>>--
>>Acee
>
>
>
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 26 04:15:39 2003
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 EAA11790
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 26 Jun 2003 04:15:39 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00A339CE@cherry.ease.lsoft.com>; Thu, 26 Jun 2003 4:13:48 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46684652 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 26 Jun 2003 04:13:38 -0400
Received: from 194.138.158.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Thu, 26 Jun 2003 04:03:38 -0400
Received: from blues.mchh.siemens.de ([139.21.204.206]) by
          gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA25877 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 26 Jun 2003 10:03:36 +0200 (MET DST)
Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de
          [139.21.200.58]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id
          KAA01019 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 26 Jun 2003 10:02:35
          +0200 (MET DST)
Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2653.19)
          id <NTWNRPFP>; Thu, 26 Jun 2003 10:03:06 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID:  <47D260E84215734F81779E8A50BE9B376560BC@mchh2a4e.mchh.siemens.de>
Date:         Thu, 26 Jun 2003 10:03:05 +0200
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Schrodi Karl <karl.schrodi@SIEMENS.COM>
Subject: AW: Zero as ospfIfRetransInterval
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

Hi Acee,

I fully understand that retransmission is mandatory - but does it =
really make sense to have a retransmission interval of zero? =
Wouldn=C2=B4t it be like some kind of a DoS attack against yourself and =
your neighbour(s)?

Well, probably nobody reasonably will set this interval to zero - but =
...

I would prefer something like the previous proposal of Vishwas, i.e. =
putting a limitation in the object description in the MIB.

Regards
Karl


-----Urspr=C3=BCngliche Nachricht-----
Von: Acee Lindem [mailto:acee@REDBACK.COM]
Gesendet: Mittwoch, 25. Juni 2003 19:03
An: OSPF@PEACH.EASE.LSOFT.COM
Betreff: Re: Zero as ospfIfRetransInterval


Eric Gray wrote:
> Acee,
>
>     Why would it be wrong to set a retransmit interval to zero?  =
Usually,
> setting a retransmit interval to zero would have the special meaning =
that
> retransmission does not occur (i.e. - the interval is infinite).  Is =
that not
> an intended meaning in this case?

Nope - not retransmitting would make the flooding unreliable and
would violate the base protocol specification (RFC 2328).

>
> Acee Lindem wrote:
>
>
>>Manral, Vishwas wrote:
>>
>>>Hi Acee,
>>>
>>>If we do not intend to define new variables, we may want to at least =
put the
>>>limitation of 0, in the object description in the MIB.
>>
>>Hi Vishwas,
>>
>>That sounds like a good idea since any implementation that allows
>>write access to set the variables to 0 is broken.
>>
>>Thanks,
>>Acee
>>
>>
>>>Thanks,
>>>Vishwas
>>>
>>>-----Original Message-----
>>>From: Acee Lindem [mailto:acee@REDBACK.COM]
>>>Sent: Tuesday, June 24, 2003 18:16
>>>To: OSPF@PEACH.EASE.LSOFT.COM
>>>Subject: Re: Zero as ospfIfRetransInterval
>>>
>>>
>>>Hi Dan,
>>>
>>>Daniel Joyal wrote:
>>>
>>>
>>>>You're not allowed to change the syntax unless
>>>>it's equivalent to the old syntax.
>>>
>>>
>>>Even if the old syntax doesn't match the protocol
>>>specification?
>>>
>>>
>>>
>>>
>>>>So in this
>>>>case, we would need to deprecate/obsolete.
>>>
>>>
>>>Then I don't think it is worth defining
>>>new MIB variables given that ospfIfTransitDelay,
>>>ospfIfRetransInterval, ospfVirtIfTransitDelay, and
>>>ospfVirtIfRetransInterval have served us thus far.
>>>
>>>Other opinions are welcome.
>>>
>>>Thanks,
>>>Acee
>>>
>>>
>>>
>>>>-Dan
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Acee Lindem [mailto:acee@redback.com]
>>>>>Sent: Monday, June 23, 2003 11:35 PM
>>>>>To: Mailing List; Joyal, Daniel [BL60:NP30:EXCH]
>>>>>Subject: Re: Zero as ospfIfRetransInterval
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Igor Miroshnik wrote:
>>>>>
>>>>>>All,
>>>>>>
>>>>>>Can anybody clarify the physical sense of assigning
>>>>>>ospfIfRetransInterval to zero? RFC1850 allows such an assignment.
>>>>>
>>>>>I believe UpToMaxAge should range from 1..3600 rather than =
0..3600.
>>>>>
>>>>>Dan - can we change this in the MIB update without
>>>>>deprecating variables?
>>>>>
>>>>>
>>>>>>Thanks
>>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>Acee
>>>>>
>>>>>
>>>>
>>>
>>>--
>>>Acee
>>>
>>
>>--
>>Acee
>
>
>
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 26 08:43:55 2003
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 IAA20365
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 26 Jun 2003 08:43:54 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00A33DB0@cherry.ease.lsoft.com>; Thu, 26 Jun 2003 8:43:47 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46706841 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 26 Jun 2003 08:43:45 -0400
Received: from 129.188.136.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Thu, 26 Jun 2003 08:43:02 -0400
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by
          ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h5QCh2G9018890 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 26 Jun 2003 05:43:02 -0700 (MST)
Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by
          il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h5QCh0SR020936
          for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 26 Jun 2003 07:43:00 -0500
Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id
          <NNKYZF24>; Thu, 26 Jun 2003 08:42:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328DD456F@india_exch.corp.mot.com>
Date:         Thu, 26 Jun 2003 08:44:30 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: Zero as ospfIfRetransInterval
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

Hi folks,

Some similar thoughts.

1. RFC2328 says that: -

    InfTransDelay
        The estimated number of seconds it takes to transmit a Link
        State Update Packet over this interface.  LSAs contained in the
        Link State Update packet will have their age incremented by =
this
        amount before transmission.  This value should take into =
account
        transmission and propagation delays; it must be greater than
        zero.

MIB allows it to be 0.

   ospfIfTransitDelay OBJECT-TYPE=20
         SYNTAX       UpToMaxAge=20
         MAX-ACCESS   read-create=20
         STATUS       current=20
         DESCRIPTION=20
            "The estimated number of seconds it takes to=20
            transmit a link state update packet over this=20
            interface."=20
         DEFVAL { 1 }=20
         ::=3D { ospfIfEntry 7 }=20
=20
2. Also what would a value of 0 for RestartInterval mean. Though it =
would
not create a problem.

3. Besides what would a value greater than 1800 mean for
RetransmitInterval(no problem caused by it though). May be the limit =
could
be RefreshInterval.=20

I will change these in the OSPFv3 MIB atleast.

Thanks,
Vishwas

-----Original Message-----
From: Schrodi Karl [mailto:karl.schrodi@SIEMENS.COM]
Sent: Thursday, June 26, 2003 13:33
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: AW: Zero as ospfIfRetransInterval


Hi Acee,

I fully understand that retransmission is mandatory - but does it =
really
make sense to have a retransmission interval of zero? Wouldn=C2=B4t it =
be like
some kind of a DoS attack against yourself and your neighbour(s)?

Well, probably nobody reasonably will set this interval to zero - but =
...

I would prefer something like the previous proposal of Vishwas, i.e. =
putting
a limitation in the object description in the MIB.

Regards
Karl


-----Urspr=C3=BCngliche Nachricht-----
Von: Acee Lindem [mailto:acee@REDBACK.COM]
Gesendet: Mittwoch, 25. Juni 2003 19:03
An: OSPF@PEACH.EASE.LSOFT.COM
Betreff: Re: Zero as ospfIfRetransInterval


Eric Gray wrote:
> Acee,
>
>     Why would it be wrong to set a retransmit interval to zero?  =
Usually,
> setting a retransmit interval to zero would have the special meaning =
that
> retransmission does not occur (i.e. - the interval is infinite).  Is =
that
not
> an intended meaning in this case?

Nope - not retransmitting would make the flooding unreliable and
would violate the base protocol specification (RFC 2328).

>
> Acee Lindem wrote:
>
>
>>Manral, Vishwas wrote:
>>
>>>Hi Acee,
>>>
>>>If we do not intend to define new variables, we may want to at least =
put
the
>>>limitation of 0, in the object description in the MIB.
>>
>>Hi Vishwas,
>>
>>That sounds like a good idea since any implementation that allows
>>write access to set the variables to 0 is broken.
>>
>>Thanks,
>>Acee
>>
>>
>>>Thanks,
>>>Vishwas
>>>
>>>-----Original Message-----
>>>From: Acee Lindem [mailto:acee@REDBACK.COM]
>>>Sent: Tuesday, June 24, 2003 18:16
>>>To: OSPF@PEACH.EASE.LSOFT.COM
>>>Subject: Re: Zero as ospfIfRetransInterval
>>>
>>>
>>>Hi Dan,
>>>
>>>Daniel Joyal wrote:
>>>
>>>
>>>>You're not allowed to change the syntax unless
>>>>it's equivalent to the old syntax.
>>>
>>>
>>>Even if the old syntax doesn't match the protocol
>>>specification?
>>>
>>>
>>>
>>>
>>>>So in this
>>>>case, we would need to deprecate/obsolete.
>>>
>>>
>>>Then I don't think it is worth defining
>>>new MIB variables given that ospfIfTransitDelay,
>>>ospfIfRetransInterval, ospfVirtIfTransitDelay, and
>>>ospfVirtIfRetransInterval have served us thus far.
>>>
>>>Other opinions are welcome.
>>>
>>>Thanks,
>>>Acee
>>>
>>>
>>>
>>>>-Dan
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Acee Lindem [mailto:acee@redback.com]
>>>>>Sent: Monday, June 23, 2003 11:35 PM
>>>>>To: Mailing List; Joyal, Daniel [BL60:NP30:EXCH]
>>>>>Subject: Re: Zero as ospfIfRetransInterval
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Igor Miroshnik wrote:
>>>>>
>>>>>>All,
>>>>>>
>>>>>>Can anybody clarify the physical sense of assigning
>>>>>>ospfIfRetransInterval to zero? RFC1850 allows such an assignment.
>>>>>
>>>>>I believe UpToMaxAge should range from 1..3600 rather than =
0..3600.
>>>>>
>>>>>Dan - can we change this in the MIB update without
>>>>>deprecating variables?
>>>>>
>>>>>
>>>>>>Thanks
>>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>Acee
>>>>>
>>>>>
>>>>
>>>
>>>--
>>>Acee
>>>
>>
>>--
>>Acee
>
>
>
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Thu Jun 26 10:17:32 2003
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 KAA27350
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 26 Jun 2003 10:17:30 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00A34118@cherry.ease.lsoft.com>; Thu, 26 Jun 2003 10:17:24 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46716084 for OSPF@PEACH.EASE.LSOFT.COM;
          Thu, 26 Jun 2003 10:17:22 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Thu, 26 Jun 2003 10:16:22 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id 2B513D9200 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 26 Jun 2003 07:16:21 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <E7E13AAF2F3ED41197C100508BD6A328DD456F@india_exch.corp.mot.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID:  <3EFB004E.7010605@redback.com>
Date:         Thu, 26 Jun 2003 10:16:46 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Zero as ospfIfRetransInterval
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit

Hi Vishwas,

Manral, Vishwas wrote:
> Hi folks,
>
> Some similar thoughts.
>
> 1. RFC2328 says that: -
>
>     InfTransDelay
>         The estimated number of seconds it takes to transmit a Link
>         State Update Packet over this interface.  LSAs contained in the
>         Link State Update packet will have their age incremented by this
>         amount before transmission.  This value should take into account
>         transmission and propagation delays; it must be greater than
>         zero.
>
> MIB allows it to be 0.
>
>    ospfIfTransitDelay OBJECT-TYPE
>          SYNTAX       UpToMaxAge
>          MAX-ACCESS   read-create
>          STATUS       current
>          DESCRIPTION
>             "The estimated number of seconds it takes to
>             transmit a link state update packet over this
>             interface."
>          DEFVAL { 1 }
>          ::= { ospfIfEntry 7 }
>
> 2. Also what would a value of 0 for RestartInterval mean. Though it would
> not create a problem.
>
> 3. Besides what would a value greater than 1800 mean for
> RetransmitInterval(no problem caused by it though). May be the limit could
> be RefreshInterval.
>
> I will change these in the OSPFv3 MIB atleast.

Sounds good - we should definitely fix these.


>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Schrodi Karl [mailto:karl.schrodi@SIEMENS.COM]
> Sent: Thursday, June 26, 2003 13:33
> To: OSPF@PEACH.EASE.LSOFT.COM
> Subject: AW: Zero as ospfIfRetransInterval
>
>
> Hi Acee,
>
> I fully understand that retransmission is mandatory - but does it really
> make sense to have a retransmission interval of zero? Wouldn´t it be like
> some kind of a DoS attack against yourself and your neighbour(s)?
>
> Well, probably nobody reasonably will set this interval to zero - but ...
>
> I would prefer something like the previous proposal of Vishwas, i.e. putting
> a limitation in the object description in the MIB.
>
> Regards
> Karl
>
>
> -----Ursprüngliche Nachricht-----
> Von: Acee Lindem [mailto:acee@REDBACK.COM]
> Gesendet: Mittwoch, 25. Juni 2003 19:03
> An: OSPF@PEACH.EASE.LSOFT.COM
> Betreff: Re: Zero as ospfIfRetransInterval
>
>
> Eric Gray wrote:
>
>>Acee,
>>
>>    Why would it be wrong to set a retransmit interval to zero?  Usually,
>>setting a retransmit interval to zero would have the special meaning that
>>retransmission does not occur (i.e. - the interval is infinite).  Is that
>
> not
>
>>an intended meaning in this case?
>
>
> Nope - not retransmitting would make the flooding unreliable and
> would violate the base protocol specification (RFC 2328).
>
>
>>Acee Lindem wrote:
>>
>>
>>
>>>Manral, Vishwas wrote:
>>>
>>>
>>>>Hi Acee,
>>>>
>>>>If we do not intend to define new variables, we may want to at least put
>>>
> the
>
>>>>limitation of 0, in the object description in the MIB.
>>>
>>>Hi Vishwas,
>>>
>>>That sounds like a good idea since any implementation that allows
>>>write access to set the variables to 0 is broken.
>>>
>>>Thanks,
>>>Acee
>>>
>>>
>>>
>>>>Thanks,
>>>>Vishwas
>>>>
>>>>-----Original Message-----
>>>>From: Acee Lindem [mailto:acee@REDBACK.COM]
>>>>Sent: Tuesday, June 24, 2003 18:16
>>>>To: OSPF@PEACH.EASE.LSOFT.COM
>>>>Subject: Re: Zero as ospfIfRetransInterval
>>>>
>>>>
>>>>Hi Dan,
>>>>
>>>>Daniel Joyal wrote:
>>>>
>>>>
>>>>
>>>>>You're not allowed to change the syntax unless
>>>>>it's equivalent to the old syntax.
>>>>
>>>>
>>>>Even if the old syntax doesn't match the protocol
>>>>specification?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>So in this
>>>>>case, we would need to deprecate/obsolete.
>>>>
>>>>
>>>>Then I don't think it is worth defining
>>>>new MIB variables given that ospfIfTransitDelay,
>>>>ospfIfRetransInterval, ospfVirtIfTransitDelay, and
>>>>ospfVirtIfRetransInterval have served us thus far.
>>>>
>>>>Other opinions are welcome.
>>>>
>>>>Thanks,
>>>>Acee
>>>>
>>>>
>>>>
>>>>
>>>>>-Dan
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Acee Lindem [mailto:acee@redback.com]
>>>>>>Sent: Monday, June 23, 2003 11:35 PM
>>>>>>To: Mailing List; Joyal, Daniel [BL60:NP30:EXCH]
>>>>>>Subject: Re: Zero as ospfIfRetransInterval
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Igor Miroshnik wrote:
>>>>>>
>>>>>>
>>>>>>>All,
>>>>>>>
>>>>>>>Can anybody clarify the physical sense of assigning
>>>>>>>ospfIfRetransInterval to zero? RFC1850 allows such an assignment.
>>>>>>
>>>>>>I believe UpToMaxAge should range from 1..3600 rather than 0..3600.
>>>>>>
>>>>>>Dan - can we change this in the MIB update without
>>>>>>deprecating variables?
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Thanks
>>>>>>>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>Acee
>>>>>>
>>>>>>
>>>>>
>>>>--
>>>>Acee
>>>>
>>>
>>>--
>>>Acee
>>
>>
>>
>>
>
>
> --
> Acee
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 27 02:28:07 2003
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 CAA18896
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 27 Jun 2003 02:28:07 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00A360D3@cherry.ease.lsoft.com>; Fri, 27 Jun 2003 2:21:23 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46808006 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 27 Jun 2003 02:21:21 -0400
Received: from 203.199.83.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 27 Jun 2003 02:21:21 -0400
Received: (qmail 8812 invoked by uid 510); 27 Jun 2003 06:19:33 -0000
Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 27 jun
          2003 06:19:33 -0000
MIME-Version: 1.0
Content-type: text/plain; format=flowed
Content-Disposition: inline
Message-ID:  <20030627061933.8811.qmail@webmail17.rediffmail.com>
Date:         Fri, 27 Jun 2003 06:19:33 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Krishna Rao <ospf_query@REDIFFMAIL.COM>
Subject: Clarification in NSSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi

I am basically testing RFC 3101 NSSA implementation. I find that
routes are missing in the Router (not in NSSA area) but is
conected to the Router in NSSA area through backbone area.


Topology Used in Testing
========================
  |-------------------------------|
  |                               |
  |                               |
  |                               |
R1-------------R2---------------R3
                 |                |
                 |                |
                 |                |
            --------------------------- NSSA area 0.0.0.1
                        |
                        |
                        |
                        R4
                        | area 0.0.0.1
                        |Import External Routes.
                        |

There are 2 areas in this Topology -
NSSA area 0.0.0.1 (R2, R3 and R4)
Remaining all the networks are in backbone area.

R1 is connected to R2 and R3 through backbone area. R2 and R3 are
connected through backbone area.

RouterID of R1 10.0.0.1
RouterID of R2 20.0.0.1
RouterID of R3 30.0.0.1

R3 is elected as Translator. Import external routes at R4. R1
holds the external routes.

Now, stop the router R3. R2 takes over as Translator.

BUT, now R1 doesnot hold the external routes.

I expect the R1 to hold the external routes. But as per RFC 3101
since R2 holds LSA generated by R3 which is of higher RouterID, R2
doesnot generate Type 5 LSAs. Is it correct. If this is the case,
then R1 would never hold the external routes.

Your response on this would be highly appreciated.

Thanks & Regards
Krishna





___________________________________________________
Click below to experience Sooraj Barjatya's latest offering
'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 27 06:46:40 2003
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 GAA21867
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 27 Jun 2003 06:46:40 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00A366F9@cherry.ease.lsoft.com>; Fri, 27 Jun 2003 6:46:38 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46839927 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 27 Jun 2003 06:46:37 -0400
Received: from 192.51.44.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 27 Jun 2003 06:46:36 -0400
Received: from m3.gw.fujitsu.co.jp ([10.0.50.73]) by fgwmail5.fujitsu.co.jp
          (8.12.9/Fujitsu Gateway) id h5RAkZQU028356 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 27 Jun 2003 19:46:35 +0900
          (envelope-from kashima@nd.net.fujitsu.co.jp)
Received: from s2.gw.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.12.9/Fujitsu
          Domain Master) id h5RAkYPN028380 for <OSPF@PEACH.EASE.LSOFT.COM>;
          Fri, 27 Jun 2003 19:46:34 +0900 (envelope-from
          kashima@nd.net.fujitsu.co.jp)
Received: from chisato.nd.net.fujitsu.co.jp (chisato.nd.net.fujitsu.co.jp
          [10.22.112.21]) by s2.gw.fujitsu.co.jp (8.12.9) id h5RAkXvA029917 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 27 Jun 2003 19:46:34 +0900
          (envelope-from kashima@nd.net.fujitsu.co.jp)
Received: from mail1.nd.net.fujitsu.co.jp (dhcp113248.nd.net.fujitsu.co.jp
          [10.22.113.248]) by chisato.nd.net.fujitsu.co.jp (8.12.6p2/8.12.6)
          with SMTP id h5RAkXSW037626 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 27
          Jun 2003 19:46:33 +0900 (JST) (envelope-from
          kashima@nd.net.fujitsu.co.jp)
X-Mailer: EdMax Ver2.85.3F
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID:  <200306271046.h5RAkXSW037626@chisato.nd.net.fujitsu.co.jp>
Date:         Fri, 27 Jun 2003 19:46:33 +0900
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: KASHIMA Hiroaki <kashima@ND.NET.FUJITSU.CO.JP>
Subject: P2MP on OSPF-TE
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi

I have an question for draft-katz-yeung-ospf-traffic.

How can I describe Link ID sub-TLV for P2MP interfaces?
The draft says in Section 2.5.2

  "The Link ID is identical to the contents of the
   Link ID field in the Router LSA for these link types",

and RFC 2328 says in Section 12.4.1.2

  "o A single Type 3 link ..."
  "o For each fully adjacent neighbor..., add an additional Type 1 link..."

but the draft also says in Section 2.4.2

  "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
   exactly one."

So I cannot write it as same as Link ID in the Router LSA.
--
KASHIMA, Hiroaki <kashima@nd.net.fujitsu.co.jp>
Software Development Department-II,
IP system Division, Fujitsu Ltd


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 27 08:22:39 2003
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 IAA25394
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 27 Jun 2003 08:22:38 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00A36913@cherry.ease.lsoft.com>; Fri, 27 Jun 2003 8:22:37 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46843671 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 27 Jun 2003 08:22:36 -0400
Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 27 Jun 2003 08:22:36 -0400
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <NTLZ69AS>;
          Fri, 27 Jun 2003 17:52:32 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <AB9CCBF59B42604EB08449C1B0BFC81A537892@HARITHA.ctd.hcltech.com>
Date:         Fri, 27 Jun 2003 17:52:49 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Jeyanath Minto J - CTD, Chennai." <jeyananthj@CTD.HCLTECH.COM>
Subject: Re: Clarification in NSSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

hi Krishna,
    R2 maintain a List of this area's Nssa border Routers and ASBR.
Translator is Elected from this List.
    so , when u stopped the R3 , R2 removes the R3 from the List. And R2
will elect itself as a Translator ( because R3 is unreachable ) and
translate type 7 to Type 5.



Cheers
Minto Mascarenhas
**********************************************************************
*  Internet IS for everyone - but it won't be unless WE make it so   *
**********************************************************************

-----Original Message-----
From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM]
Sent: Friday, June 27, 2003 11:50 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Clarification in NSSA


Hi

I am basically testing RFC 3101 NSSA implementation. I find that
routes are missing in the Router (not in NSSA area) but is
conected to the Router in NSSA area through backbone area.


Topology Used in Testing
========================
  |-------------------------------|
  |                               |
  |                               |
  |                               |
R1-------------R2---------------R3
                 |                |
                 |                |
                 |                |
            --------------------------- NSSA area 0.0.0.1
                        |
                        |
                        |
                        R4
                        | area 0.0.0.1
                        |Import External Routes.
                        |

There are 2 areas in this Topology -
NSSA area 0.0.0.1 (R2, R3 and R4)
Remaining all the networks are in backbone area.

R1 is connected to R2 and R3 through backbone area. R2 and R3 are
connected through backbone area.

RouterID of R1 10.0.0.1
RouterID of R2 20.0.0.1
RouterID of R3 30.0.0.1

R3 is elected as Translator. Import external routes at R4. R1
holds the external routes.

Now, stop the router R3. R2 takes over as Translator.

BUT, now R1 doesnot hold the external routes.

I expect the R1 to hold the external routes. But as per RFC 3101
since R2 holds LSA generated by R3 which is of higher RouterID, R2
doesnot generate Type 5 LSAs. Is it correct. If this is the case,
then R1 would never hold the external routes.

Your response on this would be highly appreciated.

Thanks & Regards
Krishna





___________________________________________________
Click below to experience Sooraj Barjatya's latest offering
'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Fri Jun 27 09:11:44 2003
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 JAA27059
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 27 Jun 2003 09:11:44 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00A368A3@cherry.ease.lsoft.com>; Fri, 27 Jun 2003 9:11:32 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46847421 for OSPF@PEACH.EASE.LSOFT.COM;
          Fri, 27 Jun 2003 09:11:13 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Fri, 27 Jun 2003 09:11:13 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id 89DD31021EB for
          <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 27 Jun 2003 06:11:12 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208
            Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <200306271046.h5RAkXSW037626@chisato.nd.net.fujitsu.co.jp>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3EFC427E.6060301@redback.com>
Date:         Fri, 27 Jun 2003 09:11:26 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: P2MP on OSPF-TE
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

KASHIMA Hiroaki wrote:
> Hi
>
> I have an question for draft-katz-yeung-ospf-traffic.
>
> How can I describe Link ID sub-TLV for P2MP interfaces?
> The draft says in Section 2.5.2
>
>   "The Link ID is identical to the contents of the
>    Link ID field in the Router LSA for these link types",


Hello Kashima-san,

The Link Type sub-TLV doesn't only allows link types of point-to-point
and multi-access. Hence, I believe you should model your P2MP interface
as multiple P2P links.

I'd be interested in other opinions as well.

>
> and RFC 2328 says in Section 12.4.1.2
>
>   "o A single Type 3 link ..."
>   "o For each fully adjacent neighbor..., add an additional Type 1 link..."
>
> but the draft also says in Section 2.4.2
>
>   "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
>    exactly one."
>
> So I cannot write it as same as Link ID in the Router LSA.
> --
> KASHIMA, Hiroaki <kashima@nd.net.fujitsu.co.jp>
> Software Development Department-II,
> IP system Division, Fujitsu Ltd
>


--
Acee


From owner-ospf@PEACH.EASE.LSOFT.COM  Sat Jun 28 04:15:54 2003
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 EAA18559
	for <ospf-archive@LISTS.IETF.ORG>; Sat, 28 Jun 2003 04:15:54 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00A38DC9@cherry.ease.lsoft.com>; Sat, 28 Jun 2003 4:15:22 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46922027 for OSPF@PEACH.EASE.LSOFT.COM;
          Sat, 28 Jun 2003 04:15:21 -0400
Received: from 203.199.83.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Sat, 28 Jun 2003 04:15:21 -0400
Received: (qmail 2451 invoked by uid 510); 28 Jun 2003 08:14:04 -0000
Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 28 jun
          2003 08:14:04 -0000
MIME-Version: 1.0
Content-type: text/plain; format=flowed
Content-Disposition: inline
Message-ID:  <20030628081404.2450.qmail@webmail35.rediffmail.com>
Date:         Sat, 28 Jun 2003 08:14:04 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vivek Dubey <vivek_ospf@REDIFFMAIL.COM>
Subject: Re: Clarification in NSSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi,
The point krishna is trying to make:
1) R3 goes down
2) R2 gets elected as translator
3) But R2 while translating Type 7 to Type 5
    sees functionally equv Type 5 previously
    translated by R3 (before being stopped).
    Note R3 router id is higher.
    So R2 doesn't originate Translated Type 5.
4) So both R2 and R1 hold Type 5 generated by
    R3 before it went down (no flushing was done
    by R3 before going down).
5) Consequently R1 will loose routes to those
    Type 7 networks (calculated using Translated
    Type 5 by R3).
6) But R2 will hold routes as it is directly connected
    to NSSA area and can use Type 7 for getting to those
    networks.

This can happen in real networks.
Probably Pat can clarify how to handle such
scenarios.

thanks,
vivek


On Fri, 27 Jun 2003 Jeyanath Minto J - CTD, Chennai. wrote :
>hi Krishna,
>     R2 maintain a List of this area's Nssa border Routers and
>ASBR.
>Translator is Elected from this List.
>     so , when u stopped the R3 , R2 removes the R3 from the
>List. And R2
>will elect itself as a Translator ( because R3 is unreachable )
>and
>translate type 7 to Type 5.
>
>
>
>Cheers
>Minto Mascarenhas
>**********************************************************************
>*  Internet IS for everyone - but it won't be unless WE make it
>so   *
>**********************************************************************
>
>-----Original Message-----
> From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM]
>Sent: Friday, June 27, 2003 11:50 AM
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: Clarification in NSSA
>
>
>Hi
>
>I am basically testing RFC 3101 NSSA implementation. I find
>that
>routes are missing in the Router (not in NSSA area) but is
>conected to the Router in NSSA area through backbone area.
>
>
>Topology Used in Testing
>========================
>   |-------------------------------|
>   |                               |
>   |                               |
>   |                               |
>R1-------------R2---------------R3
>                  |                |
>                  |                |
>                  |                |
>             --------------------------- NSSA area 0.0.0.1
>                         |
>                         |
>                         |
>                         R4
>                         | area 0.0.0.1
>                         |Import External Routes.
>                         |
>
>There are 2 areas in this Topology -
>NSSA area 0.0.0.1 (R2, R3 and R4)
>Remaining all the networks are in backbone area.
>
>R1 is connected to R2 and R3 through backbone area. R2 and R3
>are
>connected through backbone area.
>
>RouterID of R1 10.0.0.1
>RouterID of R2 20.0.0.1
>RouterID of R3 30.0.0.1
>
>R3 is elected as Translator. Import external routes at R4. R1
>holds the external routes.
>
>Now, stop the router R3. R2 takes over as Translator.
>
>BUT, now R1 doesnot hold the external routes.
>
>I expect the R1 to hold the external routes. But as per RFC
>3101
>since R2 holds LSA generated by R3 which is of higher RouterID,
>R2
>doesnot generate Type 5 LSAs. Is it correct. If this is the
>case,
>then R1 would never hold the external routes.
>
>Your response on this would be highly appreciated.
>
>Thanks & Regards
>Krishna
>
>
>
>
>
>___________________________________________________
>Click below to experience Sooraj Barjatya's latest offering
>'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
>Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com

___________________________________________________
Click below to experience Sooraj Barjatya's latest offering
'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Sat Jun 28 04:51:08 2003
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 EAA19126
	for <ospf-archive@LISTS.IETF.ORG>; Sat, 28 Jun 2003 04:51:07 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00A38DC9@cherry.ease.lsoft.com>; Sat, 28 Jun 2003 4:51:07 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46922365 for OSPF@PEACH.EASE.LSOFT.COM;
          Sat, 28 Jun 2003 04:51:06 -0400
Received: from 203.199.83.147 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Sat, 28 Jun 2003 04:51:05 -0400
Received: (qmail 2493 invoked by uid 510); 28 Jun 2003 08:49:57 -0000
Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 28 jun
          2003 08:49:57 -0000
MIME-Version: 1.0
Content-type: text/plain; format=flowed
Content-Disposition: inline
Message-ID:  <20030628084957.2492.qmail@webmail25.rediffmail.com>
Date:         Sat, 28 Jun 2003 08:49:57 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vivek Dubey <vivek_ospf@REDIFFMAIL.COM>
Subject: Tunnel Adjacency
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi Sina,

Is such a conf possible application of TA ?

    R1---- bkbone ----R2---- area 2 ------R7
     |                |                    |
     |                |                    |
   area1            area1                  |
     |                |                    |
     |                |                  area 2
    R3---- area1 -----R4                   |
     |                                     |
     |                                     |
    area2                                  |
     |                                     |
     |                                     |
    R6-------------------------------------

Now link between R6 and R7 in area 2 is broken.
Could a TA can be configured between :
1)R3 and R2 (through area 1 and bkbone ie R3 - R1 and R2)
   beloging to area 2 for repair of area 2.
2)R3 and R2 (through area 1 ie R3-R4 and R2)
   belogning to area 2 .
To repair the area partition.

In short could TTA (ie transit area) span
through multiple areas ?

Further could TA belong to an area ie TTA to
whom none of the ABRS (between which TA is
configured attached).

thanks,
vivek


___________________________________________________
Click below to experience Sooraj Barjatya's latest offering
'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Sat Jun 28 09:27:10 2003
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 JAA22284
	for <ospf-archive@LISTS.IETF.ORG>; Sat, 28 Jun 2003 09:27:10 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00A392DA@cherry.ease.lsoft.com>; Sat, 28 Jun 2003 9:22:44 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46956982 for OSPF@PEACH.EASE.LSOFT.COM;
          Sat, 28 Jun 2003 09:22:42 -0400
Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Sat, 28 Jun 2003 09:22:42 -0400
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <NTLZ7ZST>;
          Sat, 28 Jun 2003 18:52:38 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <AB9CCBF59B42604EB08449C1B0BFC81A537F03@HARITHA.ctd.hcltech.com>
Date:         Sat, 28 Jun 2003 18:52:56 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Jeyanath Minto J - CTD, Chennai." <jeyananthj@CTD.HCLTECH.COM>
Subject: Re: Clarification in NSSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

hi vivek,
   In section 3.2  step (2) clearly mention this. R3 already out from the
List of NSSA border Routers and , now R2's router Id is higher than anyone (
Actually R2 alone in that List ). As result, R2 will translate LSAs.

Cheers
Minto Mascarenhas
**********************************************************************
*  Internet IS for everyone - but it won't be unless WE make it so   *
**********************************************************************

-----Original Message-----
From: Vivek Dubey [mailto:vivek_ospf@REDIFFMAIL.COM]
Sent: Saturday, June 28, 2003 1:44 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Clarification in NSSA


Hi,
The point krishna is trying to make:
1) R3 goes down
2) R2 gets elected as translator
3) But R2 while translating Type 7 to Type 5
    sees functionally equv Type 5 previously
    translated by R3 (before being stopped).
    Note R3 router id is higher.
    So R2 doesn't originate Translated Type 5.
4) So both R2 and R1 hold Type 5 generated by
    R3 before it went down (no flushing was done
    by R3 before going down).
5) Consequently R1 will loose routes to those
    Type 7 networks (calculated using Translated
    Type 5 by R3).
6) But R2 will hold routes as it is directly connected
    to NSSA area and can use Type 7 for getting to those
    networks.

This can happen in real networks.
Probably Pat can clarify how to handle such
scenarios.

thanks,
vivek


On Fri, 27 Jun 2003 Jeyanath Minto J - CTD, Chennai. wrote :
>hi Krishna,
>     R2 maintain a List of this area's Nssa border Routers and
>ASBR.
>Translator is Elected from this List.
>     so , when u stopped the R3 , R2 removes the R3 from the
>List. And R2
>will elect itself as a Translator ( because R3 is unreachable )
>and
>translate type 7 to Type 5.
>
>
>
>Cheers
>Minto Mascarenhas
>**********************************************************************
>*  Internet IS for everyone - but it won't be unless WE make it
>so   *
>**********************************************************************
>
>-----Original Message-----
> From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM]
>Sent: Friday, June 27, 2003 11:50 AM
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: Clarification in NSSA
>
>
>Hi
>
>I am basically testing RFC 3101 NSSA implementation. I find
>that
>routes are missing in the Router (not in NSSA area) but is
>conected to the Router in NSSA area through backbone area.
>
>
>Topology Used in Testing
>========================
>   |-------------------------------|
>   |                               |
>   |                               |
>   |                               |
>R1-------------R2---------------R3
>                  |                |
>                  |                |
>                  |                |
>             --------------------------- NSSA area 0.0.0.1
>                         |
>                         |
>                         |
>                         R4
>                         | area 0.0.0.1
>                         |Import External Routes.
>                         |
>
>There are 2 areas in this Topology -
>NSSA area 0.0.0.1 (R2, R3 and R4)
>Remaining all the networks are in backbone area.
>
>R1 is connected to R2 and R3 through backbone area. R2 and R3
>are
>connected through backbone area.
>
>RouterID of R1 10.0.0.1
>RouterID of R2 20.0.0.1
>RouterID of R3 30.0.0.1
>
>R3 is elected as Translator. Import external routes at R4. R1
>holds the external routes.
>
>Now, stop the router R3. R2 takes over as Translator.
>
>BUT, now R1 doesnot hold the external routes.
>
>I expect the R1 to hold the external routes. But as per RFC
>3101
>since R2 holds LSA generated by R3 which is of higher RouterID,
>R2
>doesnot generate Type 5 LSAs. Is it correct. If this is the
>case,
>then R1 would never hold the external routes.
>
>Your response on this would be highly appreciated.
>
>Thanks & Regards
>Krishna
>
>
>
>
>
>___________________________________________________
>Click below to experience Sooraj Barjatya's latest offering
>'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
>Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com

___________________________________________________
Click below to experience Sooraj Barjatya's latest offering
'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Sat Jun 28 13:35:40 2003
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 NAA28047
	for <ospf-archive@LISTS.IETF.ORG>; Sat, 28 Jun 2003 13:35:40 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00A39B96@cherry.ease.lsoft.com>; Sat, 28 Jun 2003 13:35:38 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46968955 for OSPF@PEACH.EASE.LSOFT.COM;
          Sat, 28 Jun 2003 13:35:36 -0400
Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Sat, 28 Jun 2003 13:35:36 -0400
Received: from smirtoraw2k03 (sjc-vpn1-639.cisco.com [10.21.98.127]) by
          fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h5SHZYT17418 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Sat, 28 Jun 2003 10:35:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
Message-ID:  <000001c33d9b$aeb15bb0$f2ce7243@amer.cisco.com>
Date:         Sat, 28 Jun 2003 10:35:34 -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: Tunnel Adjacency
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <20030628084957.2492.qmail@webmail25.rediffmail.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Vivek


->
->Hi Sina,
->
->Is such a conf possible application of TA ?
->
->    R1---- bkbone ----R2---- area 2 ------R7
->     |                |                    |
->     |                |                    |
->   area1            area1                  |
->     |                |                    |
->     |                |                  area 2
->    R3---- area1 -----R4                   |
->     |                                     |
->     |                                     |
->    area2                                  |
->     |                                     |
->     |                                     |
->    R6-------------------------------------
->
->Now link between R6 and R7 in area 2 is broken.
->Could a TA can be configured between :
->1)R3 and R2 (through area 1 and bkbone ie R3 - R1 and R2)
->   beloging to area 2 for repair of area 2.

The path between the two end-point of TA must be an intra-area path, so
if you configure a TA between R3-R2 then the path taken can be only
R3-R4-R2

If you want you can have a TA between R3-R1 and another one between
R1-R2 so that you take the path R3-R1-R2

->2)R3 and R2 (through area 1 ie R3-R4 and R2)
->   belogning to area 2 .

Yes

->To repair the area partition.
->
->In short could TTA (ie transit area) span
->through multiple areas ?

No, unless you setup multiple TAs

->
->Further could TA belong to an area ie TTA to
->whom none of the ABRS (between which TA is
->configured attached).

Not sure I understand your question, TTA (TA Transit Area) is the are
through which TA goes and TA itself belong to an area ( call it
associated area ) which must be different than TTA

Thanks
Sina

->
->thanks,
->vivek
->
->
->___________________________________________________
->Click below to experience Sooraj Barjatya's latest offering
->'Main Prem Ki Diwani Hoon' starring Hrithik Roshan, Abhishek
->Bachchan & Kareena Kapoor http://www.mpkdh.com
->


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 30 01:28:18 2003
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 BAA18488
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Jun 2003 01:28:03 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00A3C44B@cherry.ease.lsoft.com>; Mon, 30 Jun 2003 1:27:01 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 47062680 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 30 Jun 2003 01:26:59 -0400
Received: from 203.199.83.147 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Mon, 30 Jun 2003 01:26:58 -0400
Received: (qmail 10149 invoked by uid 510); 30 Jun 2003 05:25:36 -0000
Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 30 jun
          2003 05:25:36 -0000
MIME-Version: 1.0
Content-type: text/plain; format=flowed
Content-Disposition: inline
Message-ID:  <20030630052536.10148.qmail@webmail25.rediffmail.com>
Date:         Mon, 30 Jun 2003 05:25:36 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vivek Dubey <vivek_ospf@REDIFFMAIL.COM>
Subject: Re: Clarification in NSSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi Minto,
The question here is whether R2 on seeing functionally equv
Type 5 LSA from R3 (translated previously before being
stopped) should originate Type 5 (which is a result
of Type 7 translation).

There is no doubt as far as who is translator, its R2
only.

thanks,
vivek



On Sat, 28 Jun 2003 Jeyanath Minto J - CTD, Chennai. wrote :
>hi vivek,
>    In section 3.2  step (2) clearly mention this. R3 already out
> from the
>List of NSSA border Routers and , now R2's router Id is higher
>than anyone (
>Actually R2 alone in that List ). As result, R2 will translate
>LSAs.
>
>Cheers
>Minto Mascarenhas
>**********************************************************************
>*  Internet IS for everyone - but it won't be unless WE make it
>so   *
>**********************************************************************
>
>-----Original Message-----
> From: Vivek Dubey [mailto:vivek_ospf@REDIFFMAIL.COM]
>Sent: Saturday, June 28, 2003 1:44 PM
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: Re: Clarification in NSSA
>
>
>Hi,
>The point krishna is trying to make:
>1) R3 goes down
>2) R2 gets elected as translator
>3) But R2 while translating Type 7 to Type 5
>     sees functionally equv Type 5 previously
>     translated by R3 (before being stopped).
>     Note R3 router id is higher.
>     So R2 doesn't originate Translated Type 5.
>4) So both R2 and R1 hold Type 5 generated by
>     R3 before it went down (no flushing was done
>     by R3 before going down).
>5) Consequently R1 will loose routes to those
>     Type 7 networks (calculated using Translated
>     Type 5 by R3).
>6) But R2 will hold routes as it is directly connected
>     to NSSA area and can use Type 7 for getting to those
>     networks.
>
>This can happen in real networks.
>Probably Pat can clarify how to handle such
>scenarios.
>
>thanks,
>vivek
>
>
>On Fri, 27 Jun 2003 Jeyanath Minto J - CTD, Chennai. wrote :
> >hi Krishna,
> >     R2 maintain a List of this area's Nssa border Routers
>and
> >ASBR.
> >Translator is Elected from this List.
> >     so , when u stopped the R3 , R2 removes the R3 from the
> >List. And R2
> >will elect itself as a Translator ( because R3 is unreachable
>)
> >and
> >translate type 7 to Type 5.
> >
> >
> >
> >Cheers
> >Minto Mascarenhas
> >**********************************************************************
> >*  Internet IS for everyone - but it won't be unless WE make
>it
> >so   *
> >**********************************************************************
> >
> >-----Original Message-----
> > From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM]
> >Sent: Friday, June 27, 2003 11:50 AM
> >To: OSPF@PEACH.EASE.LSOFT.COM
> >Subject: Clarification in NSSA
> >
> >
> >Hi
> >
> >I am basically testing RFC 3101 NSSA implementation. I find
> >that
> >routes are missing in the Router (not in NSSA area) but is
> >conected to the Router in NSSA area through backbone area.
> >
> >
> >Topology Used in Testing
> >========================
> >   |-------------------------------|
> >   |                               |
> >   |                               |
> >   |                               |
> >R1-------------R2---------------R3
> >                  |                |
> >                  |                |
> >                  |                |
> >             --------------------------- NSSA area 0.0.0.1
> >                         |
> >                         |
> >                         |
> >                         R4
> >                         | area 0.0.0.1
> >                         |Import External Routes.
> >                         |
> >
> >There are 2 areas in this Topology -
> >NSSA area 0.0.0.1 (R2, R3 and R4)
> >Remaining all the networks are in backbone area.
> >
> >R1 is connected to R2 and R3 through backbone area. R2 and R3
> >are
> >connected through backbone area.
> >
> >RouterID of R1 10.0.0.1
> >RouterID of R2 20.0.0.1
> >RouterID of R3 30.0.0.1
> >
> >R3 is elected as Translator. Import external routes at R4. R1
> >holds the external routes.
> >
> >Now, stop the router R3. R2 takes over as Translator.
> >
> >BUT, now R1 doesnot hold the external routes.
> >
> >I expect the R1 to hold the external routes. But as per RFC
> >3101
> >since R2 holds LSA generated by R3 which is of higher
>RouterID,
> >R2
> >doesnot generate Type 5 LSAs. Is it correct. If this is the
> >case,
> >then R1 would never hold the external routes.
> >
> >Your response on this would be highly appreciated.
> >
> >Thanks & Regards
> >Krishna
> >
> >
> >
> >
> >
> >___________________________________________________
> >Click below to experience Sooraj Barjatya's latest offering
> >'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
> >Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com
>
>___________________________________________________
>Click below to experience Sooraj Barjatya's latest offering
>'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
>Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com

___________________________________________________
Click below to experience Sooraj Barjatya's latest offering
'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 30 01:39:06 2003
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 BAA19092
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Jun 2003 01:39:05 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A3C4D6@cherry.ease.lsoft.com>; Mon, 30 Jun 2003 1:39:04 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 47062983 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 30 Jun 2003 01:39:02 -0400
Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Mon, 30 Jun 2003 01:39:02 -0400
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <NTLZ87D8>;
          Mon, 30 Jun 2003 11:08:59 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <AB9CCBF59B42604EB08449C1B0BFC81A5383B6@HARITHA.ctd.hcltech.com>
Date:         Mon, 30 Jun 2003 11:09:17 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Jeyanath Minto J - CTD, Chennai." <jeyananthj@CTD.HCLTECH.COM>
Subject: Re: Clarification in NSSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

hi vivek ,
      yes, R2 should originate Type 5 (which is a result of Type 7
translation).
Please read  the translation algorithm again (section 3.2 step (2) ).

Cheers
Minto Mascarenhas
**********************************************************************
*  Internet IS for everyone - but it won't be unless WE make it so   *
**********************************************************************
-----Original Message-----
From: Vivek Dubey [mailto:vivek_ospf@REDIFFMAIL.COM]
Sent: Monday, June 30, 2003 10:56 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Clarification in NSSA


Hi Minto,
The question here is whether R2 on seeing functionally equv
Type 5 LSA from R3 (translated previously before being
stopped) should originate Type 5 (which is a result
of Type 7 translation).

There is no doubt as far as who is translator, its R2
only.

thanks,
vivek



On Sat, 28 Jun 2003 Jeyanath Minto J - CTD, Chennai. wrote :
>hi vivek,
>    In section 3.2  step (2) clearly mention this. R3 already out
> from the
>List of NSSA border Routers and , now R2's router Id is higher
>than anyone (
>Actually R2 alone in that List ). As result, R2 will translate
>LSAs.
>
>Cheers
>Minto Mascarenhas
>**********************************************************************
>*  Internet IS for everyone - but it won't be unless WE make it
>so   *
>**********************************************************************
>
>-----Original Message-----
> From: Vivek Dubey [mailto:vivek_ospf@REDIFFMAIL.COM]
>Sent: Saturday, June 28, 2003 1:44 PM
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: Re: Clarification in NSSA
>
>
>Hi,
>The point krishna is trying to make:
>1) R3 goes down
>2) R2 gets elected as translator
>3) But R2 while translating Type 7 to Type 5
>     sees functionally equv Type 5 previously
>     translated by R3 (before being stopped).
>     Note R3 router id is higher.
>     So R2 doesn't originate Translated Type 5.
>4) So both R2 and R1 hold Type 5 generated by
>     R3 before it went down (no flushing was done
>     by R3 before going down).
>5) Consequently R1 will loose routes to those
>     Type 7 networks (calculated using Translated
>     Type 5 by R3).
>6) But R2 will hold routes as it is directly connected
>     to NSSA area and can use Type 7 for getting to those
>     networks.
>
>This can happen in real networks.
>Probably Pat can clarify how to handle such
>scenarios.
>
>thanks,
>vivek
>
>
>On Fri, 27 Jun 2003 Jeyanath Minto J - CTD, Chennai. wrote :
> >hi Krishna,
> >     R2 maintain a List of this area's Nssa border Routers
>and
> >ASBR.
> >Translator is Elected from this List.
> >     so , when u stopped the R3 , R2 removes the R3 from the
> >List. And R2
> >will elect itself as a Translator ( because R3 is unreachable
>)
> >and
> >translate type 7 to Type 5.
> >
> >
> >
> >Cheers
> >Minto Mascarenhas
> >**********************************************************************
> >*  Internet IS for everyone - but it won't be unless WE make
>it
> >so   *
> >**********************************************************************
> >
> >-----Original Message-----
> > From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM]
> >Sent: Friday, June 27, 2003 11:50 AM
> >To: OSPF@PEACH.EASE.LSOFT.COM
> >Subject: Clarification in NSSA
> >
> >
> >Hi
> >
> >I am basically testing RFC 3101 NSSA implementation. I find
> >that
> >routes are missing in the Router (not in NSSA area) but is
> >conected to the Router in NSSA area through backbone area.
> >
> >
> >Topology Used in Testing
> >========================
> >   |-------------------------------|
> >   |                               |
> >   |                               |
> >   |                               |
> >R1-------------R2---------------R3
> >                  |                |
> >                  |                |
> >                  |                |
> >             --------------------------- NSSA area 0.0.0.1
> >                         |
> >                         |
> >                         |
> >                         R4
> >                         | area 0.0.0.1
> >                         |Import External Routes.
> >                         |
> >
> >There are 2 areas in this Topology -
> >NSSA area 0.0.0.1 (R2, R3 and R4)
> >Remaining all the networks are in backbone area.
> >
> >R1 is connected to R2 and R3 through backbone area. R2 and R3
> >are
> >connected through backbone area.
> >
> >RouterID of R1 10.0.0.1
> >RouterID of R2 20.0.0.1
> >RouterID of R3 30.0.0.1
> >
> >R3 is elected as Translator. Import external routes at R4. R1
> >holds the external routes.
> >
> >Now, stop the router R3. R2 takes over as Translator.
> >
> >BUT, now R1 doesnot hold the external routes.
> >
> >I expect the R1 to hold the external routes. But as per RFC
> >3101
> >since R2 holds LSA generated by R3 which is of higher
>RouterID,
> >R2
> >doesnot generate Type 5 LSAs. Is it correct. If this is the
> >case,
> >then R1 would never hold the external routes.
> >
> >Your response on this would be highly appreciated.
> >
> >Thanks & Regards
> >Krishna
> >
> >
> >
> >
> >
> >___________________________________________________
> >Click below to experience Sooraj Barjatya's latest offering
> >'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
> >Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com
>
>___________________________________________________
>Click below to experience Sooraj Barjatya's latest offering
>'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
>Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com

___________________________________________________
Click below to experience Sooraj Barjatya's latest offering
'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 30 01:48:59 2003
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 BAA19390
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Jun 2003 01:48:59 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A3C488@cherry.ease.lsoft.com>; Mon, 30 Jun 2003 1:48:57 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 47063157 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 30 Jun 2003 01:48:34 -0400
Received: from 203.199.83.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Mon, 30 Jun 2003 01:48:33 -0400
Received: (qmail 30678 invoked by uid 510); 30 Jun 2003 05:47:02 -0000
Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 30 jun
          2003 05:47:02 -0000
MIME-Version: 1.0
Content-type: text/plain; format=flowed
Content-Disposition: inline
Message-ID:  <20030630054702.30677.qmail@webmail35.rediffmail.com>
Date:         Mon, 30 Jun 2003 05:47:02 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vivek Dubey <vivek_ospf@REDIFFMAIL.COM>
Subject: Clarification in NSSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi krishna,
Section 3.2 point 2 (RFC 3101).. should help...

"If the Type-7 LSA is not contained in any explicitly
configured Type-7 address range and the calculating router has
the highest router ID amongst NSSA translators that have
originated a functionally equivalent Type-5 LSA (i.e. same
destination, cost and non-zero forwarding address) and that
are reachable over area 0 and the NSSA, then a Type-5 LSA
should be generated"


vivek


On Sat, 28 Jun 2003 Vivek Dubey wrote :
>Hi,
>The point krishna is trying to make:
>1) R3 goes down
>2) R2 gets elected as translator
>3) But R2 while translating Type 7 to Type 5
>    sees functionally equv Type 5 previously
>    translated by R3 (before being stopped).
>    Note R3 router id is higher.
>    So R2 doesn't originate Translated Type 5.
>4) So both R2 and R1 hold Type 5 generated by
>    R3 before it went down (no flushing was done
>    by R3 before going down).
>5) Consequently R1 will loose routes to those
>    Type 7 networks (calculated using Translated
>    Type 5 by R3).
>6) But R2 will hold routes as it is directly connected
>    to NSSA area and can use Type 7 for getting to those
>    networks.
>
>This can happen in real networks.
>Probably Pat can clarify how to handle such
>scenarios.
>
>thanks,
>vivek
>
>
>On Fri, 27 Jun 2003 Jeyanath Minto J - CTD, Chennai. wrote :
>>hi Krishna,
>>     R2 maintain a List of this area's Nssa border Routers and
>>ASBR.
>>Translator is Elected from this List.
>>     so , when u stopped the R3 , R2 removes the R3 from the
>>List. And R2
>>will elect itself as a Translator ( because R3 is unreachable
>>)
>>and
>>translate type 7 to Type 5.
>>
>>
>>
>>Cheers
>>Minto Mascarenhas
>>**********************************************************************
>>*  Internet IS for everyone - but it won't be unless WE make
>>it
>>so   *
>>**********************************************************************
>>
>>-----Original Message-----
>> From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM]
>>Sent: Friday, June 27, 2003 11:50 AM
>>To: OSPF@PEACH.EASE.LSOFT.COM
>>Subject: Clarification in NSSA
>>
>>
>>Hi
>>
>>I am basically testing RFC 3101 NSSA implementation. I find
>>that
>>routes are missing in the Router (not in NSSA area) but is
>>conected to the Router in NSSA area through backbone area.
>>
>>
>>Topology Used in Testing
>>========================
>>   |-------------------------------|
>>   |                               |
>>   |                               |
>>   |                               |
>>R1-------------R2---------------R3
>>                  |                |
>>                  |                |
>>                  |                |
>>             --------------------------- NSSA area 0.0.0.1
>>                         |
>>                         |
>>                         |
>>                         R4
>>                         | area 0.0.0.1
>>                         |Import External Routes.
>>                         |
>>
>>There are 2 areas in this Topology -
>>NSSA area 0.0.0.1 (R2, R3 and R4)
>>Remaining all the networks are in backbone area.
>>
>>R1 is connected to R2 and R3 through backbone area. R2 and R3
>>are
>>connected through backbone area.
>>
>>RouterID of R1 10.0.0.1
>>RouterID of R2 20.0.0.1
>>RouterID of R3 30.0.0.1
>>
>>R3 is elected as Translator. Import external routes at R4. R1
>>holds the external routes.
>>
>>Now, stop the router R3. R2 takes over as Translator.
>>
>>BUT, now R1 doesnot hold the external routes.
>>
>>I expect the R1 to hold the external routes. But as per RFC
>>3101
>>since R2 holds LSA generated by R3 which is of higher
>>RouterID,
>>R2
>>doesnot generate Type 5 LSAs. Is it correct. If this is the
>>case,
>>then R1 would never hold the external routes.
>>
>>Your response on this would be highly appreciated.
>>
>>Thanks & Regards
>>Krishna
>>
>>
>>
>>
>>
>>___________________________________________________
>>Click below to experience Sooraj Barjatya's latest offering
>>'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
>>Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com
>
>___________________________________________________
>Click below to experience Sooraj Barjatya's latest offering
>'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
>Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com

___________________________________________________
Click below to experience Sooraj Barjatya's latest offering
'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 30 02:34:18 2003
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 CAA02521
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Jun 2003 02:34:18 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00A3C74F@cherry.ease.lsoft.com>; Mon, 30 Jun 2003 2:34:03 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 47064389 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 30 Jun 2003 02:33:57 -0400
Received: from 203.199.83.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i)
          with TCP; Mon, 30 Jun 2003 02:33:56 -0400
Received: (qmail 1815 invoked by uid 510); 30 Jun 2003 06:32:04 -0000
Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 30 jun
          2003 06:32:04 -0000
MIME-Version: 1.0
Content-type: text/plain; format=flowed
Content-Disposition: inline
Message-ID:  <20030630063204.1814.qmail@webmail26.rediffmail.com>
Date:         Mon, 30 Jun 2003 06:32:04 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vivek Dubey <vivek_ospf@REDIFFMAIL.COM>
Subject: Re: Clarification in NSSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi minto,
Got it.... was missing one line there.

thanks,
vivek


On Mon, 30 Jun 2003 Jeyanath Minto J - CTD, Chennai. wrote :
>hi vivek ,
>       yes, R2 should originate Type 5 (which is a result of Type
>7
>translation).
>Please read  the translation algorithm again (section 3.2 step
>(2) ).
>
>Cheers
>Minto Mascarenhas
>**********************************************************************
>*  Internet IS for everyone - but it won't be unless WE make it
>so   *
>**********************************************************************
>-----Original Message-----
> From: Vivek Dubey [mailto:vivek_ospf@REDIFFMAIL.COM]
>Sent: Monday, June 30, 2003 10:56 AM
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: Re: Clarification in NSSA
>
>
>Hi Minto,
>The question here is whether R2 on seeing functionally equv
>Type 5 LSA from R3 (translated previously before being
>stopped) should originate Type 5 (which is a result
>of Type 7 translation).
>
>There is no doubt as far as who is translator, its R2
>only.
>
>thanks,
>vivek
>
>
>
>On Sat, 28 Jun 2003 Jeyanath Minto J - CTD, Chennai. wrote :
> >hi vivek,
> >    In section 3.2  step (2) clearly mention this. R3 already
>out
> > from the
> >List of NSSA border Routers and , now R2's router Id is
>higher
> >than anyone (
> >Actually R2 alone in that List ). As result, R2 will
>translate
> >LSAs.
> >
> >Cheers
> >Minto Mascarenhas
> >**********************************************************************
> >*  Internet IS for everyone - but it won't be unless WE make
>it
> >so   *
> >**********************************************************************
> >
> >-----Original Message-----
> > From: Vivek Dubey [mailto:vivek_ospf@REDIFFMAIL.COM]
> >Sent: Saturday, June 28, 2003 1:44 PM
> >To: OSPF@PEACH.EASE.LSOFT.COM
> >Subject: Re: Clarification in NSSA
> >
> >
> >Hi,
> >The point krishna is trying to make:
> >1) R3 goes down
> >2) R2 gets elected as translator
> >3) But R2 while translating Type 7 to Type 5
> >     sees functionally equv Type 5 previously
> >     translated by R3 (before being stopped).
> >     Note R3 router id is higher.
> >     So R2 doesn't originate Translated Type 5.
> >4) So both R2 and R1 hold Type 5 generated by
> >     R3 before it went down (no flushing was done
> >     by R3 before going down).
> >5) Consequently R1 will loose routes to those
> >     Type 7 networks (calculated using Translated
> >     Type 5 by R3).
> >6) But R2 will hold routes as it is directly connected
> >     to NSSA area and can use Type 7 for getting to those
> >     networks.
> >
> >This can happen in real networks.
> >Probably Pat can clarify how to handle such
> >scenarios.
> >
> >thanks,
> >vivek
> >
> >
> >On Fri, 27 Jun 2003 Jeyanath Minto J - CTD, Chennai. wrote :
> > >hi Krishna,
> > >     R2 maintain a List of this area's Nssa border Routers
> >and
> > >ASBR.
> > >Translator is Elected from this List.
> > >     so , when u stopped the R3 , R2 removes the R3 from
>the
> > >List. And R2
> > >will elect itself as a Translator ( because R3 is
>unreachable
> >)
> > >and
> > >translate type 7 to Type 5.
> > >
> > >
> > >
> > >Cheers
> > >Minto Mascarenhas
> >
> >**********************************************************************
> > >*  Internet IS for everyone - but it won't be unless WE
>make
> >it
> > >so   *
> >
> >**********************************************************************
> > >
> > >-----Original Message-----
> > > From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM]
> > >Sent: Friday, June 27, 2003 11:50 AM
> > >To: OSPF@PEACH.EASE.LSOFT.COM
> > >Subject: Clarification in NSSA
> > >
> > >
> > >Hi
> > >
> > >I am basically testing RFC 3101 NSSA implementation. I find
> > >that
> > >routes are missing in the Router (not in NSSA area) but is
> > >conected to the Router in NSSA area through backbone area.
> > >
> > >
> > >Topology Used in Testing
> > >========================
> > >   |-------------------------------|
> > >   |                               |
> > >   |                               |
> > >   |                               |
> > >R1-------------R2---------------R3
> > >                  |                |
> > >                  |                |
> > >                  |                |
> > >             --------------------------- NSSA area 0.0.0.1
> > >                         |
> > >                         |
> > >                         |
> > >                         R4
> > >                         | area 0.0.0.1
> > >                         |Import External Routes.
> > >                         |
> > >
> > >There are 2 areas in this Topology -
> > >NSSA area 0.0.0.1 (R2, R3 and R4)
> > >Remaining all the networks are in backbone area.
> > >
> > >R1 is connected to R2 and R3 through backbone area. R2 and
>R3
> > >are
> > >connected through backbone area.
> > >
> > >RouterID of R1 10.0.0.1
> > >RouterID of R2 20.0.0.1
> > >RouterID of R3 30.0.0.1
> > >
> > >R3 is elected as Translator. Import external routes at R4.
>R1
> > >holds the external routes.
> > >
> > >Now, stop the router R3. R2 takes over as Translator.
> > >
> > >BUT, now R1 doesnot hold the external routes.
> > >
> > >I expect the R1 to hold the external routes. But as per RFC
> > >3101
> > >since R2 holds LSA generated by R3 which is of higher
> >RouterID,
> > >R2
> > >doesnot generate Type 5 LSAs. Is it correct. If this is the
> > >case,
> > >then R1 would never hold the external routes.
> > >
> > >Your response on this would be highly appreciated.
> > >
> > >Thanks & Regards
> > >Krishna
> > >
> > >
> > >
> > >
> > >
> > >___________________________________________________
> > >Click below to experience Sooraj Barjatya's latest offering
> > >'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
> > >Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com
> >
> >___________________________________________________
> >Click below to experience Sooraj Barjatya's latest offering
> >'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
> >Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com
>
>___________________________________________________
>Click below to experience Sooraj Barjatya's latest offering
>'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
>Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com

___________________________________________________
Click below to experience Sooraj Barjatya's latest offering
'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 30 08:35:13 2003
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 IAA18226
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Jun 2003 08:35:13 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00A3CB58@cherry.ease.lsoft.com>; Mon, 30 Jun 2003 7:55:01 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 47094393 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 30 Jun 2003 07:55:00 -0400
Received: from 64.4.11.44 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Mon, 30 Jun 2003 07:54:59 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon,
          30 Jun 2003 04:54:59 -0700
Received: from 203.197.24.195 by by7fd.bay7.hotmail.msn.com with HTTP; Mon, 30
          Jun 2003 11:54:58 GMT
X-Originating-IP: [203.197.24.195]
X-Originating-Email: [ameya_nms@hotmail.com]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 30 Jun 2003 11:54:59.0212 (UTC)
                       FILETIME=[6E7284C0:01C33EFE]
Message-ID:  <BAY7-F44ONgOcljYWDu00008680@hotmail.com>
Date:         Mon, 30 Jun 2003 11:54:58 +0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Ameya Pandit <ameya_nms@HOTMAIL.COM>
Subject: Area Border routers (ABRs)
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hello :

Had a question on number of ABR in an area. What is the typical ABR number
for a particular network, is it a percentage of N, where N is the total
number of routers in an area. ? .. how do we hit upon a particular value for
ABRs?

any pointers are helpful.

rgds
ameya

_________________________________________________________________
Are you a geek? Are you a techno freak? http://www.msn.co.in/Computing/


From owner-ospf@PEACH.EASE.LSOFT.COM  Mon Jun 30 08:35:14 2003
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 IAA18228
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Jun 2003 08:35:13 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A3CB89@cherry.ease.lsoft.com>; Mon, 30 Jun 2003 8:33:07 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 47105389 for OSPF@PEACH.EASE.LSOFT.COM;
          Mon, 30 Jun 2003 08:33:06 -0400
Received: from 64.102.124.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with
          TCP; Mon, 30 Jun 2003 08:33:05 -0400
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by
          rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5UCX3g5028943 for
          <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 30 Jun 2003 08:33:03 -0400 (EDT)
Received: from russpc.nc.rr.com (rtp-vpn1-337.cisco.com [10.82.225.81]) by
          cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA06424
          for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 30 Jun 2003 08:33:02 -0400 (EDT)
References: <BAY7-F44ONgOcljYWDu00008680@hotmail.com>
X-X-Sender: ruwhite@uzura.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.WNT.4.55.0306300832370.3772@russpc>
Date:         Mon, 30 Jun 2003 08:33:02 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Russ White <ruwhite@CISCO.COM>
Subject: Re: Area Border routers (ABRs)
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To:  <BAY7-F44ONgOcljYWDu00008680@hotmail.com>
Precedence: list

Most of the time, you see two or three, perhaps four, ABR's in an area, no
matter how many routers are in the area itself.

:-)

Russ

On Mon, 30 Jun 2003, Ameya Pandit wrote:

> Hello :
>
> Had a question on number of ABR in an area. What is the typical ABR number
> for a particular network, is it a percentage of N, where N is the total
> number of routers in an area. ? .. how do we hit upon a particular value for
> ABRs?
>
> any pointers are helpful.
>
> rgds
> ameya
>
> _________________________________________________________________
> Are you a geek? Are you a techno freak? http://www.msn.co.in/Computing/
>

__________________________________
riw@cisco.com CCIE <>< Grace Alone