From owner-ospf@DISCUSS.MICROSOFT.COM  Sun Sep  1 23:53:21 2002
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 XAA03416
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 1 Sep 2002 23:53:21 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006FB828@cherry.ease.lsoft.com>; 1 Sep 2002 23:54:52 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 129071 for OSPF@DISCUSS.MICROSOFT.COM;
          Sun, 1 Sep 2002 23:54:48 -0400
Received: from 166.111.68.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Sun, 1 Sep 2002 23:54:47 -0400
Received: from chinahero ([192.168.1.192]) by csnet1.cs.tsinghua.edu.cn
          (8.9.2/8.9.2) with SMTP id MAA17596 for <OSPF@DISCUSS.MICROSOFT.COM>;
          Mon, 2 Sep 2002 12:42:26 +0900 (CDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
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:  <003601c25236$03317640$c001a8c0@chinahero>
Date:         Mon, 2 Sep 2002 12:05:45 +0800
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Li Zhongjie <lzj@CSNET1.CS.TSINGHUA.EDU.CN>
Subject: description of p2p link in r-LSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id XAA03416

Hi,

  For a numbered point-to-point link, a router has two options to declare a stub link <link id,link data>:
  1) <subnet number, subnet mask>
  2) <endpoint ip address, all 1's mask>
  as decribed in RFC2328 section 12.4.1.1 page 130.
  Two questions to ask:
  1) what is the mostly widely used option on the current Internet?
  2) I think different routers in an OSPF area can use different options without causing any problems, right?
---
Best Regards,

Zhongjie Li

********************************************************************
*    Zhongjie Li                                                   *
*    Ph.D candidate, Department of Computer Science & Technology   *
*    Tsinghua University, Beijing, 100084, P.R.China               *
*    Tel: +86+10-62788109     Fax:  +86+10-62788109                *
*    Email: lzj@csnet1.cs.tsinghua.edu.cn                          *
********************************************************************


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep  2 05:38:12 2002
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 FAA17663
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 2 Sep 2002 05:38:12 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006FBF50@cherry.ease.lsoft.com>; Mon, 2 Sep 2002 5:39:44 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 129832 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 2 Sep 2002 05:39:44 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 2 Sep 2002 05:39:43 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <RQ2V0PWG>; Mon, 2 Sep 2002 05:39:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="gb2312"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328791504@india_exch.hyderabad.mindspeed.com>
Date:         Mon, 2 Sep 2002 05:42:06 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: description of p2p link in r-LSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Zhongjie Li,

1) The few implementations I know of use option 2.
2) No, there should be no interoperabilty concerns/problems if the two ends
use different options. However in that case we would have a host route(/32)
as well as a network route.

Also check the link
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind9908&L=OSPF&P=R3243&I=
-3. A similar discussion was on the list a few days back too.

Thanks,
Vishwas

-----Original Message-----
From: Li Zhongjie [mailto:lzj@CSNET1.CS.TSINGHUA.EDU.CN]
Sent: Monday, September 02, 2002 9:36 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: description of p2p link in r-LSA


Hi,

  For a numbered point-to-point link, a router has two options to declare a
stub link <link id,link data>:
  1) <subnet number, subnet mask>
  2) <endpoint ip address, all 1's mask>
  as decribed in RFC2328 section 12.4.1.1 page 130.
  Two questions to ask:
  1) what is the mostly widely used option on the current Internet?
  2) I think different routers in an OSPF area can use different options
without causing any problems, right?
---
Best Regards,

Zhongjie Li

********************************************************************
*    Zhongjie Li                                                   *
*    Ph.D candidate, Department of Computer Science & Technology   *
*    Tsinghua University, Beijing, 100084, P.R.China               *
*    Tel: +86+10-62788109     Fax:  +86+10-62788109                *
*    Email: lzj@csnet1.cs.tsinghua.edu.cn                          *
********************************************************************


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep  2 10:22:16 2002
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 KAA23166
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 2 Sep 2002 10:22:16 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.006FC3BB@cherry.ease.lsoft.com>; Mon, 2 Sep 2002 10:23:48 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 131528 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 2 Sep 2002 10:23:48 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 2 Sep 2002 10:23:47 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id 1C7BB4BA214 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Mon,  2 Sep 2002 07:23:43 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <E7E13AAF2F3ED41197C100508BD6A328791504@india_exch.hyderabad.mindspeed.com>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
Message-ID:  <3D7373DA.5040101@redback.com>
Date:         Mon, 2 Sep 2002 10:21:14 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: description of p2p link in r-LSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Manral, Vishwas wrote:

> Hi Zhongjie Li,
>
> 1) The few implementations I know of use option 2.


For the sake of clarification, I believe Vishwas means option 2
as defined in the RFC 2328 (as opposed to Zhonglie's E-mail
where the two options are reversed).


> 2) No, there should be no interoperabilty concerns/problems if the two ends
> use different options. However in that case we would have a host route(/32)
> as well as a network route.
>
> Also check the link
> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind9908&L=OSPF&P=R3243&I=
> -3. A similar discussion was on the list a few days back too.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Li Zhongjie [mailto:lzj@CSNET1.CS.TSINGHUA.EDU.CN]
> Sent: Monday, September 02, 2002 9:36 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: description of p2p link in r-LSA
>
>
> Hi,
>
>   For a numbered point-to-point link, a router has two options to declare a
> stub link <link id,link data>:
>   1) <subnet number, subnet mask>
>   2) <endpoint ip address, all 1's mask>
>   as decribed in RFC2328 section 12.4.1.1 page 130.
>   Two questions to ask:
>   1) what is the mostly widely used option on the current Internet?
>   2) I think different routers in an OSPF area can use different options
> without causing any problems, right?
> ---
> Best Regards,
>
> Zhongjie Li
>
> ********************************************************************
> *    Zhongjie Li                                                   *
> *    Ph.D candidate, Department of Computer Science & Technology   *
> *    Tsinghua University, Beijing, 100084, P.R.China               *
> *    Tel: +86+10-62788109     Fax:  +86+10-62788109                *
> *    Email: lzj@csnet1.cs.tsinghua.edu.cn                          *
> ********************************************************************
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep  3 00:21:10 2002
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 AAA06963
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 3 Sep 2002 00:21:09 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006FD39F@cherry.ease.lsoft.com>; Tue, 3 Sep 2002 0:22:36 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 133377 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 3 Sep 2002 00:22:35 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 3 Sep 2002 00:22:35 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0ANW4>; Tue, 3 Sep 2002 00:22:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="gb2312"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328791516@india_exch.hyderabad.mindspeed.com>
Date:         Tue, 3 Sep 2002 00:24:44 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: description of p2p link in r-LSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Zhongjie Li,

Acee is right, I did mean option 2 in the RFC. I did not notice it could
create conflict here.

Thanks,
Vishwas

-----Original Message-----
From: Acee Lindem [mailto:acee@REDBACK.COM]
Sent: Monday, September 02, 2002 7:51 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: description of p2p link in r-LSA


Manral, Vishwas wrote:

> Hi Zhongjie Li,
>
> 1) The few implementations I know of use option 2.


For the sake of clarification, I believe Vishwas means option 2
as defined in the RFC 2328 (as opposed to Zhonglie's E-mail
where the two options are reversed).


> 2) No, there should be no interoperabilty concerns/problems if the two
ends
> use different options. However in that case we would have a host
route(/32)
> as well as a network route.
>
> Also check the link
>
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind9908&L=OSPF&P=R3243&I=
> -3. A similar discussion was on the list a few days back too.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Li Zhongjie [mailto:lzj@CSNET1.CS.TSINGHUA.EDU.CN]
> Sent: Monday, September 02, 2002 9:36 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: description of p2p link in r-LSA
>
>
> Hi,
>
>   For a numbered point-to-point link, a router has two options to declare
a
> stub link <link id,link data>:
>   1) <subnet number, subnet mask>
>   2) <endpoint ip address, all 1's mask>
>   as decribed in RFC2328 section 12.4.1.1 page 130.
>   Two questions to ask:
>   1) what is the mostly widely used option on the current Internet?
>   2) I think different routers in an OSPF area can use different options
> without causing any problems, right?
> ---
> Best Regards,
>
> Zhongjie Li
>
> ********************************************************************
> *    Zhongjie Li                                                   *
> *    Ph.D candidate, Department of Computer Science & Technology   *
> *    Tsinghua University, Beijing, 100084, P.R.China               *
> *    Tel: +86+10-62788109     Fax:  +86+10-62788109                *
> *    Email: lzj@csnet1.cs.tsinghua.edu.cn                          *
> ********************************************************************
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep  3 06:14:54 2002
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 GAA20767
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 3 Sep 2002 06:14:54 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006FE341@cherry.ease.lsoft.com>; Tue, 3 Sep 2002 6:16:26 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 134911 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 3 Sep 2002 06:16:26 -0400
Received: from 152.163.225.98 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 3 Sep 2002 06:16:26 -0400
Received: from Jjsyed@aol.com by imo-r02.mx.aol.com (mail_out_v34.10.) id
          7.163.133fa318 (15700) for <ospf@discuss.microsoft.com>; Tue, 3 Sep
          2002 06:16:24 -0400 (EDT)
Received: from  aol.com (mow-m29.webmail.aol.com [64.12.137.6]) by
          air-id05.mx.aol.com (v88.20) with ESMTP id MAILINID52-0903061624;
          Tue, 03 Sep 2002 06:16:24 -0400
X-Mailer: Atlas Mailer 2.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <125DE5BA.2F9F561C.0004D071@aol.com>
Date:         Tue, 3 Sep 2002 06:16:24 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Javed Syed <Jjsyed@AOL.COM>
Subject: OSPF multiple process
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit

Hi,

I would like to know if anybody have seen or aware of any good document explaining why it is not recommended to run multiple OSPF processor in the same router.
I have seens many emails regarding this issue.
I have seen people running two processor only if it is absolute necessary and to make each node acting as a multiple node for load balancing.
Any comments will be appreciated.

JS


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep  3 07:53:56 2002
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 HAA22752
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 3 Sep 2002 07:53:56 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.006FE3B3@cherry.ease.lsoft.com>; Tue, 3 Sep 2002 7:55:29 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 135196 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 3 Sep 2002 07:55:29 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 3 Sep 2002 07:55:29 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0A32J>; Tue, 3 Sep 2002 07:55:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328791527@india_exch.hyderabad.mindspeed.com>
Date:         Tue, 3 Sep 2002 07:57:52 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: OSPF multiple process
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Javed,

Multiple instances of OSPF on the same router can be used between PE/CE in
BGP MPLS IP VPN's.

Check the link
http://www.ietf.org/internet-drafts/draft-rosen-vpns-ospf-bgp-mpls-05.txt

I am not really aware in which case you would want/do away with multiple
instances of OSPF though. I could not figure out the load balancing idea
either.

Thanks,
Vishwas

-----Original Message-----
From: Javed Syed [mailto:Jjsyed@AOL.COM]
Sent: Tuesday, September 03, 2002 3:46 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF multiple process


Hi,

I would like to know if anybody have seen or aware of any good document
explaining why it is not recommended to run multiple OSPF processor in the
same router.
I have seens many emails regarding this issue.
I have seen people running two processor only if it is absolute necessary
and to make each node acting as a multiple node for load balancing.
Any comments will be appreciated.

JS


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep  3 10:59:44 2002
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 KAA29763
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 3 Sep 2002 10:59:44 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006FEBCA@cherry.ease.lsoft.com>; Tue, 3 Sep 2002 11:01:18 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 136110 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 3 Sep 2002 11:01:18 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 3 Sep 2002 11:01:18 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id 55268F2C5D for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue,  3 Sep 2002 08:01:16 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <125DE5BA.2F9F561C.0004D071@aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D74CE1A.6080907@redback.com>
Date:         Tue, 3 Sep 2002 10:58:34 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: OSPF multiple process
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Javed Syed wrote:

> Hi,
>
> I would like to know if anybody have seen or aware of any good document explaining why it is not recommended to run multiple OSPF processor in the same router.
> I have seens many emails regarding this issue.

> I have seen people running two processor only if it is absolute necessary and to make each node acting as a multiple node for load balancing.
> Any comments will be appreciated.


JS,

I think the fear of multiple OSPF process dates back to days of routers
with less than 100 MHz processors and only a couple megs of memory. At
that time, many thought that the scaling/scheduling/debuging issues
associated with multiple link state protocol instances were intractable.
I doubt you'll encouter the same trepidation today.


>
> JS
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep  3 14:49:53 2002
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 OAA09270
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 3 Sep 2002 14:49:53 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006FF2BD@cherry.ease.lsoft.com>; Tue, 3 Sep 2002 14:51:26 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 136700 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 3 Sep 2002 14:51:26 -0400
Received: from 216.32.171.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 3 Sep 2002 14:51:25 -0400
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id
          LAA25555 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 3 Sep 2002 11:48:32
          -0700 (PDT)
References: <125DE5BA.2F9F561C.0004D071@aol.com> <3D74CE1A.6080907@redback.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Message-ID:  <20020903114832.B25223@demiurge.exodus.net>
Date:         Tue, 3 Sep 2002 11:48:32 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Andrew Lange <andrewl@EXODUS.NET>
Subject: Re: OSPF multiple process
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D74CE1A.6080907@redback.com>; from acee@REDBACK.COM on Tue,
              Sep 03, 2002 at 10:58:34AM -0400
Precedence: list

In fact, the Exodus network has used multiple OSPF processes for a number
of years.  It has worked just fine.

Andrew

On Tue, Sep 03, 2002 at 10:58:34AM -0400, Acee Lindem wrote:
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
>             Netscape6/6.2.3
> X-Accept-Language: en-us
> Date:         Tue, 3 Sep 2002 10:58:34 -0400
> Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
> From: Acee Lindem <acee@REDBACK.COM>
> Subject: Re: OSPF multiple process
> To: OSPF@DISCUSS.MICROSOFT.COM
> Precedence: list
> X-OriginalArrivalTime: 03 Sep 2002 15:03:11.0482 (UTC) FILETIME=[053D2DA0:01C2535B]
>
> Javed Syed wrote:
>
> > Hi,
> >
> > I would like to know if anybody have seen or aware of any good document explaining why it is not recommended to run multiple OSPF processor in the same router.
> > I have seens many emails regarding this issue.
>
> > I have seen people running two processor only if it is absolute necessary and to make each node acting as a multiple node for load balancing.
> > Any comments will be appreciated.
>
>
> JS,
>
> I think the fear of multiple OSPF process dates back to days of routers
> with less than 100 MHz processors and only a couple megs of memory. At
> that time, many thought that the scaling/scheduling/debuging issues
> associated with multiple link state protocol instances were intractable.
> I doubt you'll encouter the same trepidation today.
>
>
> >
> > JS
> >
> >
>
>
> --
> Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep  4 06:11:11 2002
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 GAA21653
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 Sep 2002 06:11:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00700DE2@cherry.ease.lsoft.com>; Wed, 4 Sep 2002 6:12:41 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 138750 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 4 Sep 2002 06:12:41 -0400
Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 4 Sep 2002 06:12:39 -0400
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
          (iPlanet Messaging Server 5.1 (built Sep  5 2001)) id
          <0H1W00K01SJTNR@mailout1.samsung.com> for ospf@disCUSS.MICROSOFT.COM;
          Wed, 04 Sep 2002 19:16:41 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet
          Messaging Server 5.1 (built Sep  5 2001)) with ESMTP id
          <0H1W00K0OSJTN9@mailout1.samsung.com> for ospf@disCUSS.MICROSOFT.COM;
          Wed, 04 Sep 2002 19:16:41 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging
          Server 5.1 (built Sep  5 2001)) with ESMTPA id
          <0H1W00DLNSK9LQ@mmp2.samsung.com> for ospf@disCUSS.MICROSOFT.COM;
          Wed, 04 Sep 2002 19:17:05 +0900 (KST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: multipart/mixed; boundary="Boundary_(ID_Kd0ulBDj59TVNF4RytiTfA)"
X-Priority: 3
X-MSMail-priority: Normal
Message-ID:  <078f01c253fb$9a1e2a00$b4036c6b@sisodomain.com>
Date:         Wed, 4 Sep 2002 15:42:37 +0530
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Manav Bhatia <manav@SAMSUNG.COM>
Subject: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

This is a multi-part message in MIME format.

--Boundary_(ID_Kd0ulBDj59TVNF4RytiTfA)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

Hi,
The question of OSPF vis-a-vis IS-IS has been raised more than once in the
mailing lists (both OSPF and ISIS) and elsewhere and there seems to be no
apparent paper which clearly differentiates between the two. I started with
IS-IS and moved to OSPF some time back, and in my quest stumbled upon Dave
Katz presentation on the same. In my course of transitioning to OSPF I had
written a lot of notes and ideas (borrowed from Dave presentation and some
helpful cues which i took from Radia Perlman's "Interconnections") on the
key differences between these 2 link state routing protocols.

I have assimilated all of those in this document which i am hereby
attaching with this mail of mine. I would like to hear from other people
their views/thoughts/experiences with these protocols and i intended to
capture all that in the updated document which can then be used as a
reference in understanding as to how/what/where the two link state routing
protocols differ.

Manav

----
"When you are courting a nice girl an hour seems like a second. When you
sit on a red-hot cinder a second seems like an hour. That's relativity."

-Albert Einstein, on relativity


--Boundary_(ID_Kd0ulBDj59TVNF4RytiTfA)
Content-type: text/plain; name=Comparitive_Study_of_OSPF_and_ISIS.txt
Content-disposition: attachment; filename=Comparitive_Study_of_OSPF_and_ISIS.txt
Content-Transfer-Encoding: quoted-printable

                                                          Manav Bhatia
                                                          Samsung =
Electronics
                                                          September 2002

              A Comparative Study of OSPF and IS-IS

  There are two link state routing protocols available. One is the=20
  IS-IS developed by ISO exclusively for the ISO networks and the other=20
  is OSPF developed by the IETF because the former did not, originally =
run=20
  on TCP/IP networks. Since then many changes have come in both the=20
  routing protocols. IETF has come out with the Integrated IS-IS which =
runs=20
  IS-IS for TCP/IP networks.
 =20
  This document compares the two link state routing protocols in each
  area of the specification and also compares the two link state=20
  routing protocols in terms of the scalability issues.
 =20
  This document compares the two routing protocols in terms of=20
 =20
  1. Encapsulation
  2. Network Types Supported
  3. Partition Repair=20
  4. Packet Encoding
  5. Data base granularity
  6. Neighbour Establishment

  7. Designated Router Concept
  8. LAN Flooding
  9. Scalability Issues
  10. Metrics Used
  11. Authentication and Security
  12. MPLS/GMPLS and Traffic Engineering Extensions
  13. Support for Ipv6=20
 =20
  There is a list of abbreviations used at the end of this document

  1. Introduction
 =20
  In essence each router distributes its view of the local neighbourhood =

  and floods it within the area within the network and every other=20
  router ends up with a map of the topology (the information in the LSPs =

  yields complete knowledge of the graph) and then routes are computed=20
  based on the map each has by running the Dijkstra's algorithm on the=20
  LSD. Both the link state routing protocols have a 2 level hierarchy.=20
  In OSPF there is this concept of a backbone area and a non zero area.=20
  In IS-IS, there are level 1 and level 2 areas. Both of the routing=20
  protocols are widely deployed in the field.
 =20
  We could have actually gone ahead with one protocol (IS-IS) wherein=20
  extending and adapting IS-IS for IP was possible by merely adding IP=20
  reachability information along with the existing model. Incidentally=20
  this is what Integrated IS-IS does (RFC 1195) but nobody thought of it =

  before and in the mean time work on OSPF had already gained momentum.=20
  Moreover people wanted an "IPv4" only protocol which was very much=20
  optimised and directed towards IPv4 and one which would have all=20
  mechanisms to make the adjacencies come up faster on the IP networks.=20
  OSPF was thus designed specifically for IP (rather IPv4!) and is
  loosely based on IS-IS.=20
 =20
 =20
 =20
                                                                  [Page =
1]

  The repercussions of having an "IPv4" only protocol become clear in =
the
  following sections for it obviously introduces some amount of =
complexity in
  the protocol. IS-IS is a lot simpler but then it was never designed =
for IP=20
  so we have some strange things like assigning OSI addresses to our IP =
only=20
  router. This often confuses people and everyone ends up making calls =
to the
  customer support centre.=20
 =20
  2. Encapsulation=20
 =20
  OSPF runs over IP and as a result of which we can have virtual links.=20
  This implies that we can send an OSPF packet from one part of the =
planet=20
  to the other. The downside of this is that it makes OSPF vulnerable to =
the=20
  classic DoS (discussed at length in later sections) attacks and all =
such=20
  related attacks.=20
 =20
  If LSAs get really big then we can have IP fragmentation to make them =
fit.=20
  One of the advantages of using IP encapsulation is that we can use =
VCmux=20
  encaps on ATM. This is basically no encapsulation and everything on =
the=20
  VC has to be necessarily IP. So if you're running OSPF on ATM then you =

  can turn off all encapsulations and save on the bandwidth in the ATM=20
  network.
   =20
  IS-IS on the other hand runs directly over layer 2 i.e. next to IP, =
which=20
  means that we cant have virtual links unless we have some sort of=20
  explicit tunnelling. Since it does not run on IP these packets cannot =
be
  routed beyond the immediate next hop and can never be sourced by =
non-border=20
  routers. This makes ISIS difficult to spoof because there's now no way =

  to get an IS-IS packet into the inside of your network from outside=20
  (because its not an IP packet) unless you accidentally let a GRE =
tunnel=20
  remain open or something.=20
 =20
  IS-IS requires ATM SNAP encapsulation because its not an IP packet =
thereby
  loosing on the bandwidth efficiency we have with OSPF. This adds =
enough=20
  bytes so a TCP ACK won't fit into one ATM cell (it does in OSPF). We =
thus=20
  waste some extra bandwidth.
 =20
  Suggestions to run OSPF directly over data link layer has the inherent =

  problem where we need to provide code points of access in OSPF for =
each=20
  of the data link protocol types. For e.g. (Frame-relay, Ethernet, ATM, =

  PPP etc).
   =20
  Moreover, most of the link layers don't provide fragmentation and=20
  reassembly services. IP (not as a protocol but as a technology) =
supports=20
  virtually all Layer 2 (except X.25). So the protocols running over IP =
need=20
  not worry about services offered by IP. There are definite =
(dis)advantages=20
  if we run OSPF directly over L2 but advantages overweigh. Once again , =

  virtual links (widely used) are not possible if we run OSPF over Layer =
2.
  For these reasons it is better to run OSPF over IP.
 =20
  Refer to John Moy's book section 3.2 Design Decisions for more =
details.
 =20
  The other obvious advantage of running over IP is the ability to use =
IP=20
  multicast when running over broadcast networks.
 =20
  Also, one nice feature about IP encapsulation of OSPF packets is that =
it=20
  tests processing of IP packets on the interfaces. I've seen routers =
not=20
  being able to process IP packets on interfaces, but still maintaining =
ISIS=20

   =20
                                                                  [Page =
2] =20

  adjacencies, so the rest of the network still used the link. This is =
not=20
  possible in OSPF where the HELLO protocol ensures that communication=20
  between the neighbours is bidirectional.
 =20
  3. Partition Repair
 =20
  Partition repair is optional in IS-IS. A L2 router indicates its =
support of=20
  partition repair in its LSPs. As long as at least one L2 router in =
each=20
  partition implements the partition-repair capability, the area =
partition
  will be repaired. IS-IS does not attempt to automatically repair a
  partitioned L2 network by using L1 path. However this can be =
accomplished=20
  in theory by promoting routers along the desired path to the L2 =
routers,=20
  which may then again connect L2. Partition repair requires tunnelling =
which=20
  is rarely implemented(except by few people out there in DEC) and isn't =

  widely deployed.=20
 =20
  OSPF on the other hand has no automatic mechanism for repairing area=20
  partitions. In OSPF, L2 routers are configured to report address =
summaries=20
  that include all the IP addresses reachable within the area. If the =
OSPF
  area partitions then it requires human intervention wherein the =
address=20
  summaries must be reconfigured after the partition and routing should =
start=20
  working again. One way of remaining unaffected with area partitions is =
by=20
  not configuring any summary addresses on the L2 routers for they will =
now=20
  instead report each individual IP address reachable within the area. =
In=20
  this case, a partitioned area just automatically breaks into two =
areas. But=20
  then there is no routing hierarchy involved and it becomes flat =
routing.
 =20
  4. Network Types Supported
 =20
  Both the protocols support LANs and Point to Point (p2p) links in =
similar=20
  ways. IS-IS has no direct Non broadcast Multiaccess (NBMA) support =
i.e.=20
  there is no specific support for things like X.25, Frame Relay and =
ATM.=20
  If you want to run IS-IS over such networks then we can either model =
them=20
  as a LAN or a set of P2P links. But IS-IS relies on the OS to do this =
for=20
  you. Modelling it as a LAN is not a very good idea anyhow.
 =20
  There is a NBMA mode in OSPF in the original specification. It takes a =

  whole lot of configuration and you're still out of luck if you loose =
your=20
  link to the designated router. NBMA networks are only as robust and=20
  reliable as the underlying data-link service. If ,for e.g., a PVC =
fails or=20
  is misconfigured or if an SVC cannot be established, due to capacity =
or=20
  policy reasons, routing over NBMA subnet will fail. And, =
unfortunately,=20
  often the reason for the failure will not be immediately obvious to =
the=20
  network operator. The Point-to-MultiPoint model (P2MP) can always be=20
  applied to rectify these problems, although at some loss of =
efficiency.

  The P2MP model can always be used on any data link technology that the =
NBMA=20
  model can be used on. Usually these subnets are connection oriented =
subnets,=20
  such as Frame Relay and ATM. In addition, the P2MP model doesn't =
require=20
  all the participating routers to be able to communicate directly, =
making it=20
  possible to model partial PVC meshes as single P2MP networks. Dropping =
the=20
  full mesh requirement also allows the modelling of more exotic data =
link=20
  technologies, such as packet radio, as P2MP networks.
 =20
  So if you have an operating system that cant do virtual interfaces or =
if=20
  there's too much of an overhead and you don't want to generate a =
separate=20
  sub interface to each of your 500 ATM circuits then p2mp is good and =
can be=20
 =20
 =20
                                                                  [Page =
3]

  handy that way.
 =20
  However, when operating a full mesh Frame Relay or ATM network in P2MP =
mode,=20
  the work involved in neighbour maintenance, flooding, and database=20
  representation increases as O(n^2), where n is the number of OSPF =
routers=20
  attached to the subnet, instead of O(n) behaviour that can be achieved =
with=20
  the NBMA model.
 =20
  5. Packet Encoding and Extensibility
 =20
  OSPF is "efficiently" encoded following a holy grail of 32 bit =
alignment.=20
  Everybody wanted a great looking packet with all the boundaries =
aligned at=20
  the 32 bit boundaries. This was supposed to be an "IPv4" only routing=20
  protocol. Here we are not talking of switching data packets. These are =

  relatively sparse controlled traffic. We came out with a great good =
looking=20
  spec with neat aligned pictures which actually did not accomplish =
much.=20
  What it did not accomplish was extensibility. The protocol cant be =
extended=20
  in a simple ways. There is no way the Router ID may be extended to =
say, 5=20
  bytes without disrupting and distorting the remaining original =
protocol.

  All fields are positional. You cant add an extra thing in the router =
LSA=20
  because you found out something interesting to extend it with. No, you =
cant=20
  do that. You can extend LSAs by using opaque LSAs but you cant extend=20
  HELLO's so if you want to support IPv6 then we need to rewrite the =
entire=20
  protocol which is in fact what we did !
 =20
  You have OSPFv3 for IPv6 which is even more complicated than the last =
one=20
  and doesn't at all look like an extension to the previous one! This is =
one=20
  of the problems of making OSPF so specific to IPv4.
 =20
  In the original spec the unrecognized LSA types are not flooded and =
hence=20
  there is no way to add new types of LSAs. Opaque LSAs were then added =
a=20
  few years ago and all vendors now support them so that they are likely =
to=20
  get from one side if your network to the other. OSPFv3 has this as an =
built=20
  in feature which means that unknown LSAs are not discarded and are =
flooded.
 =20
  IS-IS on the other hand is TLV (Tag-Length-Value) encoded. The good =
part=20
  about this is that if you don't understand a particular type you can =
always=20
  skip this and go on to the next. Unknown types are ignored but are =
still=20
  flooded. This provides a crude hook for extensibility and backward=20
  compatibility wherein we may add new fields and types even if the =
other end=20
  is not aware of it.
 =20
  All the packets are extensible as all are TLV encoded which is how we =
make=20
  HELLO messages to carry IP only information as its just another TLV =
after=20
  all!  =20
 =20
  We can have nested TLV's i.e. TLV, which has more TLV's defined inside =
to=20
  provide structure for more granular extension. Though the base=20
  specification does not use them , new IS-IS drafts are starting to do =
so=20
  for its traffic engineering. The nice part about this is that you can =
add=20
  fields to TE in future and still be backward compatible in theory with =

  earlier versions of IS-IS which support TE, or compatible with =
versions=20
  which don't support it at all!

  The new drafts written for OSPF (TE extensions) now too are beginning =
to=20
  use the TLV encoding.

                                                                  [Page =
4]


  6. Database Granularity
 =20
  It is probably the key design difference between OSPF and IS-IS and a =
lot=20
  of the details way the protocols unfold are driven by this. In OSPF =
the=20
  idea is that an atomic chunk in the database should be as small as =
possible=20
  so that if you have 10,000 externals in OSPF then you have 10,000 =
little=20
  LSAs and each one of them is a separate thing and can be looked up in =
the=20
  database and each one is a separate thing that has to be sent and=20
  acknowledged . The idea is that if we have this fine granularity and =
then=20
  if one of the external object is flapping then we just send this =
little=20
  update with one LSA in it for each flap rather than announcing the =
entire=20
  Link state database.
 =20
  LSAs are mostly numerous and small (one external per LSA, one summary =
per=20
  LSA)
 =20
  This does not however work for the Router LSA and Network LSA since =
there=20
  is only one router LSA per router and one network LSA per LAN, both of =

  which can get arbitrarily large. Although most of the people don't put =
lots=20
  and lots of externals into OSPF, we can still end up with fairly large =
LSAs=20
  anyhow. This can happen when somebody accidentally feeds the entire =
BGP=20
  route table into the OSPF!
 =20
  When its time to flood these things (LSAs) we build the Link state =
UPDATE=20
  packet out of multiple LSAs because they may be small but we want to =
send=20
  big packets (saving on the bandwidth). So there's some complexity in=20
  deciding how to build an LSA Update when we send it out. Link state =
updates=20
  are built individually at each hop because each router has a different =
view=20
  of what it was before it.=20

  Thus in OSPF small changes can yield small packets but router and =
network=20
  LSAs can be large.=20
 =20
  In IS-IS, the database is built after the link state packets (LSP). So =
each=20
  one is a bundle of information and originating routers can build them=20
  however it wants and so it will throw links between routers and =
externals=20
  and stubs and whatever else one can want in this chunk. And it is this =

  chunk which is flooded and what you can look up in your database. Each =
one=20
  of them is flooded intact hop by hop across  the network. So LSPs one=20
  router generates is exactly the same LSP which shows up on the other =
side=20
  of the network.=20
 =20
  What that means is that the LSP has to be small enough to fit into any =
link=20
  in the network. For this reason the size of the LSP is an =
architectural=20
  constant kept to 1470 bytes.=20
 =20
  The downside of this is that if we have one 1500 byte LSP packet and =
there=20
  is one thing in the middle which is changing in it then we keep =
sending the=20
  1500 bytes. As it turns out that 1500 bytes don't really matter . It's =
the=20
  number of packets that count if we look at the cost of processing the=20
  incoming packets. The overhead is the packet rate and not the number =
of=20
  bytes. We can do a clever thing if we notice that some links are =
flapping ..=20
  we move them onto smaller LSPs and pack them any way we want. This in=20
  theory can be done, but proves to be very complicated and difficult to =
do.




 =20
                                                                    =
[Page 5]

  7. Neighbour establishment

  When each of the protocols brings up the neighbours it sends HELLO =
packets=20
  and each HELLO has a "I heard you" mechanism to establish a 2 way=20
  communication. It helps the routers to determine the identity of the=20
  neighbours and periodically check the status of the links to its =
neighbours.=20
  There is a settable rate at which HELLOs are sent and a settable rate =
at=20
  which they expire to allow a trade-off between stability, overhead and =

  responsiveness. This is because if a router in your network crashes =
then=20
  you wait the "dead" time before you declare that router to be down. In =
OSPF,=20
  the spec calls for all of the holding timers and HELLO intervals to be =

  identical on a subnet and it thus becomes very difficult to actually =
change=20
  any of these timers without disrupting the entire network because the=20
  routers with the old values will now  refuse to talk to the routers =
with=20
  the new values. Any mismatch in the timers can result in the HELLOs =
being=20
  lost which can result in the adjacencies coming falsely down causing=20
  instability in the network and endless grief!
 =20
  IS-IS on the other hand allows this flexibility to configure different =

  values of timers for the routers in the same network. This also makes =
sense=20
  because in some cases it may be more important to detect quickly that =
a=20
  router has gone down, and it may be worth the overhead of more =
frequent=20
  HELLO messages from that router.
 =20
  In IS-IS there is  padding which is a cause of a lot of dissent. The =
idea=20
  was to detect links which were less than 1500 bytes (which are very =
few=20
  media in the world that have such small MTUs!) . The idea was that in =
some=20
  cases we pad the packet to MTU size and if the others cant receive =
this=20
  then we probably don't want to bring up that link because the LSPs =
wont be=20
  able to go across as LSPs are 1500 bytes big and we cant fragment them =
.=20
 =20
  In OSPF there is a check in the database exchange for MTU matches and =
we=20
  get struck in an exstart state if our MTUs aren't the same. The reason =
why=20
  they have to be the same is  that the end which is creating link state =

  update packets may build it to a MTU size on the link basis. So if one =
end=20
  thinks its 4K and the other thinks its 1500 bytes then the 1500 byte =
end=20
  cannot process the packets if it can't  receive jumbograms. The =
network is=20
  then in trouble!
 =20
  When neighbours first come up, we have to synchronize databases =
because the=20
  whole algorithm is based upon the fact that all neighbours share the =
same=20
  common information and the view of the "world". And essentially what =
we say=20
  is "Here is everything in my database" and in one case your neighbour =
will=20
  figure out what you're missing and will send it out to you or if you =
figure=20
  out what you're missing then you ask them for it. But the granularity =
of=20
  database is a huge issue here. In OSPF we may have tens of thousands =
of=20
  items which we may need to synchronize between adjacent routers =
because the=20
  data granularity is very fine. So there is this amazingly complex =
protocol=20
  for synchronizing databases. Its totally weird (initialize, more, =
master,=20
  slave, etc!) . The idea was to synchronize the routers and not to move =
any=20
  traffic across the link till their databases are completely =
synchronized.=20
  So you have all these phases that you move to and you don't declare =
the=20
  link to be up until you reach the FULL state. And thus this way we =
don't=20
  end up black- holing traffic!
 =20
  A lot of complexity in OSPF is tied up in this whole database exchange =

  process and is really a side effect of the fine granularity and it =
takes a=20
 =20
 =20
                                                                  [Page =
6]

 =20
  whole bunch of DBD packets going back and forth with a list of LSAs in
  the
 network.=20
                                                =09
  IS-IS essentially uses its regular flooding techniques to synchronize
  neighbours (that's what flooding naturally does). You just need to =
turn=20
  on and plug in the routers and the right thing will happen!
 =20
  Things would become synchronized and its easy because LSPs can be big =
and
  (remember ?) there aren't many of them. Also it doesn't take much to =
say,=20
  "This is what my view of the world looks like" because they aren't =
many=20
  items in it. So in a couple of packets you can exchange and describe =
your=20
  entire network database. We have Complete Sequence Number Packets =
(CSNP) =20
  for all these.=20
 =20
  And if you're really worried about transiting traffic before you have =
the=20
  full picture there's a tweak for that too! There's a bit called the
  "overload" bit in IS-IS which is traditionally set in the LSPs when a=20
  router runs out of memory or does not have the complete RIB. When the =
other=20
  routers in the network detect that this bit is set they will calculate =
SPF=20
  around this router and wont use it for the transit traffic. They will =
only=20
  be using it for packets destined directly to the overloaded router's=20
  directly connected networks and IP prefixes.
 =20
  This "overload" bit now finds other uses too. The router is configured =
to=20
  advertise its LSP with the "overload" bit set for a specific amount of =

  time after a reload. When this timer expires, the "overload" bit is =
cleared=20
  and the LSP is re-flooded.
 =20
  This is used by the ISPs who run both BGP and IS-IS to avoid some =
black-
  hole scenarios. Setting the overload bit for a fixed amount of time =
right=20
  after the reload (when you're booting up) ensures that the router does =
not=20
  receive transit traffic while the protocol is still converging!

  8. Designated Router concept
 =20
  Both of them have a designated router concept on the LANs. The idea is =
that=20
  if you have n routers on a LAN and if you just exchange Hellos and =
brought=20
  up adjacencies with the remaining n-1, we would end up with order more =

  than n^2 adjacencies and O(n^2) link state entries in the database. So =
a DR
  is selected and it models the LAN as a node and everybody is just =
adjacent=20
  to the LAN. So in case of n routers we have just n adjacencies to the =
LAN.=20
  Both these protocols use this same concept. The DR then issues the =
link=20
  state information on behalf of the LAN and ensures reliable =
propagation of=20
  link state information on the LAN. In OSPF, they wanted to optimize /=20
  minimize the failure time if the DR fails, partly because there is=20
  so much overhead involved in becoming adjacent because you have to =
toss=20
  those database packets back and forth. Moreover its disruptive to have =
DR=20
  changes in OSPF since it's the DR who keeps track of which nodes have=20
  acknowledged which link state information and it would require a lot =
of=20
  time and protocol messages for another router to take over in the =
event=20
  that the DR crashed. So OSPF maintains a backup DR which knows to jump =
in=20
  if the main DR goes down without disrupting the network (Backup DR is =
fully=20
  synchronized with the DR). Further more they didn't want the DRship to =
hop=20
  around if when a new router with a higher priority comes along. The=20
  designers of OSPF didn't want that router to become DR because it will =

  disrupt the network and so DRship sticks to the last router who got it =

 =20
 =20
 =20
                                                                [Page 7]
 =20
  (DRship is not deterministic which means, that given the same set of =
the
  participating routers, the same router is not always chosen as the DR) =
and=20
  so if you decide to choose one router arbitrarily to act as a DR then =
its=20
  very difficult to do so in OSPF and the algorithm involved is fairly=20
  complex. The DR election in OSPF is thus sticky, meaning that after a
  router has been elected, no other router can take over that position =
unless=20
  this router dies and goes down.

  In IS-IS everybody just says, "Hey, I am adjacent" because there's so=20
  little overhead in synchronizing the databases. In OSPF you are only=20
  adjacent to the DR and the backup DR and to nobody else on the LAN. In =
IS-
  IS there is a simple DR election scheme in which the router with the=20
  highest priority becomes the DR. If the DR dies (there's no backup DR) =

  everyone has to elect a new DR. The overhead of doing this is just the =
time=20
  to detect that DR has failed because everybody is already synchronized =
with=20
  each other. So there is no huge database exchange to go through. Its=20
  deterministic because its first based on the priority that you =
advertise in=20
  you HELLOs and second by the highest MAC address.=20
 =20
  And If you don't want the DR to hop around when a new router comes up =
with=20
  a higher router priority then there's a solution for that too (as=20
  implemented in NLSP). Whenever a router becomes a DR it pumps up its =
router=20
  priority by 20 points and it effectively makes it sticky and its just =
a few=20
  lines of additional code. If you want the OSPF behaviour, then all the =

  priorities can be set to be within 20 of each other. You can also get=20

  something in between. For e.g., suppose there is a set of powerful =
routers,=20
  and if one of them is up and you'd like it elected. But you want =
sticky=20
  behaviour among that group, and you'd like to elect one router of the=20
  second most powerful group, but only if all the powerful routers are =
dead.=20
  In that case, you set all the priorities in the most powerful group to =
be=20
  21 more than the priorities of any of the other routers.
   =20
  9. LAN Flooding
 =20
  In OSPF there is a whole bunch of per neighbour state which you have =
to=20
  keep if you are the Designated Router. If you are flooding it to n =
routers=20
  then you have to maintain state machine for each of the n routers as =
to who=20
  needs which retransmission, who's active and so on and so forth.

  When a router R has an LSA to propagate on the LAN, it does not =
multicast=20
  that LSA to all the other routers. It instead advertises this to the =
DR and=20
  the BDR only. The DR on receiving the LSA multicasts this to all the=20
  remaining routers. Each router then in turn is expected to multicast =
an ACK=20
  to both the DR and the BDR. If the DR does not receive an ACK from a =
subset=20
  of the routers, it sends explicit copies of the LSA to each router in =
that=20
  subset.
 =20
  This is a bad because a lot of the bandwidth is wasted by sending =
unicast=20
  ACKs back in response to the multicast LSAs which each router =
receives.=20
  Saving half of the packets is not really a great optimization unless=20
  someone is so bandwidth clogged that it cant even support the protocol =
on=20
  the LAN! If that is the case then the admin actually has no business=20
  running the network. Saving half the packets is really a very =
uninteresting=20
  optimization.
 =20
  Then there are these Acknowledgment/Hello suppression schemes which=20
  people wanted to optimize in OSPF because they wanted to optimize the=20
   =20
                                                                [Page 8]

  packet count. There are some rules for not acknowledging under certain =

  conditions and not setting the LS age and so on and so forth. But this =
is=20
  also not very helpful.=20

  In OSPF the more the number of routers you add, more the flooding =
traffic=20
  you get. It grows, as O(n) where n is the number of routers. This is =
so=20
  because of the ACKs which we have to send for each LSA.=20

  OSPF thus causes extra latency for disseminating routing information=20
  because if a router other than the DR is the first to receive an LSA, =
the=20
  LSA cannot immediately be multicast on the LAN to the other routers.=20
  Instead, it must first be transmitted to the DR and the backup DR and =
then=20
  forwarded to the other routers on the LAN. In IS-IS as we shall see, =
the=20
  first router on the LAN that receives the information immediately=20
  multicasts it on the LAN to the other routers.
 =20
  In IS-IS whoever has a new LSP should multicast it on the LAN once to =
a=20
  multicast address to which all the routers listen so that everybody=20
  receives it. There is no explicit acknowledgment. Instead what happens =
is=20
  that the DR periodically multicasts his view of the network (these =
packets=20
  are called CSNPs) and if everybody agrees with his view then nothing =
else=20
  happens but if one of the router's on LAN detects, based on the packet =
sent=20
  by DR,  that the DR is missing something (LSP that this router has) =
then=20
  this router will send the LSP to DR or will flood it on the LAN and=20
  everybody will hear it and update their database. A router on the LAN =
can=20
  detect that the DR has missed an LSP if the LSP is either not listed =
in the=20
  periodic packet sent by DR or if listed with a lower sequence number. =
If a=20
  router detects that the DR has a more recent copy of the LSP than what =
it=20
  has then it explicitly requests the missing LSP by sending a PSNP back =
to=20
  the DR which is basically a request for the required LSP. So now =
everybody=20
  is synchronized and everybody sees a consistent view of the network. =
Under=20
  normal circumstances the flooding traffic is constant regardless of =
the=20
  number of routers because there is one flood and there is one DR =
sending=20
  Complete Sequence Number Packets (CSNP) regardless of how many =
neighbours=20
  it has.=20
 =20
  If there are no changes to the link state information, the IS-IS =
method=20
  requires a constant background rumble of CSNPs, whereas the OSPF =
method,=20
  after all acknowledgements are received, has no further overhead. =
IS-IS=20
  method will prove more effective when there are a lot of routers on =
the LAN=20
  and there is a lot of routing information which needs to be flooded. =
But=20
  then nobody actually puts thousands of routers on a LAN!
 =20
  One interesting issue to consider is the load of flooding and this is =
also=20
  interesting if you have one of these networks that is a full mesh of=20
  ATM/Frame Relay VCs. A number of large ISPs have built networks with =
100s=20
  of them. With 300 routers you have 90,000 (n^2) links! Each of them is =
a=20
  p2p link and the flooding algorithm says that when you receive a new=20
  LSP/LSA you flood it out on every interface you have. So if there are =
300=20
  routers and something happens on any one of the routers then it sends =
it to=20
  299 other routers. Each of these says "Oh! This is new! I need to send =
it=20
  to my neighbours!" and it sends it to other 298 routers. We thus get =
n^2=20
  copies of this information hanging in the network! This is because, to =

  ensure reliability, typical implementations of the flooding algorithm =
send=20
  new information via all interfaces other than the one the new piece of =

  information was received on. This redundancy is required to guarantee =
that=20
  flooding is performed reliably and that all the routers receive the =
new=20
 =20
 =20
                                                                 [Page =
9]
 =20
  information at the earliest and they converge fast enough. This causes =

  considerable overhead in terms of the bandwidth and the CPU cycles if=20
  neighbouring routers are connected with more number of links.=20
 =20
  Moreover if a router does not receive ACKs on some links then it will =
keep=20
  retransmitting unacknowledged LSAs.
 =20
  Each of these packets is O(n) in size (u have n links) because its=20
  typically the router LSA/LSP (which gets bigger with the number of =
routers).=20
  So if a link fails and we get O(n^3) information hanging around.  And =
if=20
  the router fails since its adjacent to everybody else, all of the =
other=20
  routers have to flood their router LSAs or LSPs again. We then get =
O(n^4)=20
  information hanging around!

  Lets see how .. In a full mesh network each LSA is O(n) in size. When =
a=20
  link fails we get O(n^2) copies of size O(n) and thus we have =
information=20
  of O(n^3) hanging around. But when a router fails, every other (n-1) =
router=20
  generates a new LSA of which O(n^2) copies are flooded and since its =
size=20
  is of O(n) we get information of O(n^4) hanging about.
 =20
  Various solutions have come about which attempt to solve this. The =
main=20
  idea is to move the flooding algorithm from the per-interface to per-
  neighbour basis in a backward compatible manner based on the =
observation=20
  that the ultimate goal of the flooding algorithm is not to send link =
state=20
  PDUs over all interfaces, but to deliver them to all routers in the =
network.=20
  These techniques are generic for all the protocols utilizing reliable=20
  flooding.
 =20
  10. Scalability
 =20
  In theory OSPF topology is limited to how much we can stuff in our =
router=20
  LSA as each router gets one router LSA and it cant be bigger than 64K =
for=20
  it's the biggest an IP packet can be.=20
 =20
  Lets us then calculate the number of links that can be advertised (or=20
  "supported" ?) by OSPF. Each link in the router can take up at most 24 =

  bytes and the size of the Router LSA is limited to 64K.=20

  Thus the number of links =3D (64 * 1024) / 24 =3D  2370
=20
  However if we take the minimum link size per link (12 bytes) in the =
Router=20
  LSA, then the maximum is about 2730 * 2 =3D O(5000)
 =20
  To be more specific, for point-to-point and point-to-multipoint =
interfaces=20
  we can have at the most 2730 links (not considering virtual links etc) =
and=20
  for the broadcast and NBMA approx 2 * 2730.

  Thus the Router LSA can carry some 5000 links information in it. =
Though=20
  it's hard to imagine a router with 5000 neighbours to it but we have =
seen=20
  routers with 400 neighbours and it doesn't take long to reach the =
order of=20
  that magnitude. One such scenario I could think of was of a remote =
edge=20
  access box advertising all its caller routes individually. But it's =
kind of=20
  pushing it to other ways as whether is this practical or actually sane =
to=20
  have topology like that. Externals and inter-area routers can have =
billions=20
  of them until you run out of LSA IDs.
 =20
  There is no problem with Network LSA's too. A network LSA is generated =
by
  the DR for each broadcast interface it is connected to. To have =
scaling=20
 =20
                                                                [Page =
10]

  problems for the Network LSA's, we need to have about 2730 * 6 times=20
  neighbours on a particular interface.=20
=20
  This is even less possible and hence there are no scalability issues =
per se
  with OSPF.
 =20
  In IS-IS we are limited by the number of LSPs a single router can =
issue as=20
  each router can issue maximum of 256 LSPs of normally 1470 bytes of =
data=20
  and we have to pack everything we have to advertise into that much. =
And we=20
  shall not run out of space unless one is foolish enough to dump his =
full=20
  BGP routing into IS-IS .. we will then run out of space at about 10% =
of the=20
  way into the redistribution and not be able to advertise the rest.

  We can in fact come up with great interesting hacks like having fake=20
  pseudonodes LAN topology which looks like LAN and all we have to do is =
to=20
  fake this LAN LSP which has zero cost link to us and then we get =
another=20
  turn of 256 LSPs. No other adjacencies are advertised and as a =
consequence=20
  the fake LAN systems are "stub", meaning they can only be reached by =
their=20
  originating system. And if that's not enough we can act like two =
routers=20
  that are adjacent to one another (we can then get 512 LSPs) and as =
long as=20
  we act like what we are advertising then no one can tell. But at the =
end of=20
  the day if we have a slightly sane network then none of it matters. We =

  shouldn't be running out of space.
 =20
  When you flood an entry out into the world it has a life time, and if =
your=20
  router crashes and you die eventually then all the information you =
flooded=20
  will die by itself. But since it dies by itself and if you are still =
alive=20
  then you have to keep refreshing it so that it doesn't die when you =
don't=20
  want it to.
 =20
  Both the protocols have time limited database entries and therefore =
require=20
  refreshing.
 =20
  In IS-IS there is a life time field which says, "This is how long I =
want an=20
  LSP to live". Its 16 bits wide and its in seconds so you get 18.7 =
hours and=20
  on one by one basis you can pick this and send it out. As long as you=20
  refresh it in 18.7 hours you're fine and everything works fine.
 =20
  In OSPF for some reasons they decided to count up rather than down and =
so=20
  the field in OSPF is the age and is set to zero when you send it out =
into=20
  the world.  It is counted upwards and since nobody has been told as to =
how=20
  long it should live; its life is an architectural constant which says =
one=20
  hour. One hour seems like a long time but if in fact you redistribute =
full=20
  routing into OSPF then we'll be refreshing on an average age of 23 ms =
just=20
  with the refresh load and nothing else interesting happening on the =
network.
 =20
  LSAs are refreshed after every 30 minutes =3D 1800 seconds.=20

  After 1800 secs we would have refreshed 80,000 LSAs. Therefore =
assuming=20
  that the LSAs are evenly refreshed we get=20
 =20
  1800/80000 =3D 0.0225 i.e. 80,000 LSAs yield a refresh of every 23ms.
 =20
  Of course doing this is not really great but there is a "do not age" =
LSA=20
  which is created for demand routing which in theory u can press into=20
  service where u can send it out on the network and it looks forever =
and=20
 =20

 =20
                                                                    =
[Page 11]

  never gets aged.
 =20
  But it is not backward compatible and if you deploy this in your =
network=20
  today with some not supporting this then the network will get weird. =
So=20
  there's not much, which can be done unless the entire network is =
changed.=20
   =20
  In the end it's also not very useful.
 =20
  To summarize : Both the protocols are scalable and there should not be =
any=20
  scalability issues with any one them if properly implemented.
 =20

  11. Metrics used
 =20
  One of the big complaints of IS-IS is that in the base spec (ISO =
10589)=20
  link metrics are 6 bits wide which doesn't really give you a lot of=20
  granularity for mapping it into things like link speed, bandwidth and =
those=20
  sort of things. The reason why this was done was that you could make=20
  optimization in your route calculation by allowing the implementers to =
use=20
  a trick during sorting the tentative list during SPF. This would bring =
the=20
  theoretical complexity of SPF from O(n log n) to O(n). But in real =
life=20
  this hardly matters any more since the CPUs are really fast these days =

  and the SPF in the biggest and the scariest networks takes only a few=20
  milliseconds. So its really pointless to keep the metrics this small =
and it=20
  did make it really hard to assign meaningful metrics. So there is a =
wide=20
  metric extension which extends them so they are as or bigger than what =
is=20
  present in OSPF.
 =20
  Another complaint with IS-IS is in terms of how much information which =
goes=20
  into level one area. In OSPF the default is that you send everything =
into=20
  non zero areas so you have optimal routing and you don't have all the=20
  complexity of calculating topology outside the area. You have each=20
  individual routers and you know the best exit points from an area. In =
IS-IS=20
  they went the other way and said that the only thing that we'll =
advertise=20
  to our level 1 router is default and you go to the nearest level 2 =
router=20
  and follow it out to the world. But this may not be the most optimal =
exit=20
  from your area so there's a route leaking extension to IS-IS where we =
now=20
  leak our level 2 routes into level 1 and get optimal routing into the =
area.
 =20
  12. Authentication and Security
 =20
  One of the oft brought up issue with ISIS proponents is apparently the =
big=20
  advantage that IS-IS has over OSPF from a security point of view as =
ISIS=20
  protocol packets cannot be routed beyond the immediate next hop or can =

  never be sourced by non-border routers. This is claimed, can prevent a =

  variety of potential DoS attacks as anyone can launch OSPF packet =
bombs in=20
  the others network. This apparent vulnerability to DoS attacks is =
because=20
  OSPF rides over IP rather than directly running on the link layer.=20
 =20
  Since all OSPF packets can be authenticated using MD5, all spurious =
OSPF
  packets can be dropped. But there can be times when MD5 can itself be =
a=20
  part of a problem because it takes significant CPU to check signatures =
and=20
  discard the packets. This is partly true but it is to be noted however =
that=20
  even if OSPF encapsulation is changed to L2, we would still have to =
support=20
  IP encapsulation for virtual links, so we would still have to do MD5.=20
  Moreover the system administrator can filter on the edges of the =
network to=20
  pry away all the OSPF messages coming from the edges. This will of =
course=20
  be done in addition to cryptography.=20
 =20
 =20
                                                                    =
[Page 12]

  13. MPLS/GMPLS and Traffic Engineering Extensions
 =20
  There are MPLS/GMPLS extensions to both the protocols and in fact are=20
  almost identical. The idea is that you're carrying around this extra =
link=20
  information like how much bandwidth is available on this link, what =
policy=20
  colour is this link, etc. We use the routing protocol as a mule to =
carry=20
  around all this data around and then there is a separate traffic=20
  engineering model which is not a part of the protocol. These protocols =

  carry around TE link info on behalf of MPLS but don't use the data
  themselves. Both the routing protocols act as a convenient flooding
  mechanism for conveying different types of information that is =
essentially=20
  "don=92t care" for the protocols themselves. New drafts call for data =
to be=20
  added to the LSA/LSPs that may be of interest to other entities, such =
as=20
  MPLS/GMPLS or a constrained based SPF, but would not make any =
difference to=20
  the normal SPF run on these routing protocols.
     =20
  14. Ipv6 Support

  "Integrated IS-IS" is just a bunch of extensions. Extra TLVs have been
  added so that IS-IS may carry IP information. IS-IS can easily be=20
  extended to carry routing information for IPv6 or any for that matter =
any=20
  Layer 3 protocol. Have a look at NLSP, and we can see ISIS carrying =
IPX=20
  routes and SAPs. Unfortunately Novell defined NLSP in such a way that =
it
  is incompatible with ISIS.
 =20
  IS-IS as described in ISO document 10589, defines the base structures
  of the protocol (adjacencies, flooding, etc). Unfortunately it also
  defines lots of CLNS specific TLVs. So it looks like ISIS is a routing
  protocol for CLNS, and the IP thing is an add on. That is partly true,
  but the ability to carry routing info for any Layer 3 protocol is a
  well designed feature. I suspect IS-IS might be easier to understand
  if the CLNS specific part was separated from the base protocol.
 =20
  IS-IS is "Ipv6" ready and can be coded for this extension in a matter =
of=20
  weeks since the TCP/IP based version of IS-IS is totally TLV encoded. =
It is=20
  just a matter of adding a few more TLVs to support Ipv6.


  OSPF as suggested earlier has been tailor made exclusively for IPv4 =
and=20
  was never made to be extensible. Extending it to the next version is =
no=20
  easy task. The fact is that it has already been done, but the downside =
is=20
  that the new protocol does not at all look like an extension to the=20
  previous version.=20

  It is for this reason that they probably refer to it as OSPFv3.

  15. List of Abbreviations

  ACK - Acknowledgement
  BDR - Backup Designated Router
  CSNP - Complete Sequence Number Packet
  DBD - Database Description Packet
  DOS - Denial Of Service=20
  DR - Designated Router
  IETF- Internet Engineering Task Force
  IGP- Interior Gateway Protocol
  IP - Internet Protocol
  ISIS - Intermediate System to Intermediate System
  LAN - Local Area Network
                                                                  [Page =
13]
 =20
  LSA - Link State Advertisement
  LSP - Link State Packet
  MD5 - Message Digest 5
  MPLS - Multiprotocol Label Switching
  MTU - Mean Transfer Unit
  NBMA - Non Broadcast Multi Access
  OSI - Open System Interconnect
  OSPF - Open Shortest Path First
  p2mp - Point to Multi Point
  p2p - Point To Point
  PDU - Protocol Datagram Unit
  PSNP - Partial Sequence Number Packet
  SPF - Shortest Path First
  TCP - Transmission Control Protocol
  TE - Traffic Extensions
  TLV - Tag Length Value

  References
 =20
  - ISO/IEC 10589, "Intermediate System to Intermediate System =
Intra-Domain=20
  Routing Exchange Protocol for use in Conjunction with the Protocol for =

  Providing the Connectionless-mode Network Service (ISO 8473)", June =
1992

  - RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual =
environments",=20
  R.W. Callon, Dec 1990

  - Amir Hermelin , "Extending the Number of IS-IS LSP Fragments beyond =
the
  256 Limit",  February 2002, Work in Progress

  - Christian E. Hopps, "Routing IPv6 with IS-IS", April 2001, Work in =
Progress

  - Radia Perlman, "Interconnections, Second Edition: Bridges, Routers,=20
  Switches, and Internetworking Protocols",  Addison Wesley Longman,
  ISBN 81-7808-428-7
 =20
  - RFC 1793, "Extending OSPF to Support Demand Circuits", J. Moy, April =
1995

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

  - A. Zinin, Mike Shand, "Flooding optimizations in link-state routing=20
  protocols", September 2001, Work in Progress
 =20
  - Dave Katz, "OSPF and IS-IS : A comparative Study", Nanog, June 2000

  - John Moy, "Anatomy of an Internet Routing Protocol", Addison Wesley =
Longman,
  ISBN 0-201-63472-4

  - D. Katz, D. Yeung, K. Kompella, "Traffic Engineering Extensions to =
OSPF v2",
  February 2003, Work in Progress

16. Authors Address

    Manav Bhatia
    Samsung India Software Operations,
    Samsung Digital House,
    No. 67, Infantry Road,
    Bangalore, Karnataka,
    India - 560001

    email: manav@samsung.com


--Boundary_(ID_Kd0ulBDj59TVNF4RytiTfA)--


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep  4 06:23:06 2002
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 GAA21861
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 Sep 2002 06:23:05 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00700E73@cherry.ease.lsoft.com>; Wed, 4 Sep 2002 6:24:39 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 138812 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 4 Sep 2002 06:24:39 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 4 Sep 2002 06:24:39 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0AQHS>; Wed, 4 Sep 2002 06:24:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A32879153F@india_exch.hyderabad.mindspeed.com>
Date:         Wed, 4 Sep 2002 06:26:47 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Manav/Others,

A few of us have been working to form a group for the same, I have a list of
topics that we would probably want to discuss which contains a list of
topics besides the mentioned, which I will be willing to pass along in
private to anyone. Manav or anyone else who would want to help in in the
effort please mail me, I will add you to the list which I intend to make.

I intend to send a similar mail to the ISIS group too.

Thanks,
Vishwas

-----Original Message-----
From: Manav Bhatia [mailto:manav@SAMSUNG.COM]
Sent: Wednesday, September 04, 2002 3:43 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Paper comparing OSPF and ISIS


Hi,
The question of OSPF vis-a-vis IS-IS has been raised more than once in the
mailing lists (both OSPF and ISIS) and elsewhere and there seems to be no
apparent paper which clearly differentiates between the two. I started with
IS-IS and moved to OSPF some time back, and in my quest stumbled upon Dave
Katz presentation on the same. In my course of transitioning to OSPF I had
written a lot of notes and ideas (borrowed from Dave presentation and some
helpful cues which i took from Radia Perlman's "Interconnections") on the
key differences between these 2 link state routing protocols.

I have assimilated all of those in this document which i am hereby
attaching with this mail of mine. I would like to hear from other people
their views/thoughts/experiences with these protocols and i intended to
capture all that in the updated document which can then be used as a
reference in understanding as to how/what/where the two link state routing
protocols differ.

Manav


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep  4 09:40:12 2002
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 JAA28670
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 Sep 2002 09:40:11 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00701A08@cherry.ease.lsoft.com>; Wed, 4 Sep 2002 9:41:45 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 139559 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 4 Sep 2002 09:41:45 -0400
Received: from 216.136.173.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 4 Sep 2002 09:41:45 -0400
Received: from [203.200.20.226] by web12408.mail.yahoo.com via HTTP; Wed, 04
          Sep 2002 06:41:44 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020904134144.91048.qmail@web12408.mail.yahoo.com>
Date:         Wed, 4 Sep 2002 06:41:44 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Rohit Gupta <rohitgupta416@YAHOO.COM>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <078f01c253fb$9a1e2a00$b4036c6b@sisodomain.com>
Precedence: list

Hi,
I just went thru your paper on comparing ISIS and OSPF
and i could not understand how TCP ACK came into
picture when comparing two link state routing
protocols?

In Section where you describe the encapsulation you
mention that there is some problem in IS-IS and you
waste additional bandwith?

Please Help ..

-- Rohit

--- Manav Bhatia <manav@SAMSUNG.COM> wrote:
> Hi,
> The question of OSPF vis-a-vis IS-IS has been raised
> more than once in the
> mailing lists (both OSPF and ISIS) and elsewhere and
> there seems to be no
> apparent paper which clearly differentiates between
> the two. I started with
> IS-IS and moved to OSPF some time back, and in my
> quest stumbled upon Dave
> Katz presentation on the same. In my course of
> transitioning to OSPF I had
> written a lot of notes and ideas (borrowed from Dave
> presentation and some
> helpful cues which i took from Radia Perlman's
> "Interconnections") on the
> key differences between these 2 link state routing
> protocols.
>
> I have assimilated all of those in this document
> which i am hereby
> attaching with this mail of mine. I would like to
> hear from other people
> their views/thoughts/experiences with these
> protocols and i intended to
> capture all that in the updated document which can
> then be used as a
> reference in understanding as to how/what/where the
> two link state routing
> protocols differ.
>
> Manav
>
> ----
> "When you are courting a nice girl an hour seems
> like a second. When you
> sit on a red-hot cinder a second seems like an hour.
> That's relativity."
>
> -Albert Einstein, on relativity
>
> >

>      Manav Bhatia
>
>      Samsung Electronics
>
>      September 2002
>
>               A Comparative Study of OSPF and IS-IS
>
>   There are two link state routing protocols
> available. One is the
>   IS-IS developed by ISO exclusively for the ISO
> networks and the other
>   is OSPF developed by the IETF because the former
> did not, originally run
>   on TCP/IP networks. Since then many changes have
> come in both the
>   routing protocols. IETF has come out with the
> Integrated IS-IS which runs
>   IS-IS for TCP/IP networks.
>
>   This document compares the two link state routing
> protocols in each
>   area of the specification and also compares the
> two link state
>   routing protocols in terms of the scalability
> issues.
>
>   This document compares the two routing protocols
> in terms of
>
>   1. Encapsulation
>   2. Network Types Supported
>   3. Partition Repair
>   4. Packet Encoding
>   5. Data base granularity
>   6. Neighbour Establishment
>
>   7. Designated Router Concept
>   8. LAN Flooding
>   9. Scalability Issues
>   10. Metrics Used
>   11. Authentication and Security
>   12. MPLS/GMPLS and Traffic Engineering Extensions
>   13. Support for Ipv6
>
>   There is a list of abbreviations used at the end
> of this document
>
>   1. Introduction
>
>   In essence each router distributes its view of the
> local neighbourhood
>   and floods it within the area within the network
> and every other
>   router ends up with a map of the topology (the
> information in the LSPs
>   yields complete knowledge of the graph) and then
> routes are computed
>   based on the map each has by running the
> Dijkstra's algorithm on the
>   LSD. Both the link state routing protocols have a
> 2 level hierarchy.
>   In OSPF there is this concept of a backbone area
> and a non zero area.
>   In IS-IS, there are level 1 and level 2 areas.
> Both of the routing
>   protocols are widely deployed in the field.
>
>   We could have actually gone ahead with one
> protocol (IS-IS) wherein
>   extending and adapting IS-IS for IP was possible
> by merely adding IP
>   reachability information along with the existing
> model. Incidentally
>   this is what Integrated IS-IS does (RFC 1195) but
> nobody thought of it
>   before and in the mean time work on OSPF had
> already gained momentum.
>   Moreover people wanted an "IPv4" only protocol
> which was very much
>   optimised and directed towards IPv4 and one which
> would have all
>   mechanisms to make the adjacencies come up faster
> on the IP networks.
>   OSPF was thus designed specifically for IP (rather
> IPv4!) and is
>   loosely based on IS-IS.
>
>
>
>
>              [Page 1]
>
>   The repercussions of having an "IPv4" only
> protocol become clear in the
>   following sections for it obviously introduces
> some amount of complexity in
>   the protocol. IS-IS is a lot simpler but then it
> was never designed for IP
>   so we have some strange things like assigning OSI
> addresses to our IP only
>   router. This often confuses people and everyone
> ends up making calls to the
>   customer support centre.
>
>   2. Encapsulation
>
>   OSPF runs over IP and as a result of which we can
> have virtual links.
>   This implies that we can send an OSPF packet from
> one part of the planet
>   to the other. The downside of this is that it
> makes OSPF vulnerable to the
>   classic DoS (discussed at length in later
> sections) attacks and all such
>   related attacks.
>
>   If LSAs get really big then we can have IP
> fragmentation to make them fit.
>   One of the advantages of using IP encapsulation is
> that we can use VCmux
>   encaps on ATM. This is basically no encapsulation
> and everything on the
>   VC has to be necessarily IP. So if you're running
> OSPF on ATM then you
>   can turn off all encapsulations and save on the
> bandwidth in the ATM
>   network.
>
>   IS-IS on the other hand runs directly over layer 2
> i.e. next to IP, which
>   means that we cant have virtual links unless we
> have some sort of
>   explicit tunnelling. Since it does not run on IP
> these packets cannot be
>   routed beyond the immediate next hop and can never
> be sourced by non-border
>   routers. This makes ISIS difficult to spoof
> because there's now no way
>   to get an IS-IS packet into the inside of your
> network from outside
>   (because its not an IP packet) unless you
> accidentally let a GRE tunnel
>   remain open or something.
>
>   IS-IS requires ATM SNAP encapsulation because its
> not an IP packet thereby
>   loosing on the bandwidth efficiency we have with
> OSPF. This adds enough
>   bytes so a TCP ACK won't fit into one ATM cell (it
> does in OSPF). We thus
>   waste some extra bandwidth.
>
>   Suggestions to run OSPF directly over data link
> layer has the inherent
>   problem where we need to provide code points of
> access in OSPF for each
>   of the data link protocol types. For e.g.
> (Frame-relay, Ethernet, ATM,
>   PPP etc).
>
>   Moreover, most of the link layers don't provide
> fragmentation and
>   reassembly services. IP (not as a protocol but as
> a technology) supports
>   virtually all Layer 2 (except X.25). So the
> protocols running over IP need
>   not worry about services offered by IP. There are
> definite (dis)advantages
>   if we run OSPF directly over L2 but advantages
> overweigh. Once again ,
>   virtual links (widely used) are not possible if we
> run OSPF over Layer 2.
>   For these reasons it is better to run OSPF over
> IP.
>
>   Refer to John Moy's book section 3.2 Design
> Decisions for more details.
>
>   The other obvious advantage of running over IP is
> the ability to use IP
>   multicast when running over broadcast networks.
>
>   Also, one nice feature about IP encapsulation of
> OSPF packets is that it
>   tests processing of IP packets on the interfaces.
> I've seen routers not
>   being able to process IP packets on interfaces,
> but still maintaining ISIS
>
>
>
>              [Page 2]
>
>   adjacencies, so the rest of the network still used
> the link. This is not
>   possible in OSPF where the HELLO protocol ensures
> that communication
>   between the neighbours is bidirectional.
>
>
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep  4 10:05:27 2002
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 KAA00306
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 Sep 2002 10:05:26 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00701CA6@cherry.ease.lsoft.com>; Wed, 4 Sep 2002 10:07:01 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 139672 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 4 Sep 2002 10:07:01 -0400
Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 4 Sep 2002 10:07:01 -0400
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
          (iPlanet Messaging Server 5.1 (built Sep  5 2001)) id
          <0H1X006013EFPR@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 04 Sep 2002 23:11:03 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet
          Messaging Server 5.1 (built Sep  5 2001)) with ESMTP id
          <0H1X006423EFHK@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 04 Sep 2002 23:11:03 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging
          Server 5.1 (built Sep  5 2001)) with ESMTPA id
          <0H1X00L6Y3F1IG@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 04 Sep 2002 23:11:27 +0900 (KST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <20020904134144.91048.qmail@web12408.mail.yahoo.com>
Message-ID:  <00c901c2541c$5a427f00$b4036c6b@sisodomain.com>
Date:         Wed, 4 Sep 2002 19:37:05 +0530
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Manav Bhatia <manav@SAMSUNG.COM>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7BIT

Rohit,
In ATM VC multiplexing (null encapsulation) there is no SNAP header and
hence no additional overhead in the cell.  As the name suggests, in
LLC/SNAP encaps we store LLC-SNAP information in the cell resulting in a
packet size > 40 bytes. Now, a simple TCP ACK message is of 40 bytes.
LLC/SNAP header adds 3 more bytes. AAL5 adds an additional 8 bytes in
either case. ATM LLC/SNAP encapsulation thus adds enough bytes so that a
TCP ACK wont fit into one ATM cell!

Thus if we know that we are using only IP then it is better to go in for VC
mux encaps because we save a lot of bandwidth.

IS-IS requires ATM LLC/SNAP encapsulation because its not an IP packet
thereby loosing on the bandwidth efficiency we have with OSPF.

I hope it makes it clear.

Regards,
Manav

----- Original Message -----
From: "Rohit Gupta" <rohitgupta416@YAHOO.COM>
To: <OSPF@DISCUSS.MICROSOFT.COM>
Sent: Wednesday, September 04, 2002 7:11 PM
Subject: Re: Paper comparing OSPF and ISIS


| Hi,
| I just went thru your paper on comparing ISIS and OSPF
| and i could not understand how TCP ACK came into
| picture when comparing two link state routing
| protocols?
|
| In Section where you describe the encapsulation you
| mention that there is some problem in IS-IS and you
| waste additional bandwith?
|
| Please Help ..
|
| -- Rohit
|
| --- Manav Bhatia <manav@SAMSUNG.COM> wrote:
| > Hi,
| > The question of OSPF vis-a-vis IS-IS has been raised
| > more than once in the
| > mailing lists (both OSPF and ISIS) and elsewhere and
| > there seems to be no
| > apparent paper which clearly differentiates between
| > the two. I started with
| > IS-IS and moved to OSPF some time back, and in my
| > quest stumbled upon Dave
| > Katz presentation on the same. In my course of
| > transitioning to OSPF I had
| > written a lot of notes and ideas (borrowed from Dave
| > presentation and some
| > helpful cues which i took from Radia Perlman's
| > "Interconnections") on the
| > key differences between these 2 link state routing
| > protocols.
| >
| > I have assimilated all of those in this document
| > which i am hereby
| > attaching with this mail of mine. I would like to
| > hear from other people
| > their views/thoughts/experiences with these
| > protocols and i intended to
| > capture all that in the updated document which can
| > then be used as a
| > reference in understanding as to how/what/where the
| > two link state routing
| > protocols differ.
| >
| > Manav
| >
| > ----
| > "When you are courting a nice girl an hour seems
| > like a second. When you
| > sit on a red-hot cinder a second seems like an hour.
| > That's relativity."
| >
| > -Albert Einstein, on relativity
| >
| > >
|
| >      Manav Bhatia
| >
| >      Samsung Electronics
| >
| >      September 2002
| >
| >               A Comparative Study of OSPF and IS-IS
| >
| >   There are two link state routing protocols
| > available. One is the
| >   IS-IS developed by ISO exclusively for the ISO
| > networks and the other
| >   is OSPF developed by the IETF because the former
| > did not, originally run
| >   on TCP/IP networks. Since then many changes have
| > come in both the
| >   routing protocols. IETF has come out with the
| > Integrated IS-IS which runs
| >   IS-IS for TCP/IP networks.
| >
| >   This document compares the two link state routing
| > protocols in each
| >   area of the specification and also compares the
| > two link state
| >   routing protocols in terms of the scalability
| > issues.
| >
| >   This document compares the two routing protocols
| > in terms of
| >
| >   1. Encapsulation
| >   2. Network Types Supported
| >   3. Partition Repair
| >   4. Packet Encoding
| >   5. Data base granularity
| >   6. Neighbour Establishment
| >
| >   7. Designated Router Concept
| >   8. LAN Flooding
| >   9. Scalability Issues
| >   10. Metrics Used
| >   11. Authentication and Security
| >   12. MPLS/GMPLS and Traffic Engineering Extensions
| >   13. Support for Ipv6
| >
| >   There is a list of abbreviations used at the end
| > of this document
| >
| >   1. Introduction
| >
| >   In essence each router distributes its view of the
| > local neighbourhood
| >   and floods it within the area within the network
| > and every other
| >   router ends up with a map of the topology (the
| > information in the LSPs
| >   yields complete knowledge of the graph) and then
| > routes are computed
| >   based on the map each has by running the
| > Dijkstra's algorithm on the
| >   LSD. Both the link state routing protocols have a
| > 2 level hierarchy.
| >   In OSPF there is this concept of a backbone area
| > and a non zero area.
| >   In IS-IS, there are level 1 and level 2 areas.
| > Both of the routing
| >   protocols are widely deployed in the field.
| >
| >   We could have actually gone ahead with one
| > protocol (IS-IS) wherein
| >   extending and adapting IS-IS for IP was possible
| > by merely adding IP
| >   reachability information along with the existing
| > model. Incidentally
| >   this is what Integrated IS-IS does (RFC 1195) but
| > nobody thought of it
| >   before and in the mean time work on OSPF had
| > already gained momentum.
| >   Moreover people wanted an "IPv4" only protocol
| > which was very much
| >   optimised and directed towards IPv4 and one which
| > would have all
| >   mechanisms to make the adjacencies come up faster
| > on the IP networks.
| >   OSPF was thus designed specifically for IP (rather
| > IPv4!) and is
| >   loosely based on IS-IS.
| >
| >
| >
| >
| >              [Page 1]
| >
| >   The repercussions of having an "IPv4" only
| > protocol become clear in the
| >   following sections for it obviously introduces
| > some amount of complexity in
| >   the protocol. IS-IS is a lot simpler but then it
| > was never designed for IP
| >   so we have some strange things like assigning OSI
| > addresses to our IP only
| >   router. This often confuses people and everyone
| > ends up making calls to the
| >   customer support centre.
| >
| >   2. Encapsulation
| >
| >   OSPF runs over IP and as a result of which we can
| > have virtual links.
| >   This implies that we can send an OSPF packet from
| > one part of the planet
| >   to the other. The downside of this is that it
| > makes OSPF vulnerable to the
| >   classic DoS (discussed at length in later
| > sections) attacks and all such
| >   related attacks.
| >
| >   If LSAs get really big then we can have IP
| > fragmentation to make them fit.
| >   One of the advantages of using IP encapsulation is
| > that we can use VCmux
| >   encaps on ATM. This is basically no encapsulation
| > and everything on the
| >   VC has to be necessarily IP. So if you're running
| > OSPF on ATM then you
| >   can turn off all encapsulations and save on the
| > bandwidth in the ATM
| >   network.
| >
| >   IS-IS on the other hand runs directly over layer 2
| > i.e. next to IP, which
| >   means that we cant have virtual links unless we
| > have some sort of
| >   explicit tunnelling. Since it does not run on IP
| > these packets cannot be
| >   routed beyond the immediate next hop and can never
| > be sourced by non-border
| >   routers. This makes ISIS difficult to spoof
| > because there's now no way
| >   to get an IS-IS packet into the inside of your
| > network from outside
| >   (because its not an IP packet) unless you
| > accidentally let a GRE tunnel
| >   remain open or something.
| >
| >   IS-IS requires ATM SNAP encapsulation because its
| > not an IP packet thereby
| >   loosing on the bandwidth efficiency we have with
| > OSPF. This adds enough
| >   bytes so a TCP ACK won't fit into one ATM cell (it
| > does in OSPF). We thus
| >   waste some extra bandwidth.
| >
| >   Suggestions to run OSPF directly over data link
| > layer has the inherent
| >   problem where we need to provide code points of
| > access in OSPF for each
| >   of the data link protocol types. For e.g.
| > (Frame-relay, Ethernet, ATM,
| >   PPP etc).
| >
| >   Moreover, most of the link layers don't provide
| > fragmentation and
| >   reassembly services. IP (not as a protocol but as
| > a technology) supports
| >   virtually all Layer 2 (except X.25). So the
| > protocols running over IP need
| >   not worry about services offered by IP. There are
| > definite (dis)advantages
| >   if we run OSPF directly over L2 but advantages
| > overweigh. Once again ,
| >   virtual links (widely used) are not possible if we
| > run OSPF over Layer 2.
| >   For these reasons it is better to run OSPF over
| > IP.
| >
| >   Refer to John Moy's book section 3.2 Design
| > Decisions for more details.
| >
| >   The other obvious advantage of running over IP is
| > the ability to use IP
| >   multicast when running over broadcast networks.
| >
| >   Also, one nice feature about IP encapsulation of
| > OSPF packets is that it
| >   tests processing of IP packets on the interfaces.
| > I've seen routers not
| >   being able to process IP packets on interfaces,
| > but still maintaining ISIS
| >
| >
| >
| >              [Page 2]
| >
| >   adjacencies, so the rest of the network still used
| > the link. This is not
| >   possible in OSPF where the HELLO protocol ensures
| > that communication
| >   between the neighbours is bidirectional.
| >
| >
| === message truncated ===
|
|
| __________________________________________________
| Do You Yahoo!?
| Yahoo! Finance - Get real-time stock quotes
| http://finance.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep  4 10:13:27 2002
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 KAA00737
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 Sep 2002 10:13:26 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00701C24@cherry.ease.lsoft.com>; Wed, 4 Sep 2002 10:15:01 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 139715 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 4 Sep 2002 10:15:01 -0400
Received: from 216.136.173.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 4 Sep 2002 10:15:01 -0400
Received: from [203.200.20.226] by web12404.mail.yahoo.com via HTTP; Wed, 04
          Sep 2002 07:14:59 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020904141459.52822.qmail@web12404.mail.yahoo.com>
Date:         Wed, 4 Sep 2002 07:14:59 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Rohit Gupta <rohitgupta416@YAHOO.COM>
Subject: Re: Paper comparing OSPF and ISIS
Comments: cc: manav@samsung.com
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <00c901c2541c$5a427f00$b4036c6b@sisodomain.com>
Precedence: list

Hi Manav,
Thanks for the prompt reply !!
I was just getting confused with how TCP came in
between ISIS and OSPF!

Can we make this paper some sort of informational
draft/working group paper after everyone has given his
inputs so that everybody has access to it and it keeps
getting updated because such papers are very useful
and very difficult to find! :-)

just my two cents :-)

-- Rohit





















--- Manav Bhatia <manav@SAMSUNG.COM> wrote:
> Rohit,
> In ATM VC multiplexing (null encapsulation) there is
> no SNAP header and
> hence no additional overhead in the cell.  As the
> name suggests, in
> LLC/SNAP encaps we store LLC-SNAP information in the
> cell resulting in a
> packet size > 40 bytes. Now, a simple TCP ACK
> message is of 40 bytes.
> LLC/SNAP header adds 3 more bytes. AAL5 adds an
> additional 8 bytes in
> either case. ATM LLC/SNAP encapsulation thus adds
> enough bytes so that a
> TCP ACK wont fit into one ATM cell!
>
> Thus if we know that we are using only IP then it is
> better to go in for VC
> mux encaps because we save a lot of bandwidth.
>
> IS-IS requires ATM LLC/SNAP encapsulation because
> its not an IP packet
> thereby loosing on the bandwidth efficiency we have
> with OSPF.
>
> I hope it makes it clear.
>
> Regards,
> Manav
>
> ----- Original Message -----
> From: "Rohit Gupta" <rohitgupta416@YAHOO.COM>
> To: <OSPF@DISCUSS.MICROSOFT.COM>
> Sent: Wednesday, September 04, 2002 7:11 PM
> Subject: Re: Paper comparing OSPF and ISIS
>
>
> | Hi,
> | I just went thru your paper on comparing ISIS and
> OSPF
> | and i could not understand how TCP ACK came into
> | picture when comparing two link state routing
> | protocols?
> |
> | In Section where you describe the encapsulation
> you
> | mention that there is some problem in IS-IS and
> you
> | waste additional bandwith?
> |
> | Please Help ..
> |
> | -- Rohit
> |
> | --- Manav Bhatia <manav@SAMSUNG.COM> wrote:
> | > Hi,
> | > The question of OSPF vis-a-vis IS-IS has been
> raised
> | > more than once in the
> | > mailing lists (both OSPF and ISIS) and elsewhere
> and
> | > there seems to be no
> | > apparent paper which clearly differentiates
> between
> | > the two. I started with
> | > IS-IS and moved to OSPF some time back, and in
> my
> | > quest stumbled upon Dave
> | > Katz presentation on the same. In my course of
> | > transitioning to OSPF I had
> | > written a lot of notes and ideas (borrowed from
> Dave
> | > presentation and some
> | > helpful cues which i took from Radia Perlman's
> | > "Interconnections") on the
> | > key differences between these 2 link state
> routing
> | > protocols.
> | >
> | > I have assimilated all of those in this document
> | > which i am hereby
> | > attaching with this mail of mine. I would like
> to
> | > hear from other people
> | > their views/thoughts/experiences with these
> | > protocols and i intended to
> | > capture all that in the updated document which
> can
> | > then be used as a
> | > reference in understanding as to how/what/where
> the
> | > two link state routing
> | > protocols differ.
> | >
> | > Manav
> | >
> | > ----
> | > "When you are courting a nice girl an hour seems
> | > like a second. When you
> | > sit on a red-hot cinder a second seems like an
> hour.
> | > That's relativity."
> | >
> | > -Albert Einstein, on relativity
> | >
> | > >
> |
> | >      Manav Bhatia
> | >
> | >      Samsung Electronics
> | >
> | >      September 2002
> | >
> | >               A Comparative Study of OSPF and
> IS-IS
> | >
> | >   There are two link state routing protocols
> | > available. One is the
> | >   IS-IS developed by ISO exclusively for the ISO
> | > networks and the other
> | >   is OSPF developed by the IETF because the
> former
> | > did not, originally run
> | >   on TCP/IP networks. Since then many changes
> have
> | > come in both the
> | >   routing protocols. IETF has come out with the
> | > Integrated IS-IS which runs
> | >   IS-IS for TCP/IP networks.
> | >
> | >   This document compares the two link state
> routing
> | > protocols in each
> | >   area of the specification and also compares
> the
> | > two link state
> | >   routing protocols in terms of the scalability
> | > issues.
> | >
> | >   This document compares the two routing
> protocols
> | > in terms of
> | >
> | >   1. Encapsulation
> | >   2. Network Types Supported
> | >   3. Partition Repair
> | >   4. Packet Encoding
> | >   5. Data base granularity
> | >   6. Neighbour Establishment
> | >
> | >   7. Designated Router Concept
> | >   8. LAN Flooding
> | >   9. Scalability Issues
> | >   10. Metrics Used
> | >   11. Authentication and Security
> | >   12. MPLS/GMPLS and Traffic Engineering
> Extensions
> | >   13. Support for Ipv6
> | >
> | >   There is a list of abbreviations used at the
> end
> | > of this document
> | >
> | >   1. Introduction
> | >
> | >   In essence each router distributes its view of
> the
> | > local neighbourhood
> | >   and floods it within the area within the
> network
> | > and every other
> | >   router ends up with a map of the topology (the
> | > information in the LSPs
> | >   yields complete knowledge of the graph) and
> then
> | > routes are computed
> | >   based on the map each has by running the
> | > Dijkstra's algorithm on the
> | >   LSD. Both the link state routing protocols
> have a
> | > 2 level hierarchy.
> | >   In OSPF there is this concept of a backbone
> area
> | > and a non zero area.
> | >   In IS-IS, there are level 1 and level 2 areas.
> | > Both of the routing
> | >   protocols are widely deployed in the field.
> | >
> | >   We could have actually gone ahead with one
> | > protocol (IS-IS) wherein
> | >   extending and adapting IS-IS for IP was
> possible
> | > by merely adding IP
> | >   reachability information along with the
> existing
> | > model. Incidentally
> | >   this is what Integrated IS-IS does (RFC 1195)
> but
> | > nobody thought of it
> | >   before and in the mean time work on OSPF had
> | > already gained momentum.
> | >   Moreover people wanted an "IPv4" only protocol
>
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep  4 12:23:57 2002
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 MAA08063
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 Sep 2002 12:23:57 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00701FC0@cherry.ease.lsoft.com>; Wed, 4 Sep 2002 12:18:17 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 140090 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 4 Sep 2002 12:18:16 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 4 Sep 2002 12:18:16 -0400
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g84GIFm27954 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 4 Sep 2002 09:18:15 -0700 (PDT)
          (envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id
          g84GIF429584; Wed, 4 Sep 2002 09:18:15 -0700 (PDT) (envelope-from
          dkatz@cirrus.juniper.net)
References: <20020904134144.91048.qmail@web12408.mail.yahoo.com>
            <00c901c2541c$5a427f00$b4036c6b@sisodomain.com>
Message-ID:  <200209041618.g84GIF429584@cirrus.juniper.net>
Date:         Wed, 4 Sep 2002 09:18:15 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Dave Katz <dkatz@JUNIPER.NET>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <00c901c2541c$5a427f00$b4036c6b@sisodomain.com> (message from
              Manav Bhatia on Wed, 4 Sep 2002 19:37:05 +0530)
Precedence: list

Actually this is not true;  there is the infamous "Henk Hack" whereby
you can run ISIS over a VCMUX PVC:  you do protocol identification based
on the first byte of the packet.  0x83 (IIRC) is IS-IS, 0x4x is IP.  It's
a NLPID stood on its head.

I don't know that anybody has implemented this, though we've considered it;
mostly it took the wind out of the sails of ISIS-over-IP.

   IS-IS requires ATM LLC/SNAP encapsulation because its not an IP packet
   thereby loosing on the bandwidth efficiency we have with OSPF.


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep  4 12:43:07 2002
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 MAA09113
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 Sep 2002 12:43:07 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00702152@cherry.ease.lsoft.com>; Wed, 4 Sep 2002 12:36:39 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 140171 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 4 Sep 2002 12:36:39 -0400
Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 4 Sep 2002 12:36:37 -0400
Received: from user-2ivfk6c.dialup.mindspring.com ([165.247.208.204]
          helo=earthlink.net) by snipe.mail.pas.earthlink.net with esmtp (Exim
          3.33 #1) id 17md8q-0007O9-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 04
          Sep 2002 09:36:33 -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: <125DE5BA.2F9F561C.0004D071@aol.com> <3D74CE1A.6080907@redback.com>
            <20020903114832.B25223@demiurge.exodus.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D763982.576B1590@earthlink.net>
Date:         Wed, 4 Sep 2002 09:49:06 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: OSPF multiple process
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Group,

        And I know of a a a well known company implimentation   that I believe
has used at least a three process
        OSPF implimentation for 7+ years : main, hello, and a scanner.

        Mitchell Erblich
        PS: Someone said that we should keep discussions company
            neutral..
        Staff Kernel / IP Routing Protocol Engineer
        ==============================================

Andrew Lange wrote:
>
> In fact, the Exodus network has used multiple OSPF processes for a number
> of years.  It has worked just fine.
>
> Andrew
>
> On Tue, Sep 03, 2002 at 10:58:34AM -0400, Acee Lindem wrote:
> > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
> >             Netscape6/6.2.3
> > X-Accept-Language: en-us
> > Date:         Tue, 3 Sep 2002 10:58:34 -0400
> > Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
> > From: Acee Lindem <acee@REDBACK.COM>
> > Subject: Re: OSPF multiple process
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Precedence: list
> > X-OriginalArrivalTime: 03 Sep 2002 15:03:11.0482 (UTC) FILETIME=[053D2DA0:01C2535B]
> >
> > Javed Syed wrote:
> >
> > > Hi,
> > >
> > > I would like to know if anybody have seen or aware of any good document explaining why it is not recommended to run multiple OSPF processor in the same router.
> > > I have seens many emails regarding this issue.
> >
> > > I have seen people running two processor only if it is absolute necessary and to make each node acting as a multiple node for load balancing.
> > > Any comments will be appreciated.
> >
> >
> > JS,
> >
> > I think the fear of multiple OSPF process dates back to days of routers
> > with less than 100 MHz processors and only a couple megs of memory. At
> > that time, many thought that the scaling/scheduling/debuging issues
> > associated with multiple link state protocol instances were intractable.
> > I doubt you'll encouter the same trepidation today.
> >
> >
> > >
> > > JS
> > >
> > >
> >
> >
> > --
> > Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep  4 12:49:22 2002
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 MAA09537
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 Sep 2002 12:49:22 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.007021B3@cherry.ease.lsoft.com>; Wed, 4 Sep 2002 12:50:56 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 140282 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 4 Sep 2002 12:50:56 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 4 Sep 2002 12:50:56 -0400
Received: from redback.com (login001.redback.com [155.53.12.18]) by
          prattle.redback.com (Postfix) with ESMTP id D286E2CDB47 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Wed,  4 Sep 2002 09:50:54 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <125DE5BA.2F9F561C.0004D071@aol.com> <3D74CE1A.6080907@redback.com>
            <20020903114832.B25223@demiurge.exodus.net>
            <3D763982.576B1590@earthlink.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D763A32.8000508@redback.com>
Date:         Wed, 4 Sep 2002 12:52:02 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: OSPF multiple process
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Erblichs wrote:

> Group,
>
>         And I know of a a a well known company implimentation   that I believe
> has used at least a three process
>         OSPF implimentation for 7+ years : main, hello, and a scanner.


Michell,

I think you're confusing internal OSPF implementation with supporting
mulitple OSPF instances (at least one vendor calls these routing processes).


>
>         Mitchell Erblich
>         PS: Someone said that we should keep discussions company
>             neutral..
>         Staff Kernel / IP Routing Protocol Engineer
>         ==============================================
>
> Andrew Lange wrote:
>
>>In fact, the Exodus network has used multiple OSPF processes for a number
>>of years.  It has worked just fine.
>>
>>Andrew
>>
>>On Tue, Sep 03, 2002 at 10:58:34AM -0400, Acee Lindem wrote:
>>
>>>User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
>>>            Netscape6/6.2.3
>>>X-Accept-Language: en-us
>>>Date:         Tue, 3 Sep 2002 10:58:34 -0400
>>>Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
>>>From: Acee Lindem <acee@REDBACK.COM>
>>>Subject: Re: OSPF multiple process
>>>To: OSPF@DISCUSS.MICROSOFT.COM
>>>Precedence: list
>>>X-OriginalArrivalTime: 03 Sep 2002 15:03:11.0482 (UTC) FILETIME=[053D2DA0:01C2535B]
>>>
>>>Javed Syed wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I would like to know if anybody have seen or aware of any good document explaining why it is not recommended to run multiple OSPF processor in the same router.
>>>>I have seens many emails regarding this issue.
>>>>
>>>>I have seen people running two processor only if it is absolute necessary and to make each node acting as a multiple node for load balancing.
>>>>Any comments will be appreciated.
>>>>
>>>
>>>JS,
>>>
>>>I think the fear of multiple OSPF process dates back to days of routers
>>>with less than 100 MHz processors and only a couple megs of memory. At
>>>that time, many thought that the scaling/scheduling/debuging issues
>>>associated with multiple link state protocol instances were intractable.
>>>I doubt you'll encouter the same trepidation today.
>>>
>>>
>>>
>>>>JS
>>>>
>>>>
>>>>
>>>
>>>--
>>>Acee
>>>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep  4 13:35:52 2002
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 MAA09115
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 Sep 2002 12:43:07 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00701FA9@cherry.ease.lsoft.com>; Wed, 4 Sep 2002 12:39:48 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 140190 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 4 Sep 2002 12:39:48 -0400
Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 4 Sep 2002 12:39:48 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id MAA06416 for <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 4 Sep 2002
          12:39:45 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00344
          for <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 4 Sep 2002 12:39:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R68QLF0D>; Wed, 4 Sep 2002 12:39:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <39469E08BD83D411A3D900204840EC5576330B@vie-msgusr-01.dc.fore.com>
Date:         Wed, 4 Sep 2002 12:39:39 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Naidu, Venkata" <Venkata.Naidu@MARCONI.COM>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Manav,

 Some clarification on the text:

-> LLC/SNAP header adds 3 more bytes.

 As per RFC2684 (which obsoletes RFC1483), LLC header for IPv4 is
 8 bytes.

-> Thus if we know that we are using only IP then it is better
-> to go in for VC mux encaps because we save a lot of bandwidth.

  No! you can't save *lot* of bandwidth :) May be when running a
  greedy TCP application. :-)

  RFC3035 reads:
   In addition, if two LDP peers are connected via an LC-ATM interface,
   a non-MPLS connection, capable of carrying unlabelled IP packets,
   MUST be available.  This non-MPLS connection is used to carry LDP
   packets between the two peers, and MAY also be used (but is not
   required to be used) for other unlabeled packets (such as OSPF
   packets, etc.).  The LLC/SNAP encapsulation of RFC 2684 [5] MUST be
   used on the non-MPLS connection.

-> IS-IS requires ATM LLC/SNAP encapsulation because its not an
-> IP packet thereby loosing on the bandwidth efficiency we have
-> with OSPF.

 More over, whether to use LLC encapsulation or not is definitely
 not based on bandwidth efficiency. LLC Encapsulation is needed
 when more than one protocol might be carried over the same VC.

 Dave Katz presentation also had this "TCP ACK" statement when
 comparing OSPF and ISIS. IMHO, the smallest OSPF packet (let us
 take Hello gives "20 (IP header) + 24 (OSPF header) + 20 (Hello header)"
 (then LLC 8 byte header + AAL5 header) definitely won't fit in
 a single cell. So, w.r.t OSPF vs ISIS one additional cell
 (because of LLC encapsulation) is not much important.

 Dave might give some more clarification to this.

 However, your paper gives a very good insight on the differences
 between OSPF and ISIS.

--
Venkata.


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep  4 14:51:37 2002
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 OAA15616
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 Sep 2002 14:51:37 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00702437@cherry.ease.lsoft.com>; Wed, 4 Sep 2002 14:53:08 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 140619 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 4 Sep 2002 14:53:07 -0400
Received: from 192.122.173.43 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 4 Sep 2002 14:43:06 -0400
Received: from cisco.com ([10.77.138.151]) by cisco.com (8.8.8/2.6/Cisco List
          Logging/8.8.8) with ESMTP id AAA19928 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 5 Sep 2002 00:12:59 +0530 (IST)
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (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:  <3D765437.D3FACBE2@cisco.com>
Date:         Thu, 5 Sep 2002 00:13:03 +0530
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Santhosh Ram <smanohar@CISCO.COM>
Subject: Links included in routing calculation
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi,
In the book "OSPF Anatomy of an internet routing protocol" in section 4.2.4
under the heading "LS Age Field" author says,

"After an LSA's originating router has failed, it can therefore take as long
as an hour for the LSA to be removed from other router's link-state database
Such an LSA is certainly advertising out-of-date information; however, OSPF
guarantees that the LSA will not interfere with the routing table calculation.
How? By requiring that a link be advertised by the routers at both the ends
of the link before using the link in the routing calculation"

Can someone please help me understand what the last line in the above quote
means ?

One more question I had is, when a router LSA is generated should the router
always advertise its router ID as a stub link ? If not, what are the cases
in which it should be advertised ? In the RT3's router-LSA for Area 1 given
in section 12.4.1.4 of RFC 2328 the router ID is not advertised in the router
LSA where as a router LSA in the above mentioned book(In section 4.3) does
include the router ID in the type 1 LSA.

thanks,
Santhosh.


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep  4 17:37:18 2002
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 RAA22533
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 Sep 2002 17:37:18 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00702C0B@cherry.ease.lsoft.com>; Wed, 4 Sep 2002 17:38:53 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 140959 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 4 Sep 2002 17:38:52 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 4 Sep 2002 17:38:51 -0400
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g84Lcpm59391 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 4 Sep 2002 14:38:51 -0700 (PDT)
          (envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost) by kummer.juniper.net
          (8.11.6/8.9.3) with ESMTP id g84LcpS44592 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 4 Sep 2002 14:38:51 -0700 (PDT)
          (envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <20020904142505.A44490-100000@kummer.juniper.net>
Date:         Wed, 4 Sep 2002 14:38:51 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Kireeti Kompella <kireeti@JUNIPER.NET>
Subject: Re: ospf te doc
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <9BBB98592D94084DB7118F889CFD3EC57FC55C@atlntex01.movaz.com>
Precedence: list

Hi All,

The *rough* consensus here is to make the Instance field all 24 bits
of the Opaque ID.  The new wording is:

2.2. LSA ID

   The LSA ID of an Opaque LSA is defined as having eight bits of type
   and 24 bits of type-specific data.  The Traffic Engineering LSA uses
   type 1.  The remaining 24 bits are the Instance field, as follows:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       1       |                   Instance                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Instance field is an arbitrary value used to maintain multiple
   Traffic Engineering LSAs.  A maximum of 16777216 Traffic Engineering
   LSAs may be sourced by a single system.  The LSA ID has no
   topological significance.

Also, I will add the following (similar to the ISIS TE doc) to 2.4.1:

   If a router advertises BGP routes with the BGP next hop attribute
   set to the BGP router ID, then the Router Address SHOULD be the same as
   the BGP router ID.

Any other comments before I send this doc to John & Bill/Alex for IETF
Last Call?

Kireeti.


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep  4 18:49:57 2002
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 SAA23994
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 Sep 2002 18:49:57 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00702EB2@cherry.ease.lsoft.com>; Wed, 4 Sep 2002 18:51:30 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 141118 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 4 Sep 2002 18:51:30 -0400
Received: from 12.40.60.233 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 4 Sep 2002 18:41:30 -0400
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service
          (5.5.2653.19) id <RBC1B3KH>; Wed, 4 Sep 2002 18:41:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Message-ID:  <1117F7D44159934FB116E36F4ABF221B0267EAA9@celox-ma1-ems1.celoxnetworks.com>
Date:         Wed, 4 Sep 2002 18:41:29 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Gray, Eric" <egray@CELOXNETWORKS.COM>
Subject: Re: ospf te doc
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

One comment - Yay!

Eric W. Gray
Systems Architect
Celox Networks, Inc.
egray@celoxnetworks.com
508 305 7214


> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@JUNIPER.NET]
> Sent: Wednesday, September 04, 2002 5:39 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: ospf te doc
>
> Hi All,
>
> The *rough* consensus here is to make the Instance field all 24 bits
> of the Opaque ID.  The new wording is:
>
> 2.2. LSA ID
>
>    The LSA ID of an Opaque LSA is defined as having eight bits of type
>    and 24 bits of type-specific data.  The Traffic Engineering LSA uses
>    type 1.  The remaining 24 bits are the Instance field, as follows:
>
>       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
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |       1       |                   Instance                    |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    The Instance field is an arbitrary value used to maintain multiple
>    Traffic Engineering LSAs.  A maximum of 16777216 Traffic Engineering
>    LSAs may be sourced by a single system.  The LSA ID has no
>    topological significance.
>
> Also, I will add the following (similar to the ISIS TE doc) to 2.4.1:
>
>    If a router advertises BGP routes with the BGP next hop attribute
>    set to the BGP router ID, then the Router Address SHOULD be the same as
>    the BGP router ID.
>
> Any other comments before I send this doc to John & Bill/Alex for IETF
> Last Call?
>
> Kireeti.


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep  5 03:52:26 2002
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 DAA12242
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Sep 2002 03:52:25 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.007040FD@cherry.ease.lsoft.com>; Thu, 5 Sep 2002 3:54:00 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 142453 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 5 Sep 2002 03:54:00 -0400
Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 5 Sep 2002 03:54:00 -0400
Received: from user-2ivfmst.dialup.mindspring.com ([165.247.219.157]
          helo=earthlink.net) by swan.mail.pas.earthlink.net with esmtp (Exim
          3.33 #1) id 17mrSg-0004mh-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 05
          Sep 2002 00:53:58 -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: <125DE5BA.2F9F561C.0004D071@aol.com> <3D74CE1A.6080907@redback.com>
            <20020903114832.B25223@demiurge.exodus.net>
            <3D763982.576B1590@earthlink.net> <3D763A32.8000508@redback.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D771084.BD55325A@earthlink.net>
Date:         Thu, 5 Sep 2002 01:06:28 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: OSPF multiple process
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Acee,

        I am pretty sure that I am correct.

        I remember that they achieved these
        additional processes via their internal
        fork system calls that returns twice.

        Yes, once for the parent and once for the
        child. You do this two times and you
        have a three process OSPF.

        And don't you think it is wise to do this
        type of OSPF implimentation?

        Mitchell Erblich
        Staff Kernel / IP Routing Protocol Engineer
        ===============================================




Acee Lindem wrote:
>
> Erblichs wrote:
>
> > Group,
> >
> >         And I know of a a a well known company implimentation   that I believe
> > has used at least a three process
> >         OSPF implimentation for 7+ years : main, hello, and a scanner.
>
> Michell,
>
> I think you're confusing internal OSPF implementation with supporting
> mulitple OSPF instances (at least one vendor calls these routing processes).
>
> >
> >         Mitchell Erblich
> >         PS: Someone said that we should keep discussions company
> >             neutral..
> >         Staff Kernel / IP Routing Protocol Engineer
> >         ==============================================
> >
> > Andrew Lange wrote:
> >
> >>In fact, the Exodus network has used multiple OSPF processes for a number
> >>of years.  It has worked just fine.
> >>
> >>Andrew
> >>
> >>On Tue, Sep 03, 2002 at 10:58:34AM -0400, Acee Lindem wrote:
> >>
> >>>User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
> >>>            Netscape6/6.2.3
> >>>X-Accept-Language: en-us
> >>>Date:         Tue, 3 Sep 2002 10:58:34 -0400
> >>>Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
> >>>From: Acee Lindem <acee@REDBACK.COM>
> >>>Subject: Re: OSPF multiple process
> >>>To: OSPF@DISCUSS.MICROSOFT.COM
> >>>Precedence: list
> >>>X-OriginalArrivalTime: 03 Sep 2002 15:03:11.0482 (UTC) FILETIME=[053D2DA0:01C2535B]
> >>>
> >>>Javed Syed wrote:
> >>>
> >>>
> >>>>Hi,
> >>>>
> >>>>I would like to know if anybody have seen or aware of any good document explaining why it is not recommended to run multiple OSPF processor in the same router.
> >>>>I have seens many emails regarding this issue.
> >>>>
> >>>>I have seen people running two processor only if it is absolute necessary and to make each node acting as a multiple node for load balancing.
> >>>>Any comments will be appreciated.
> >>>>
> >>>
> >>>JS,
> >>>
> >>>I think the fear of multiple OSPF process dates back to days of routers
> >>>with less than 100 MHz processors and only a couple megs of memory. At
> >>>that time, many thought that the scaling/scheduling/debuging issues
> >>>associated with multiple link state protocol instances were intractable.
> >>>I doubt you'll encouter the same trepidation today.
> >>>
> >>>
> >>>
> >>>>JS
> >>>>
> >>>>
> >>>>
> >>>
> >>>--
> >>>Acee
> >>>
> >
>
> --
> Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep  5 04:30:29 2002
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 EAA12749
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Sep 2002 04:30:29 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00704212@cherry.ease.lsoft.com>; Thu, 5 Sep 2002 4:32:04 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 142516 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 5 Sep 2002 04:32:04 -0400
Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 5 Sep 2002 04:32:04 -0400
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
          (iPlanet Messaging Server 5.1 (built Sep  5 2001)) id
          <0H1Y00A01IK9MK@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 05 Sep 2002 17:36:09 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet
          Messaging Server 5.1 (built Sep  5 2001)) with ESMTP id
          <0H1Y00A8OIK96L@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 05 Sep 2002 17:36:09 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging
          Server 5.1 (built Sep  5 2001)) with ESMTPA id
          <0H1Y00DECIKUVS@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 05 Sep 2002 17:36:31 +0900 (KST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <39469E08BD83D411A3D900204840EC5576330B@vie-msgusr-01.dc.fore.com>
Message-ID:  <042801c254b6$b97c5730$b4036c6b@sisodomain.com>
Date:         Thu, 5 Sep 2002 14:02:07 +0530
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Manav Bhatia <manav@SAMSUNG.COM>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7BIT

Venkata,

|
| -> Thus if we know that we are using only IP then it is better
| -> to go in for VC mux encaps because we save a lot of bandwidth.
|
|   No! you can't save *lot* of bandwidth :) May be when running a
|   greedy TCP application. :-)

I was comparing the bandwidth when running TCP applications only :-)
because using VC mux encaps we can send TCP ACK in one cell and i read in
some paper that TCP ACKs constitute a major percentage of the traffic.

|
|   RFC3035 reads:
|    In addition, if two LDP peers are connected via an LC-ATM interface,
|    a non-MPLS connection, capable of carrying unlabelled IP packets,
|    MUST be available.  This non-MPLS connection is used to carry LDP
|    packets between the two peers, and MAY also be used (but is not
|    required to be used) for other unlabeled packets (such as OSPF
|    packets, etc.).  The LLC/SNAP encapsulation of RFC 2684 [5] MUST be
|    used on the non-MPLS connection.
|
| -> IS-IS requires ATM LLC/SNAP encapsulation because its not an
| -> IP packet thereby loosing on the bandwidth efficiency we have
| -> with OSPF.
|
|  More over, whether to use LLC encapsulation or not is definitely
|  not based on bandwidth efficiency. LLC Encapsulation is needed
|  when more than one protocol might be carried over the same VC.

Agreed.

What i wanted to convey was that if we use IS-IS then we have to go in for
LLC/SNAP encaps because you'll be running TCP/IP applications too. But if
you're running OSPF then you can as well use VC mux.

|
|  Dave Katz presentation also had this "TCP ACK" statement when
|  comparing OSPF and ISIS. IMHO, the smallest OSPF packet (let us
|  take Hello gives "20 (IP header) + 24 (OSPF header) + 20 (Hello header)"
|  (then LLC 8 byte header + AAL5 header) definitely won't fit in
|  a single cell. So, w.r.t OSPF vs ISIS one additional cell
|  (because of LLC encapsulation) is not much important.

I believe it is not the protocol packets that we're talking of fitting in
one cell or not but rather the data (TCP to be precise) packets wherein we
can gain some efficiency. But then as Dave says there is a hack for that
too :-)

|
|  Dave might give some more clarification to this.
|
|  However, your paper gives a very good insight on the differences
|  between OSPF and ISIS.

Thanks.

Regards,
Manav


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep  5 06:40:50 2002
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 GAA14299
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Sep 2002 06:40:50 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00704513@cherry.ease.lsoft.com>; Thu, 5 Sep 2002 6:41:59 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 143355 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 5 Sep 2002 06:41:58 -0400
Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 5 Sep 2002 06:41:58 -0400
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
          (iPlanet Messaging Server 5.1 (built Sep  5 2001)) id
          <0H1Y00G04OJ3L9@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 05 Sep 2002 19:45:03 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet
          Messaging Server 5.1 (built Sep  5 2001)) with ESMTP id
          <0H1Y00G95OJ36K@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 05 Sep 2002 19:45:03 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging
          Server 5.1 (built Sep  5 2001)) with ESMTPA id
          <0H1Y00I3ZOJOWF@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 05 Sep 2002 19:45:26 +0900 (KST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <20020904134144.91048.qmail@web12408.mail.yahoo.com>
            <00c901c2541c$5a427f00$b4036c6b@sisodomain.com>
            <200209041618.g84GIF429584@cirrus.juniper.net>
Message-ID:  <04d801c254c8$bb19ae50$b4036c6b@sisodomain.com>
Date:         Thu, 5 Sep 2002 16:11:01 +0530
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Manav Bhatia <manav@SAMSUNG.COM>
Subject: Re: Paper comparing OSPF and ISIS
Comments: cc: dkatz@juniper.net
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7BIT

Expounding on what Dave just said.

The first two fields in the IP header are the 4-bit version number and the
4-bit header length. The value of the first byte is normally 0x45. If there
are IP header options attached to the IP header, the first byte can be
between 0x46 and 0x4F. The first byte in an IS-IS packet is always 0x83.
Thus by looking at the first byte of an incoming packet, the receiver can
separate IP and IS-IS packets. Because of this feature we do not to depend
on the ATM layer anymore to help us with the demultiplexing. Routers can
now send and receive both IS-IS and IP packets using vc mux encaps which is
what we wanted to do to avoid the atm cell tax.

But is anybody aware of why there aren't any implementations out there for
this or why this wasn't accepted?

----- Original Message -----
From: "Dave Katz" <dkatz@JUNIPER.NET>
To: <OSPF@DISCUSS.MICROSOFT.COM>
Sent: Wednesday, September 04, 2002 9:48 PM
Subject: Re: Paper comparing OSPF and ISIS


| Actually this is not true;  there is the infamous "Henk Hack" whereby
| you can run ISIS over a VCMUX PVC:  you do protocol identification based
| on the first byte of the packet.  0x83 (IIRC) is IS-IS, 0x4x is IP.  It's
| a NLPID stood on its head.
|
| I don't know that anybody has implemented this, though we've considered
it;
| mostly it took the wind out of the sails of ISIS-over-IP.
|
|    IS-IS requires ATM LLC/SNAP encapsulation because its not an IP packet
|    thereby loosing on the bandwidth efficiency we have with OSPF.


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep  5 09:24:38 2002
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 JAA18421
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Sep 2002 09:24:38 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00704871@cherry.ease.lsoft.com>; Thu, 5 Sep 2002 9:26:05 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 143801 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 5 Sep 2002 09:26:04 -0400
Received: from 166.111.68.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 5 Sep 2002 09:26:03 -0400
Received: from chinahero ([192.168.1.192]) by csnet1.cs.tsinghua.edu.cn
          (8.9.2/8.9.2) with SMTP id WAA01984 for <OSPF@DISCUSS.MICROSOFT.COM>;
          Thu, 5 Sep 2002 22:13:41 +0900 (CDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
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:  <000901c254e1$51cbca00$c001a8c0@chinahero>
Date:         Thu, 5 Sep 2002 21:36:59 +0800
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Li Zhongjie <lzj@CSNET1.CS.TSINGHUA.EDU.CN>
Subject: question about IP subnet overlap
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA18421

Hi everybody,

I am interested in IP subnet overlap when assigning subnets to router interfaces.
As an example, see the figure below. Router A connects to B via a point-to-point
link which is assigned a subnet 192.168.1.240/28. A also has an broadcast interface
whose subnet is 192.168.1.240/28. These two subnet overlap.
Is this configuration scenario common, or rare, or wrong in practice?

Another question is: there may be multiple p2p links between two routers, in this 
case, anybody knows that whether there exists some rules governing the assignment
of subnets and metrics to these multiple links? I just lack experiences of running
real networks.

If anybody could recommend some literature or website or something else, thanks a lot. 
     ----------
         |
         | 192.168.1.240/28
         |
       ******192.168.1.248/29   *******
       * A  *-------------------*  B  *
       ******                   *******
---
Best Regards,

Zhongjie Li

********************************************************************
*    Zhongjie Li                                                   *
*    Ph.D candidate, Department of Computer Science & Technology   *
*    Tsinghua University, Beijing, 100084, P.R.China               *
*    Tel: +86+10-62788109     Fax:  +86+10-62788109                *
*    Email: lzj@csnet1.cs.tsinghua.edu.cn                          *
********************************************************************


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep  5 09:28:07 2002
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 JAA18663
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Sep 2002 09:28:07 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.007047B3@cherry.ease.lsoft.com>; Thu, 5 Sep 2002 9:29:42 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 143828 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 5 Sep 2002 09:29:42 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 5 Sep 2002 09:29:41 -0400
Received: from redback.com (login004.redback.com [155.53.12.57]) by
          prattle.redback.com (Postfix) with ESMTP id 29758F2C5A for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu,  5 Sep 2002 06:29:41 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <125DE5BA.2F9F561C.0004D071@aol.com> <3D74CE1A.6080907@redback.com>
            <20020903114832.B25223@demiurge.exodus.net>           
            <3D763982.576B1590@earthlink.net> <3D763A32.8000508@redback.com>
            <3D771084.BD55325A@earthlink.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D775C7D.3020401@redback.com>
Date:         Thu, 5 Sep 2002 09:30:37 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: OSPF multiple process
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Erblichs wrote:

> Acee,
>
>         I am pretty sure that I am correct.


Hello Michell,

You may be correct about this particular implementation.
However, I believe the original question was whether a someone
setting up an OSPF network should use multiple instances
of OSPF in a single router as opposed to whether one should
implement OSPF with more than one process. About 8 or 9
years back, the former was discouraged.


>
>         I remember that they achieved these
>         additional processes via their internal
>         fork system calls that returns twice.
>
>         Yes, once for the parent and once for the
>         child. You do this two times and you
>         have a three process OSPF.
>
>         And don't you think it is wise to do this
>         type of OSPF implimentation?
>
>         Mitchell Erblich
>         Staff Kernel / IP Routing Protocol Engineer
>         ===============================================
>
>
>
>
> Acee Lindem wrote:
>
>>Erblichs wrote:
>>
>>
>>>Group,
>>>
>>>        And I know of a a a well known company implimentation   that I believe
>>>has used at least a three process
>>>        OSPF implimentation for 7+ years : main, hello, and a scanner.
>>>
>>Michell,
>>
>>I think you're confusing internal OSPF implementation with supporting
>>mulitple OSPF instances (at least one vendor calls these routing processes).
>>
>>
>>>        Mitchell Erblich
>>>        PS: Someone said that we should keep discussions company
>>>            neutral..
>>>        Staff Kernel / IP Routing Protocol Engineer
>>>        ==============================================
>>>
>>>Andrew Lange wrote:
>>>
>>>
>>>>In fact, the Exodus network has used multiple OSPF processes for a number
>>>>of years.  It has worked just fine.
>>>>
>>>>Andrew
>>>>
>>>>On Tue, Sep 03, 2002 at 10:58:34AM -0400, Acee Lindem wrote:
>>>>
>>>>
>>>>>User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
>>>>>           Netscape6/6.2.3
>>>>>X-Accept-Language: en-us
>>>>>Date:         Tue, 3 Sep 2002 10:58:34 -0400
>>>>>Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
>>>>>From: Acee Lindem <acee@REDBACK.COM>
>>>>>Subject: Re: OSPF multiple process
>>>>>To: OSPF@DISCUSS.MICROSOFT.COM
>>>>>Precedence: list
>>>>>X-OriginalArrivalTime: 03 Sep 2002 15:03:11.0482 (UTC) FILETIME=[053D2DA0:01C2535B]
>>>>>
>>>>>Javed Syed wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I would like to know if anybody have seen or aware of any good document explaining why it is not recommended to run multiple OSPF processor in the same router.
>>>>>>I have seens many emails regarding this issue.
>>>>>>
>>>>>>I have seen people running two processor only if it is absolute necessary and to make each node acting as a multiple node for load balancing.
>>>>>>Any comments will be appreciated.
>>>>>>
>>>>>>
>>>>>JS,
>>>>>
>>>>>I think the fear of multiple OSPF process dates back to days of routers
>>>>>with less than 100 MHz processors and only a couple megs of memory. At
>>>>>that time, many thought that the scaling/scheduling/debuging issues
>>>>>associated with multiple link state protocol instances were intractable.
>>>>>I doubt you'll encouter the same trepidation today.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>JS
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>--
>>>>>Acee
>>>>>
>>>>>
>>--
>>Acee
>>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep  5 10:25:00 2002
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 KAA20583
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Sep 2002 10:25:00 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00704B14@cherry.ease.lsoft.com>; Thu, 5 Sep 2002 10:26:36 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 143984 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 5 Sep 2002 10:26:35 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 5 Sep 2002 10:26:35 -0400
Received: from redback.com (login004.redback.com [155.53.12.57]) by
          prattle.redback.com (Postfix) with ESMTP id 6FEDFF2C4C for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu,  5 Sep 2002 07:26:28 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D765437.D3FACBE2@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D7769CC.2040600@redback.com>
Date:         Thu, 5 Sep 2002 10:27:24 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Links included in routing calculation
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Santhosh Ram wrote:

> Hi,
> In the book "OSPF Anatomy of an internet routing protocol" in section 4.2.4
> under the heading "LS Age Field" author says,
>
> "After an LSA's originating router has failed, it can therefore take as long
> as an hour for the LSA to be removed from other router's link-state database
> Such an LSA is certainly advertising out-of-date information; however, OSPF
> guarantees that the LSA will not interfere with the routing table calculation.
> How? By requiring that a link be advertised by the routers at both the ends
> of the link before using the link in the routing calculation"


Hi Santhosh,

Yes. The LSAs have to have a bi-directional link (i.e., there must be a
full neighbor adjacency) in order to be used in the SPF calculation.


>
> Can someone please help me understand what the last line in the above quote
> means ?
>
> One more question I had is, when a router LSA is generated should the router
> always advertise its router ID as a stub link ? If not, what are the cases
> in which it should be advertised ? In the RT3's router-LSA for Area 1 given
> in section 12.4.1.4 of RFC 2328 the router ID is not advertised in the router
> LSA where as a router LSA in the above mentioned book(In section 4.3) does
> include the router ID in the type 1 LSA.


Implicitly advertising the router ID as a stub link is an implementation choice.
It is not part of the specification. Since it increases the size of every
OSPF router's route table in the area, I'd opt against it. If an implementation
does choose implicit advertisement, the implementation should assure that
the router ID always corresponds to an interface address (so that the route
is valid).


>
> thanks,
> Santhosh.
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep  5 11:05:33 2002
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 LAA22108
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Sep 2002 11:05:32 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00704B55@cherry.ease.lsoft.com>; Thu, 5 Sep 2002 11:07:08 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 144171 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 5 Sep 2002 11:07:08 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 5 Sep 2002 11:07:07 -0400
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g85F76m22436; Thu, 5
          Sep 2002 08:07:06 -0700 (PDT) (envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id
          g85F75G32706; Thu, 5 Sep 2002 08:07:05 -0700 (PDT) (envelope-from
          dkatz@cirrus.juniper.net)
References: <20020904134144.91048.qmail@web12408.mail.yahoo.com>
            <00c901c2541c$5a427f00$b4036c6b@sisodomain.com>
            <200209041618.g84GIF429584@cirrus.juniper.net>
            <04d801c254c8$bb19ae50$b4036c6b@sisodomain.com>
Message-ID:  <200209051507.g85F75G32706@cirrus.juniper.net>
Date:         Thu, 5 Sep 2002 08:07:05 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Dave Katz <dkatz@JUNIPER.NET>
Subject: Re: Paper comparing OSPF and ISIS
Comments: To: manav@samsung.com
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <04d801c254c8$bb19ae50$b4036c6b@sisodomain.com> (message from
              Manav Bhatia on Thu, 05 Sep 2002 16:11:01 +0530)
Precedence: list

The demise of ATM cores in the largest ISPs (which are also among the few
running ISIS) made this pretty moot.


   But is anybody aware of why there aren't any implementations out there for
   this or why this wasn't accepted?


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep  5 13:24:55 2002
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 NAA27233
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Sep 2002 13:24:55 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0070502D@cherry.ease.lsoft.com>; Thu, 5 Sep 2002 13:26:29 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 144881 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 5 Sep 2002 13:26:29 -0400
Received: from 216.15.8.227 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 5 Sep 2002 13:26:29 -0400
Received: from jupiter.polarisnetworks.com ([192.168.0.19]) by
          mercury.polarisnetworks.com (Post.Office MTA v3.5.3 release 223 ID#
          0-0U10L2S100V35) with ESMTP id com for <OSPF@DISCUSS.MICROSOFT.COM>;
          Thu, 5 Sep 2002 10:20:38 -0700
Received: by JUPITER with Internet Mail Service (5.5.2650.21) id <RQ5DN26L>;
          Thu, 5 Sep 2002 10:22:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="gb2312"
Message-ID:  <DFC78D6E417DD411A26F0001021D6386901822@JUPITER>
Date:         Thu, 5 Sep 2002 10:22:54 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Cheng, Dean" <DCheng@POLARISNETWORKS.COM>
Subject: Re: question about IP subnet overlap
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Mr. Li,

     Comments inline...

Dean

> -----Original Message-----
> From: Li Zhongjie [mailto:lzj@CSNET1.CS.TSINGHUA.EDU.CN]
> Sent: Thursday, September 05, 2002 6:37 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: question about IP subnet overlap
>
>
> Hi everybody,
>
> I am interested in IP subnet overlap when assigning subnets
> to router interfaces.
> As an example, see the figure below. Router A connects to B
> via a point-to-point
> link which is assigned a subnet 192.168.1.240/28. A also has
> an broadcast interface
> whose subnet is 192.168.1.240/28. These two subnet overlap.
> Is this configuration scenario common, or rare, or wrong in practice?

First of all, the address/mask in your text is not consistent
with that in the picture, i.e., it is /28 in one place and
/29 in another.

In practice, the IP address on router interfaces must be
configured with uniqueness. So the scenario as shown is a
wrong configuration. Many routers upon initialization or
configuration, do check on the uniqueness on their interfaces'
IP addresses.

>
> Another question is: there may be multiple p2p links between
> two routers, in this
> case, anybody knows that whether there exists some rules
> governing the assignment
> of subnets and metrics to these multiple links? I just lack
> experiences of running
> real networks.

In addition to the "uniqueness", there is not much rule.
On the other hand, users prefer to have no IP addresses
assigned on p2p links for reasons including saving address
space, reduce IP routing table size, eliminate the
configuration efforts, etc. If a p2p link has no IP
address assigned, it is called unnumbered links, and
it is supported by OSPF, refer to RFC 2328 OSPF v2.

>
> If anybody could recommend some literature or website or
> something else, thanks a lot.
>      ----------
>          |
>          | 192.168.1.240/28
>          |
>        ******192.168.1.248/29   *******
>        * A  *-------------------*  B  *
>        ******                   *******
> ---
> Best Regards,
>
> Zhongjie Li
>
> ********************************************************************
> *    Zhongjie Li                                                   *
> *    Ph.D candidate, Department of Computer Science & Technology   *
> *    Tsinghua University, Beijing, 100084, P.R.China               *
> *    Tel: +86+10-62788109     Fax:  +86+10-62788109                *
> *    Email: lzj@csnet1.cs.tsinghua.edu.cn                          *
> ********************************************************************
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep  5 14:25:09 2002
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 OAA00867
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Sep 2002 14:25:09 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00705B46@cherry.ease.lsoft.com>; Thu, 5 Sep 2002 14:26:44 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 145415 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 5 Sep 2002 14:26:44 -0400
Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 5 Sep 2002 14:26:44 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <1.00705B61@cherry.ease.lsoft.com>;
          Thu, 5 Sep 2002 14:26:43 -0400
Message-ID:  <OSPF%2002090514264415@DISCUSS.MICROSOFT.COM>
Date:         Thu, 5 Sep 2002 14:26:44 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Darshan Purohit <darshan.purohit@NOKIA.COM>
Subject: Multiple Interfaces to a Link
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi All,
I had a question about multiple interfaces on the same link. The setup
is:

      __
     |  | --1--|
E1---|R1| --2--|
     |__| --3--|
               |   __
               |_1|  |
                  |R2|
                  |__|


As mentioned in 2740, section 3.9, R1 uses only interface 1 (say), for
control traffic and setting up adjacency with R2. However,
R1 originates a router LSA for each interface 1,2 and 3  ,
and it generates a separate Link LSA for each interface. Now, for a
route
through R1, how is R2 supposed to pick the nexthop link local address.
Will it be I1 - the interface which is being used for control traffic,
OR any one of the routers Link LSA , OR all three of them.

In the setup above, will the passive interfaces of R1 be used just as
backups in case the primary fails, or will they really play a role when
R2 (or any other Router in the area) does its routing table
calculation.

Thanks.
Darshan


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep  5 21:30:38 2002
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 VAA13399
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 5 Sep 2002 21:30:38 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0070689E@cherry.ease.lsoft.com>; Thu, 5 Sep 2002 21:32:13 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 146692 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 5 Sep 2002 21:32:13 -0400
Received: from 166.111.68.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 5 Sep 2002 21:32:12 -0400
Received: from chinahero ([192.168.1.192]) by csnet1.cs.tsinghua.edu.cn
          (8.9.2/8.9.2) with SMTP id KAA03070 for <OSPF@DISCUSS.MICROSOFT.COM>;
          Fri, 6 Sep 2002 10:19:50 +0900 (CDT)
References:  <DFC78D6E417DD411A26F0001021D6386901822@JUPITER>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
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:  <001901c25546$c4709760$c001a8c0@chinahero>
Date:         Fri, 6 Sep 2002 09:43:14 +0800
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Li Zhongjie <lzj@CSNET1.CS.TSINGHUA.EDU.CN>
Subject: Re: question about IP subnet overlap
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA13399

Thanks for Dean, see comments inline ...

----- Original Message ----- 
From: "Cheng, Dean" <DCheng@POLARISNETWORKS.COM>
To: <OSPF@DISCUSS.MICROSOFT.COM>
Sent: Friday, September 06, 2002 1:22 AM
Subject: Re: question about IP subnet overlap


> Mr. Li,
> 
>      Comments inline...
> 
> Dean
> 
> > -----Original Message-----
> > From: Li Zhongjie [mailto:lzj@CSNET1.CS.TSINGHUA.EDU.CN]
> > Sent: Thursday, September 05, 2002 6:37 AM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: question about IP subnet overlap
> >
> >
> > Hi everybody,
> >
> > I am interested in IP subnet overlap when assigning subnets
> > to router interfaces.
> > As an example, see the figure below. Router A connects to B
> > via a point-to-point
> > link which is assigned a subnet 192.168.1.240/28. A also has
> > an broadcast interface
> > whose subnet is 192.168.1.240/28. These two subnet overlap.
> > Is this configuration scenario common, or rare, or wrong in practice?
> 
> First of all, the address/mask in your text is not consistent
> with that in the picture, i.e., it is /28 in one place and
> /29 in another.
> 
yes, a mistake, should be 192.168.1.240/28 and 192.168.1.248/29.

> In practice, the IP address on router interfaces must be
> configured with uniqueness. So the scenario as shown is a
> wrong configuration. Many routers upon initialization or
> configuration, do check on the uniqueness on their interfaces'
> IP addresses.
> 
I cann't precisely understand what you mean. The ip addresses of 
each router interface are unique does not exclude that their 
belonging subnets overlap.

> >
> > Another question is: there may be multiple p2p links between
> > two routers, in this
> > case, anybody knows that whether there exists some rules
> > governing the assignment
> > of subnets and metrics to these multiple links? I just lack
> > experiences of running
> > real networks.
> 
> In addition to the "uniqueness", there is not much rule.
> On the other hand, users prefer to have no IP addresses
> assigned on p2p links for reasons including saving address
> space, reduce IP routing table size, eliminate the
> configuration efforts, etc. If a p2p link has no IP
> address assigned, it is called unnumbered links, and
> it is supported by OSPF, refer to RFC 2328 OSPF v2.

I think you should guarantee that the configurations of both
ends are consistent. Inconsistent configurations may include:
1. numbered vs. unnumbered
2. different subnets assigned
3. ...
Also, in the assignment of metrics, perhaps we relate them to
our routing purpose: equal metrics to share load, different
metrics to backup. 

So I wonder if there are some literature talking about this issue.

> 
> >
> > If anybody could recommend some literature or website or
> > something else, thanks a lot.
> >      ----------
> >          |
> >          | 192.168.1.240/28
> >          |
> >        ******192.168.1.248/29   *******
> >        * A  *-------------------*  B  *
> >        ******                   *******
> > ---
> > Best Regards,
> >
> > Zhongjie Li
> >
> > ********************************************************************
> > *    Zhongjie Li                                                   *
> > *    Ph.D candidate, Department of Computer Science & Technology   *
> > *    Tsinghua University, Beijing, 100084, P.R.China               *
> > *    Tel: +86+10-62788109     Fax:  +86+10-62788109                *
> > *    Email: lzj@csnet1.cs.tsinghua.edu.cn                          *
> > ********************************************************************
> >
> 
> 


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep  6 09:08:16 2002
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 JAA02288
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 6 Sep 2002 09:08:16 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00707B63@cherry.ease.lsoft.com>; Fri, 6 Sep 2002 9:09:51 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 148922 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 6 Sep 2002 09:09:50 -0400
Received: from 157.181.151.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 6 Sep 2002 09:09:50 -0400
Received: from pandora.inf.elte.hu (pandora.inf.elte.hu [157.181.161.17]) by
          mx2.elte.hu (Postfix) with ESMTP id 0DC4E4817B for
          <ospf@discuss.microsoft.com>; Fri,  6 Sep 2002 15:09:50 +0200 (CEST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.A41.4.31.0209061455060.25184-100000@pandora.inf.elte.hu>
Date:         Fri, 6 Sep 2002 15:09:50 +0200
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Nohl Attila Rajmund <nar@INF.ELTE.HU>
Subject: Router removed from an area
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hello!

I have a question about the removal of a router from an area. Let's say
I have the following topology:

+---+       if1 +---+
| 1 |-----------| 2 |
+---+ if1       +---+

Both of the routers are in the backbone area. When I remove the if1
interface of router2 from the backbone area, the adjacency between the two
routers broke down, but the Router LSA of router2 remains in the LSA
database of router1 for at most an hour. At least this happens on the
router where I tried this.

My questions are: is the situation above compliant to RFC 2328? I
think, it is not conflicting with the RFC. My other question is that is
it compliant to RFC 2328, if a router tries to be smart, and flushes its
Router LSA from the backbone after it got the command (i.e. from the
console), but before it configures its interface?

                                Bye,NAR


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep  6 09:25:21 2002
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 JAA02778
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 6 Sep 2002 09:25:20 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00707CC2@cherry.ease.lsoft.com>; Fri, 6 Sep 2002 9:26:55 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 149028 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 6 Sep 2002 09:26:54 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 6 Sep 2002 09:26:54 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0AVFF>; Fri, 6 Sep 2002 09:26:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328791585@india_exch.hyderabad.mindspeed.com>
Date:         Fri, 6 Sep 2002 09:29:18 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: Router removed from an area
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi NAR,

The router LSA of router2 remaining in router1 is correct behaviour. The LSA
will however not be considered in the SPF calculations.

Yes, if a router is shutting down it should flush its router LSA and this is
compliant with the behaviour of the RFC2328. However a router would
originate a router LSA after an interface goes down, I do not see much
advantage of originating a router LSA to take care of this special case,
though I guess it would work fine.

Hope this helps.

Thanks,
Vishwas

-----Original Message-----
From: Nohl Attila Rajmund [mailto:nar@INF.ELTE.HU]
Sent: Friday, September 06, 2002 6:40 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Router removed from an area


Hello!

I have a question about the removal of a router from an area. Let's say
I have the following topology:

+---+       if1 +---+
| 1 |-----------| 2 |
+---+ if1       +---+

Both of the routers are in the backbone area. When I remove the if1
interface of router2 from the backbone area, the adjacency between the two
routers broke down, but the Router LSA of router2 remains in the LSA
database of router1 for at most an hour. At least this happens on the
router where I tried this.

My questions are: is the situation above compliant to RFC 2328? I
think, it is not conflicting with the RFC. My other question is that is
it compliant to RFC 2328, if a router tries to be smart, and flushes its
Router LSA from the backbone after it got the command (i.e. from the
console), but before it configures its interface?

                                Bye,NAR


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep  6 15:13:31 2002
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 PAA18089
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 6 Sep 2002 15:13:31 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0070882B@cherry.ease.lsoft.com>; Fri, 6 Sep 2002 15:15:05 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 150409 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 6 Sep 2002 15:15:05 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 6 Sep 2002 15:15:05 -0400
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by
          prattle.redback.com (Postfix) with ESMTP id 6BA1E1DCC6B; Fri,  6 Sep
          2002 12:15:04 -0700 (PDT)
Message-ID:  <20020906191504.6BA1E1DCC6B@prattle.redback.com>
Date:         Fri, 6 Sep 2002 12:15:04 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Naiming Shen <naiming@REDBACK.COM>
Subject: Re: [Isis-wg] Paper comparing OSPF and ISIS
Comments: To: prz@net4u.ch
Comments: cc: "isis-wg@ietf.org" <isis-wg@ietf.org>, riw@cisco.com
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  Mail from Tony Przygienda <prz@net4u.ch> dated Fri, 06 Sep 2002
              07:22:35 PDT <3D78BA2B.5010402@net4u.ch>
Precedence: list

Once Russ told me he was going to write a book on this subject:
"The differences between OSPF and ISIS", and he said there were only
three sentences in that book. Here is the electronic version of that
interesting book if I remember it correctly:

  ISIS is simple.

  OSPF is complicated.

  Otherwise they are the same.

thanks.
(hopefully i didn't violate his publisher's copyright issues)

 ] It is outside the scope
 ] of this workgroup for sure and on top, I am not entirely sure anything
 ] really new comes out of it.
 ] Dave K.'s presentation pretty well covered the issues IMHO.
 ]
 ]     -- tony przygienda

- Naiming


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep  6 15:15:35 2002
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 PAA18136
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 6 Sep 2002 15:15:35 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.007087C6@cherry.ease.lsoft.com>; Fri, 6 Sep 2002 15:17:10 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 150422 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 6 Sep 2002 15:17:10 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 6 Sep 2002 15:17:10 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0AV6N>; Fri, 6 Sep 2002 15:17:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A32879158E@india_exch.hyderabad.mindspeed.com>
Date:         Fri, 6 Sep 2002 15:19:33 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: [Isis-wg] Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Naiming,

We intend to delve into the topic in a little more detail. ;-)

Thanks,
Vishwas

-----Original Message-----
From: Naiming Shen [mailto:naiming@REDBACK.COM]
Sent: Saturday, September 07, 2002 12:45 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: [Isis-wg] Paper comparing OSPF and ISIS


Once Russ told me he was going to write a book on this subject:
"The differences between OSPF and ISIS", and he said there were only
three sentences in that book. Here is the electronic version of that
interesting book if I remember it correctly:

  ISIS is simple.

  OSPF is complicated.

  Otherwise they are the same.

thanks.
(hopefully i didn't violate his publisher's copyright issues)

 ] It is outside the scope
 ] of this workgroup for sure and on top, I am not entirely sure anything
 ] really new comes out of it.
 ] Dave K.'s presentation pretty well covered the issues IMHO.
 ]
 ]     -- tony przygienda

- Naiming


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep  6 17:27:40 2002
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 RAA22035
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 6 Sep 2002 17:27:40 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00708C95@cherry.ease.lsoft.com>; Fri, 6 Sep 2002 17:29:16 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 150779 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 6 Sep 2002 17:29:16 -0400
Received: from 47.103.122.112 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Fri, 6 Sep 2002 17:29:16 -0400
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
          by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP
          id g86LTRH03960 for <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 6 Sep 2002
          16:29:28 -0500 (CDT)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id
          <R06BMV30>; Fri, 6 Sep 2002 14:29:13 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C255EC.71000B0A"
Message-ID:  <5D630265EF50D311ABB60008C7917DB60AF4F8DA@zsc4c004.us.nortel.com>
Date:         Fri, 6 Sep 2002 14:29:11 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Subhasree Mandal <sumandal@NORTELNETWORKS.COM>
Subject: NSSA - type 7 LSA
To: OSPF@DISCUSS.MICROSOFT.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_01C255EC.71000B0A
Content-Type: text/plain;
        charset="iso-8859-1"

Hi,

I have a question about type-7 LSA origination and route calculation.
Let us consider the following configuration

                      N1
       R1-----------cost 10------------------R2
        |                                     |
        |                                     |
        |--cost 10-------R3--------cost 10----|
             N2                      N3

Lets consider that all these routers are in an NSSA area nd R3 is an ASBR
advertising an external
route to network Nx.  If we want that route to be translated to type 5 by
some ABR in this NSSA area, we must set the forwarding address to a non-zero
value (page 6, RFC 1587).  According to page 7 of
the same RFC
         "...if the intervening network is not advertised
         into OSPF as an internal OSPF route, the forwarding
         address should be any one of the router's active OSPF
         interface addresses."

So my type-7 LSA for Nx can have forwarding address as the interface address
of R3 on network N3.
When R1 computes route to Nx, it would actually use the next-hop for N3 as
the next-hop for Nx since
the forwarding address is in N3.  So if R1 chooses to reach N3 through R2
(equally possible as through
R3), the packets from R1 would reach R3 (to go out of the AS) via R2.  In
other words it is adding
an extra hop to the route to Nx.

How do we address this issue?

Thanks,
Subhasree

------_=_NextPart_001_01C255EC.71000B0A
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>NSSA - type 7 LSA</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>I have a question about type-7 LSA origination and =
route calculation.</FONT>
<BR><FONT SIZE=3D2>Let us consider the following configuration</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N1</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
R1-----------cost 10------------------R2</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; |</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; |</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |--cost =
10-------R3--------cost 10----|</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; =
N2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; N3</FONT>
</P>

<P><FONT SIZE=3D2>Lets consider that all these routers are in an NSSA =
area nd R3 is an ASBR advertising an external </FONT>
<BR><FONT SIZE=3D2>route to network Nx.&nbsp; If we want that route to =
be translated to type 5 by some ABR in this NSSA area, we must set the =
forwarding address to a non-zero value (page 6, RFC 1587).&nbsp; =
According to page 7 of </FONT></P>

<P><FONT SIZE=3D2>the same RFC </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;...if the intervening network is not advertised</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
into OSPF as an internal OSPF route, the forwarding</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
address should be any one of the router's active OSPF</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
interface addresses.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>So my type-7 LSA for Nx can have forwarding address =
as the interface address of R3 on network N3.</FONT>
<BR><FONT SIZE=3D2>When R1 computes route to Nx, it would actually use =
the next-hop for N3 as the next-hop for Nx since </FONT>
<BR><FONT SIZE=3D2>the forwarding address is in N3.&nbsp; So if R1 =
chooses to reach N3 through R2 (equally possible as through </FONT>
<BR><FONT SIZE=3D2>R3), the packets from R1 would reach R3 (to go out =
of the AS) via R2.&nbsp; In other words it is adding</FONT>
<BR><FONT SIZE=3D2>an extra hop to the route to Nx.</FONT>
</P>

<P><FONT SIZE=3D2>How do we address this issue?</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Subhasree</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C255EC.71000B0A--


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep  6 17:29:25 2002
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 RAA22164
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 6 Sep 2002 17:29:24 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00708E40@cherry.ease.lsoft.com>; Fri, 6 Sep 2002 17:31:01 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 150797 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 6 Sep 2002 17:31:01 -0400
Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 6 Sep 2002 17:31:01 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <20.00708C66@cherry.ease.lsoft.com>;
          Fri, 6 Sep 2002 17:31:01 -0400
Message-ID:  <OSPF%2002090617310148@DISCUSS.MICROSOFT.COM>
Date:         Fri, 6 Sep 2002 17:31:01 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Chaoping Wu <chaoping_wu@YAHOO.COM>
Subject: Re: question about IP subnet overlap
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Gentlemen,

I'd like to make a short comment on the following statement so that
everybody sees the whole picture.

>In practice, the IP address on router interfaces must be
>configured with uniqueness.

This statement is very true in traditional routers. However, in routers
supporting VPNs, particularly VPNs using virtual router architecture,
overlapping IP addresses in physical router interfaces are very common.

In VR environment, IP address on any virtual router interfaces in one VPN
must be unique.

If you go to IETF draft sites, and search for virtual router, you should
see a number of drafts available on virtual router based VPNs.

Best Regards,
Chaoping Wu


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep  6 21:58:56 2002
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 VAA26899
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 6 Sep 2002 21:58:56 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00709485@cherry.ease.lsoft.com>; Fri, 6 Sep 2002 22:00:31 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 151328 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 6 Sep 2002 22:00:31 -0400
Received: from 216.15.8.227 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 6 Sep 2002 22:00:31 -0400
Received: from jupiter.polarisnetworks.com ([192.168.0.19]) by
          mercury.polarisnetworks.com (Post.Office MTA v3.5.3 release 223 ID#
          0-0U10L2S100V35) with ESMTP id com; Fri, 6 Sep 2002 18:54:52 -0700
Received: by JUPITER with Internet Mail Service (5.5.2650.21) id <RQ5DNL2Q>;
          Fri, 6 Sep 2002 18:56:53 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="gb2312"
Message-ID:  <DFC78D6E417DD411A26F0001021D638601531ACB@JUPITER>
Date:         Fri, 6 Sep 2002 18:56:47 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Cheng, Dean" <DCheng@POLARISNETWORKS.COM>
Subject: Re: question about IP subnet overlap
Comments: To: Li Zhongjie <lzj@CSNET1.CS.TSINGHUA.EDU.CN>
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Got more comments inline...

> -----Original Message-----
> From: Li Zhongjie [mailto:lzj@CSNET1.CS.TSINGHUA.EDU.CN]
> Sent: Thursday, September 05, 2002 6:43 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: question about IP subnet overlap
>
>
> Thanks for Dean, see comments inline ...
>
> ----- Original Message -----
> From: "Cheng, Dean" <DCheng@POLARISNETWORKS.COM>
> To: <OSPF@DISCUSS.MICROSOFT.COM>
> Sent: Friday, September 06, 2002 1:22 AM
> Subject: Re: question about IP subnet overlap
>
>
> > Mr. Li,
> >
> >      Comments inline...
> >
> > Dean
> >
> > > -----Original Message-----
> > > From: Li Zhongjie [mailto:lzj@CSNET1.CS.TSINGHUA.EDU.CN]
> > > Sent: Thursday, September 05, 2002 6:37 AM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: question about IP subnet overlap
> > >
> > >
> > > Hi everybody,
> > >
> > > I am interested in IP subnet overlap when assigning subnets
> > > to router interfaces.
> > > As an example, see the figure below. Router A connects to B
> > > via a point-to-point
> > > link which is assigned a subnet 192.168.1.240/28. A also has
> > > an broadcast interface
> > > whose subnet is 192.168.1.240/28. These two subnet overlap.
> > > Is this configuration scenario common, or rare, or wrong
> in practice?
> >
> > First of all, the address/mask in your text is not consistent
> > with that in the picture, i.e., it is /28 in one place and
> > /29 in another.
> >
> yes, a mistake, should be 192.168.1.240/28 and 192.168.1.248/29.

Also, on a point-to-point link, the network mask is usually not
defined, or the two IP addresses can be independently defined
if you prefer numbered links.

>
> > In practice, the IP address on router interfaces must be
> > configured with uniqueness. So the scenario as shown is a
> > wrong configuration. Many routers upon initialization or
> > configuration, do check on the uniqueness on their interfaces'
> > IP addresses.
> >
> I cann't precisely understand what you mean. The ip addresses of
> each router interface are unique does not exclude that their
> belonging subnets overlap.

Assume you replace the p2p link to an Ethernet (see comment above),
and choose to configure as such,there will be two separate
subnets advertised, i.e., 192.168.1.240/28 and 192.168.1.248/29.

Packets sent to the associated IP addresses may be forwared to
either subnet, depending on the result of the longest matching
rule. The destinations better be on the right subnet otherwise
may become unreachable.

>
> > >
> > > Another question is: there may be multiple p2p links between
> > > two routers, in this
> > > case, anybody knows that whether there exists some rules
> > > governing the assignment
> > > of subnets and metrics to these multiple links? I just lack
> > > experiences of running
> > > real networks.
> >
> > In addition to the "uniqueness", there is not much rule.
> > On the other hand, users prefer to have no IP addresses
> > assigned on p2p links for reasons including saving address
> > space, reduce IP routing table size, eliminate the
> > configuration efforts, etc. If a p2p link has no IP
> > address assigned, it is called unnumbered links, and
> > it is supported by OSPF, refer to RFC 2328 OSPF v2.
>
> I think you should guarantee that the configurations of both
> ends are consistent. Inconsistent configurations may include:
> 1. numbered vs. unnumbered
> 2. different subnets assigned
> 3. ...
> Also, in the assignment of metrics, perhaps we relate them to
> our routing purpose: equal metrics to share load, different
> metrics to backup.
>
> So I wonder if there are some literature talking about this issue.
>
> >
> > >
> > > If anybody could recommend some literature or website or
> > > something else, thanks a lot.
> > >      ----------
> > >          |
> > >          | 192.168.1.240/28
> > >          |
> > >        ******192.168.1.248/29   *******
> > >        * A  *-------------------*  B  *
> > >        ******                   *******
> > > ---
> > > Best Regards,
> > >
> > > Zhongjie Li
> > >
> > >
> ********************************************************************
> > > *    Zhongjie Li
>          *
> > > *    Ph.D candidate, Department of Computer Science &
> Technology   *
> > > *    Tsinghua University, Beijing, 100084, P.R.China
>          *
> > > *    Tel: +86+10-62788109     Fax:  +86+10-62788109
>          *
> > > *    Email: lzj@csnet1.cs.tsinghua.edu.cn
>          *
> > >
> ********************************************************************
> > >
> >
> >
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Sat Sep  7 08:06:16 2002
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 IAA11654
	for <ospf-archive@LISTS.IETF.ORG>; Sat, 7 Sep 2002 08:06:16 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0070A03A@cherry.ease.lsoft.com>; Sat, 7 Sep 2002 8:07:52 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 152739 for OSPF@DISCUSS.MICROSOFT.COM;
          Sat, 7 Sep 2002 08:07:51 -0400
Received: from 166.111.68.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Sat, 7 Sep 2002 08:07:50 -0400
Received: from chinahero ([192.168.1.192]) by csnet1.cs.tsinghua.edu.cn
          (8.9.2/8.9.2) with SMTP id UAA07172 for <OSPF@DISCUSS.MICROSOFT.COM>;
          Sat, 7 Sep 2002 20:55:26 +0900 (CDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
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:  <005b01c25668$bc22cce0$c001a8c0@chinahero>
Date:         Sat, 7 Sep 2002 20:18:50 +0800
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Li Zhongjie <lzj@CSNET1.CS.TSINGHUA.EDU.CN>
Subject: What is a MIB-II IfIndex like
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id IAA11654

I am not familiar with MIBs. A question is what a MIB-II IfIndex looks like.
Could it be distinguished from IP address? An example is better.
---
Best Regards,

Zhongjie Li

********************************************************************
*    Zhongjie Li                                                   *
*    Ph.D candidate, Department of Computer Science & Technology   *
*    Tsinghua University, Beijing, 100084, P.R.China               *
*    Tel: +86+10-62788109     Fax:  +86+10-62788109                *
*    Email: lzj@csnet1.cs.tsinghua.edu.cn                          *
********************************************************************


From owner-ospf@DISCUSS.MICROSOFT.COM  Sat Sep  7 09:55:55 2002
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 JAA13187
	for <ospf-archive@LISTS.IETF.ORG>; Sat, 7 Sep 2002 09:55:55 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0070A156@cherry.ease.lsoft.com>; Sat, 7 Sep 2002 9:57:31 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 152995 for OSPF@DISCUSS.MICROSOFT.COM;
          Sat, 7 Sep 2002 09:57:29 -0400
Received: from 192.122.173.43 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Sat, 7 Sep 2002 09:57:29 -0400
Received: from cisco.com ([10.77.138.151]) by cisco.com (8.8.8/2.6/Cisco List
          Logging/8.8.8) with ESMTP id TAA08745 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Sat, 7 Sep 2002 19:27:23 +0530 (IST)
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <005b01c25668$bc22cce0$c001a8c0@chinahero>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D7A05C7.4D714D65@cisco.com>
Date:         Sat, 7 Sep 2002 19:27:27 +0530
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Santhosh Ram <smanohar@CISCO.COM>
Organization: HCL - Cisco
Subject: Re: What is a MIB-II IfIndex like
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Zhongjie Li,

Here is the ifIndex definition from RFC 1213 which defines MIB II...

          ifIndex OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-only
              STATUS  mandatory

              DESCRIPTION
                      "A unique value for each interface.  Its value
                      ranges between 1 and the value of ifNumber.  The
                      value for each interface must remain constant at
                      least from one re-initialization of the entity's
                      network management system to the next re-
                      initialization."
              ::= { ifEntry 1 }

HTH,

cheers,
Santhosh.

Li Zhongjie wrote:
>
> I am not familiar with MIBs. A question is what a MIB-II IfIndex looks like.
> Could it be distinguished from IP address? An example is better.
> ---
> Best Regards,
>
> Zhongjie Li
>
> ********************************************************************
> *    Zhongjie Li                                                   *
> *    Ph.D candidate, Department of Computer Science & Technology   *
> *    Tsinghua University, Beijing, 100084, P.R.China               *
> *    Tel: +86+10-62788109     Fax:  +86+10-62788109                *
> *    Email: lzj@csnet1.cs.tsinghua.edu.cn                          *
> ********************************************************************


From owner-ospf@DISCUSS.MICROSOFT.COM  Sun Sep  8 21:14:39 2002
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 VAA12709
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 8 Sep 2002 21:14:38 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0070D0B3@cherry.ease.lsoft.com>; 8 Sep 2002 21:16:13 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 156838 for OSPF@DISCUSS.MICROSOFT.COM;
          Sun, 8 Sep 2002 21:16:13 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Sun, 8 Sep 2002 21:16:12 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id 00D324BA217 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Sun,  8 Sep 2002 18:16:11 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <5D630265EF50D311ABB60008C7917DB60AF4F8DA@zsc4c004.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D7BF665.2060103@redback.com>
Date:         Sun, 8 Sep 2002 21:16:21 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: NSSA - type 7 LSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Subhasree Mandal wrote:

> Hi,
>
> I have a question about type-7 LSA origination and route calculation.
> Let us consider the following configuration
>
>                       N1
>        R1-----------cost 10------------------R2
>         |                                     |
>         |                                     |
>         |--cost 10-------R3--------cost 10----|
>              N2                      N3
>
> Lets consider that all these routers are in an NSSA area nd R3 is an
> ASBR advertising an external
> route to network Nx.  If we want that route to be translated to type 5
> by some ABR in this NSSA area, we must set the forwarding address to a
> non-zero value (page 6, RFC 1587).  According to page 7 of
>
> the same RFC
>          "...if the intervening network is not advertised
>          into OSPF as an internal OSPF route, the forwarding
>          address should be any one of the router's active OSPF
>          interface addresses."
>
> So my type-7 LSA for Nx can have forwarding address as the interface
> address of R3 on network N3.
> When R1 computes route to Nx, it would actually use the next-hop for N3
> as the next-hop for Nx since
> the forwarding address is in N3.  So if R1 chooses to reach N3 through
> R2 (equally possible as through
> R3), the packets from R1 would reach R3 (to go out of the AS) via R2.
> In other words it is adding
> an extra hop to the route to Nx.


Hello Subhasree,

It looks like an ECMP route will be computed. However, I see your point.


>
> How do we address this issue?


By configuring a loopback address on R3 and making it part of the NSSA area.

I believe draft-ietf-ospf-nssa-update-11.txt (soon to obsolete 1587) stipulates
that loopback addresses should be preferred over non-loopback when selecting
an NSSA interface address to use as a forwarding address. Besides avoiding
the issue you mention, selecting a loopback address offers better stability
(since you're less likely to have to re-originate all your NSSA type 7 LSAs
due to the forwarding address interface going down).

Thanks,
Acee


>
> Thanks,
> Subhasree
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep  9 10:20:35 2002
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 KAA03184
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 Sep 2002 10:20:35 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0070EA2B@cherry.ease.lsoft.com>; Mon, 9 Sep 2002 10:22:12 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 160834 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 9 Sep 2002 10:22:10 -0400
Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 9 Sep 2002 10:12:10 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <0.0070EB78@cherry.ease.lsoft.com>;
          Mon, 9 Sep 2002 10:12:11 -0400
Message-ID:  <OSPF%2002090910221089@DISCUSS.MICROSOFT.COM>
Date:         Mon, 9 Sep 2002 10:12:10 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Christian Glomb <christian.glomb@SIEMENS.COM>
Subject: Message Flow after Link Failure
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Dear all,

let's assume we are monitoring the flow of OSPF messages within one OSPF
area. All routers have successfully come up and are running stable, i.e.
only HELLO messages are exchanged between adjacent routers. Now the link
between Router A and Router B fails such that Router A does not receive
HELLOs from Router B and vice versa. After the timer RouterDeadInterval
has expired at each Router, Router A as well as Router B assumes that the
other router (or the link to the other router) has crashed. All OSPF
information concerning the other router is removed from the database of
Router A and Router B respectively and both Routers are recalculating their
routing tables.

However Router A as well as Router B have working adjacencies to other
Routers C...E and F...H respectively and are still sending HELLOs to these
neighbors.

What happens then?

1.
Due to the fact that the ID of Router B is missing in the neighbor list
of the HELLOs send from Router A to Routers C...E and the ID of Router A
is missing in the HELLO neighbor list sent from Router B to Router F...H,
Routers C...E as well as Routers F...H are sending a LINK_STATE_REQUEST to
Router A and Router B respectively, since they notice that the topology has
changed (i.e. one link is missing).
Routers A and B resp. are responding with a LINK_STATE_UPDATE. Then the
Flooding Procedure starts due to the receipt of such a message at Routers
C...E and F...H.

OR

2.
Routers A and B resp. send a LINK_STATE_UPDATE directly to Routers C...E
and Router F...H after having updated their routing tables to trigger the
Flooding Process.

OR

3. I'm completely wrong, it's working completely different.

Thank you for your comments,

Christian.


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep  9 12:17:36 2002
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 MAA09057
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 Sep 2002 12:17:36 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0070F41E@cherry.ease.lsoft.com>; Mon, 9 Sep 2002 12:19:13 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 161385 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 9 Sep 2002 12:19:13 -0400
Received: from 195.58.103.125 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 9 Sep 2002 12:19:13 -0400
Received: from utfors.se (nat-sto.utfors.se [212.73.0.237]) by
          blooper.utfors.se (8.12.6/8.12.6) with ESMTP id g89GJBtA015969; Mon,
          9 Sep 2002 18:19:11 +0200 (MEST)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1)
            Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D6DBFBE.4050603@utfors.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-MIME-Autoconverted: from 8bit to quoted-printable by blooper.utfors.se id
                      g89GJBtA015969
Message-ID:  <3D7CC9FF.6010509@utfors.se>
Date:         Mon, 9 Sep 2002 18:19:11 +0200
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Loa Andersson <loa.andersson@UTFORS.SE>
Subject: Re: LAst Call: draft-ietf-mpls-bundle-04.txt
Comments: To: isis-wg <isis-wg@ietf.org>
Comments: cc: MPLS wg <mpls@uu.net>
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09057

All,

it is my understanding that there has been some hick-ups on
the is-is list, so I'm re-issueing this last call and extending
the time to September 29th. At the same time I would like point out
that there is an acompanying mib draft-ietf-mpls-bundle-mib-03.txt.

Also comments on the mib is welcome.

BTW, thanks to those of you who already sent us comments :)

The wg last call on

  <draft-ietf-mpls-bundle-04.txt>
  <draft-ietf-mpls-bundle-mib-03.txt>

has been extended to September 29.

/Loa

Loa Andersson wrote:

> OSPF and IS-IS working groups, (mpls wg for info)
> 
> the iesg has started the review of the mpls working group draft
> draft-ietf-mpls-bundle-04.txt. The immediate response from the iesg
> is that the draft contains OSPF and ISIS related details (see
> the included mail). After discussing with the wg chairs for ospf
> and is-is working groups, there is a feeling that the two weeks
> the iesg allocated for this last call might not be enough, since the
> draft has not been widely circulated in the routing working groups.
> 
> Therefore:
> 
> This is to initiate a last call for the
> 
> <draft-ietf-mpls-bundle-04.txt>
> 
> by the ospf and is-is working groups.
> The last call ends September 22nd at 12PM CET
> 
> 
> Please include the mpls mailing list (mpls@uu.net) in your responses.
> 
> /Loa (co-chair of the mpls wg)
> 
> -------- Original Message --------
> Subject: draft-ietf-mpls-bundle-04.txt
> Date: Tue, 27 Aug 2002 15:06:48 -0400 (EDT)
> From: Scott Bradner
> To: loa.andersson@utfors.se, swallow@cisco.com
> 
> 
> The IESG discussed this ID last week during its teleconference
> one issue was raised during the discussion
> 
> "the draft contains OSPF & ISIS
> related details and I don't remember it being LC'ed or reviewed
> in the corresponding WGs."
> 
> can you start a 2 week last call on the IS-IS and OSPF mailing
> lists for this document?
> 
> Scott
> 


-- 
     Loa Andersson
     Chief Architect,
     Utfors Research, Architecture and Future Lab (URAX)
     Utfors AB
     Råsundavägen 12
     Box 525, 169 29 Solna
     Office          +46 8 5270 2000
     Office direct   +46 8 5270 5038
     Mobile          +46 70 848 5038
     Email           loa.andersson@utfors.se
     WWW             www.utfors.se


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep  9 12:40:30 2002
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 MAA09738
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 Sep 2002 12:40:30 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0070F5A0@cherry.ease.lsoft.com>; Mon, 9 Sep 2002 12:42:07 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 161516 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 9 Sep 2002 12:42:07 -0400
Received: from 47.81.138.65 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 9 Sep 2002 12:42:07 -0400
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
          by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP
          id g89Gg4V10165 for <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 9 Sep 2002
          09:42:05 -0700 (PDT)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id
          <R06BM5K4>; Mon, 9 Sep 2002 09:42:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C2581F.C1D116F2"
Message-ID:  <5D630265EF50D311ABB60008C7917DB60AF4F8DE@zsc4c004.us.nortel.com>
Date:         Mon, 9 Sep 2002 09:42:01 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Subhasree Mandal <sumandal@NORTELNETWORKS.COM>
Subject: Re: NSSA - type 7 LSA
To: OSPF@DISCUSS.MICROSOFT.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_01C2581F.C1D116F2
Content-Type: text/plain;
        charset="iso-8859-1"

Thanks Acce.  So unless I have a stub or loopback network, I cannot avoid
this problem always.

-----Original Message-----
From: Acee Lindem [mailto:acee@REDBACK.COM]
Sent: Sunday, September 08, 2002 6:16 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: NSSA - type 7 LSA


Subhasree Mandal wrote:

> Hi,
>
> I have a question about type-7 LSA origination and route calculation.
> Let us consider the following configuration
>
>                       N1
>        R1-----------cost 10------------------R2
>         |                                     |
>         |                                     |
>         |--cost 10-------R3--------cost 10----|
>              N2                      N3
>
> Lets consider that all these routers are in an NSSA area nd R3 is an
> ASBR advertising an external
> route to network Nx.  If we want that route to be translated to type 5
> by some ABR in this NSSA area, we must set the forwarding address to a
> non-zero value (page 6, RFC 1587).  According to page 7 of
>
> the same RFC
>          "...if the intervening network is not advertised
>          into OSPF as an internal OSPF route, the forwarding
>          address should be any one of the router's active OSPF
>          interface addresses."
>
> So my type-7 LSA for Nx can have forwarding address as the interface
> address of R3 on network N3.
> When R1 computes route to Nx, it would actually use the next-hop for N3
> as the next-hop for Nx since
> the forwarding address is in N3.  So if R1 chooses to reach N3 through
> R2 (equally possible as through
> R3), the packets from R1 would reach R3 (to go out of the AS) via R2.
> In other words it is adding
> an extra hop to the route to Nx.


Hello Subhasree,

It looks like an ECMP route will be computed. However, I see your point.


>
> How do we address this issue?


By configuring a loopback address on R3 and making it part of the NSSA area.

I believe draft-ietf-ospf-nssa-update-11.txt (soon to obsolete 1587)
stipulates
that loopback addresses should be preferred over non-loopback when selecting
an NSSA interface address to use as a forwarding address. Besides avoiding
the issue you mention, selecting a loopback address offers better stability
(since you're less likely to have to re-originate all your NSSA type 7 LSAs
due to the forwarding address interface going down).

Thanks,
Acee


>
> Thanks,
> Subhasree
>


--
Acee

------_=_NextPart_001_01C2581F.C1D116F2
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: NSSA - type 7 LSA</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Thanks Acce.&nbsp; So unless I have a stub or =
loopback network, I cannot avoid this problem always.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Acee Lindem [<A =
HREF=3D"mailto:acee@REDBACK.COM">mailto:acee@REDBACK.COM</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, September 08, 2002 6:16 PM</FONT>
<BR><FONT SIZE=3D2>To: OSPF@DISCUSS.MICROSOFT.COM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: NSSA - type 7 LSA</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Subhasree Mandal wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I have a question about type-7 LSA origination =
and route calculation.</FONT>
<BR><FONT SIZE=3D2>&gt; Let us consider the following =
configuration</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; N1</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
R1-----------cost 10------------------R2</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|--cost 10-------R3--------cost 10----|</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; =
N2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; N3</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Lets consider that all these routers are in an =
NSSA area nd R3 is an</FONT>
<BR><FONT SIZE=3D2>&gt; ASBR advertising an external</FONT>
<BR><FONT SIZE=3D2>&gt; route to network Nx.&nbsp; If we want that =
route to be translated to type 5</FONT>
<BR><FONT SIZE=3D2>&gt; by some ABR in this NSSA area, we must set the =
forwarding address to a</FONT>
<BR><FONT SIZE=3D2>&gt; non-zero value (page 6, RFC 1587).&nbsp; =
According to page 7 of</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; the same RFC</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;...if the intervening network is not advertised</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
into OSPF as an internal OSPF route, the forwarding</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
address should be any one of the router's active OSPF</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
interface addresses.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; So my type-7 LSA for Nx can have forwarding =
address as the interface</FONT>
<BR><FONT SIZE=3D2>&gt; address of R3 on network N3.</FONT>
<BR><FONT SIZE=3D2>&gt; When R1 computes route to Nx, it would actually =
use the next-hop for N3</FONT>
<BR><FONT SIZE=3D2>&gt; as the next-hop for Nx since</FONT>
<BR><FONT SIZE=3D2>&gt; the forwarding address is in N3.&nbsp; So if R1 =
chooses to reach N3 through</FONT>
<BR><FONT SIZE=3D2>&gt; R2 (equally possible as through</FONT>
<BR><FONT SIZE=3D2>&gt; R3), the packets from R1 would reach R3 (to go =
out of the AS) via R2.</FONT>
<BR><FONT SIZE=3D2>&gt; In other words it is adding</FONT>
<BR><FONT SIZE=3D2>&gt; an extra hop to the route to Nx.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hello Subhasree,</FONT>
</P>

<P><FONT SIZE=3D2>It looks like an ECMP route will be computed. =
However, I see your point.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; How do we address this issue?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>By configuring a loopback address on R3 and making it =
part of the NSSA area.</FONT>
</P>

<P><FONT SIZE=3D2>I believe draft-ietf-ospf-nssa-update-11.txt (soon to =
obsolete 1587) stipulates</FONT>
<BR><FONT SIZE=3D2>that loopback addresses should be preferred over =
non-loopback when selecting</FONT>
<BR><FONT SIZE=3D2>an NSSA interface address to use as a forwarding =
address. Besides avoiding</FONT>
<BR><FONT SIZE=3D2>the issue you mention, selecting a loopback address =
offers better stability</FONT>
<BR><FONT SIZE=3D2>(since you're less likely to have to re-originate =
all your NSSA type 7 LSAs</FONT>
<BR><FONT SIZE=3D2>due to the forwarding address interface going =
down).</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Acee</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; Subhasree</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Acee</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2581F.C1D116F2--


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep  9 13:25:24 2002
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 NAA10850
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 Sep 2002 13:25:24 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0070F68F@cherry.ease.lsoft.com>; Mon, 9 Sep 2002 13:27:02 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 161750 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 9 Sep 2002 13:27:02 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 9 Sep 2002 13:27:02 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id 555BBF2C45 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Mon,  9 Sep 2002 10:27:00 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <5D630265EF50D311ABB60008C7917DB60AF4F8DE@zsc4c004.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D7CD9E5.2030803@redback.com>
Date:         Mon, 9 Sep 2002 13:27:01 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: NSSA - type 7 LSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Subhasree Mandal wrote:

> Thanks Acce.  So unless I have a stub or loopback network, I cannot
> avoid this problem always.


I can't see any with the current specification. One could change the rules
for forwarding address origination and put the onus of selecting a forwarding
address on the translating ABR(s). However, at this point I don't think it
is worth the trouble given that the problem can be solved by simply
configuring a loopback address in the OSPF NSSA on the NSSA ABR.


>
> -----Original Message-----
> From: Acee Lindem [mailto:acee@REDBACK.COM]
> Sent: Sunday, September 08, 2002 6:16 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: NSSA - type 7 LSA
>
>
> Subhasree Mandal wrote:
>
>  > Hi,
>  >
>  > I have a question about type-7 LSA origination and route calculation.
>  > Let us consider the following configuration
>  >
>  >                       N1
>  >        R1-----------cost 10------------------R2
>  >         |                                     |
>  >         |                                     |
>  >         |--cost 10-------R3--------cost 10----|
>  >              N2                      N3
>  >
>  > Lets consider that all these routers are in an NSSA area nd R3 is an
>  > ASBR advertising an external
>  > route to network Nx.  If we want that route to be translated to type 5
>  > by some ABR in this NSSA area, we must set the forwarding address to a
>  > non-zero value (page 6, RFC 1587).  According to page 7 of
>  >
>  > the same RFC
>  >          "...if the intervening network is not advertised
>  >          into OSPF as an internal OSPF route, the forwarding
>  >          address should be any one of the router's active OSPF
>  >          interface addresses."
>  >
>  > So my type-7 LSA for Nx can have forwarding address as the interface
>  > address of R3 on network N3.
>  > When R1 computes route to Nx, it would actually use the next-hop for N3
>  > as the next-hop for Nx since
>  > the forwarding address is in N3.  So if R1 chooses to reach N3 through
>  > R2 (equally possible as through
>  > R3), the packets from R1 would reach R3 (to go out of the AS) via R2.
>  > In other words it is adding
>  > an extra hop to the route to Nx.
>
>
> Hello Subhasree,
>
> It looks like an ECMP route will be computed. However, I see your point.
>
>
>  >
>  > How do we address this issue?
>
>
> By configuring a loopback address on R3 and making it part of the NSSA
> area.
>
> I believe draft-ietf-ospf-nssa-update-11.txt (soon to obsolete 1587)
> stipulates
> that loopback addresses should be preferred over non-loopback when
> selecting
> an NSSA interface address to use as a forwarding address. Besides avoiding
> the issue you mention, selecting a loopback address offers better stability
> (since you're less likely to have to re-originate all your NSSA type 7 LSAs
> due to the forwarding address interface going down).
>
> Thanks,
> Acee
>
>
>  >
>  > Thanks,
>  > Subhasree
>  >
>
>
> --
> Acee
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep  9 14:01:41 2002
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 OAA11593
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 Sep 2002 14:01:41 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0070FA76@cherry.ease.lsoft.com>; Mon, 9 Sep 2002 14:03:18 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 162030 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 9 Sep 2002 14:03:18 -0400
Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 9 Sep 2002 14:03:18 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392)
          id <01KMAM8FYUVQ8WYYWC@omega7.wr.usgs.gov> for
          OSPF@DISCUSS.MICROSOFT.COM; Mon, 09 Sep 2002 11:03:11 -0700 (PDT)
X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM
X-VMS-Cc: PMURPHY
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Message-ID:  <01KMAM8FYUVS8WYYWC@omega7.wr.usgs.gov>
Date:         Mon, 9 Sep 2002 11:03:11 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: NSSA - type 7 LSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Subhasree,

>Thanks Acce.  So unless I have a stub or loopback network, I cannot
>avoid this problem always.

Its been my experience that implementations advertise the addresses of
p-t-p or p-t-mp links as stub host addresses. Given this fact, this does
not seem like a major deficiency. It is true that a router's only
address in the NSSA could come from an interface connected to a
multiaccess network that multiple routers connect to. When that happens
this deficiency is possible. This situation is easily resolved by
configuring the router with a local (loopback) interface/address in the
NSSA.

Pat


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep  9 16:19:49 2002
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 QAA15302
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 9 Sep 2002 16:19:49 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0071035B@cherry.ease.lsoft.com>; Mon, 9 Sep 2002 16:21:27 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 162508 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 9 Sep 2002 16:21:27 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 9 Sep 2002 16:21:26 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id F32ED4BA218 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Mon,  9 Sep 2002 13:21:24 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <OSPF%2002090910221089@DISCUSS.MICROSOFT.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D7D02C4.2050707@redback.com>
Date:         Mon, 9 Sep 2002 16:21:24 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Message Flow after Link Failure
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Christian,
It is closer to #2 than #1. Assuming a single area topology,
it would be the neighbor inactivity event that triggers
re-origination of router LSAs for A and B. Refer
to section 12.4 in RFC 2328.

Christian Glomb wrote:

> Dear all,
>
> let's assume we are monitoring the flow of OSPF messages within one OSPF
> area. All routers have successfully come up and are running stable, i.e.
> only HELLO messages are exchanged between adjacent routers. Now the link
> between Router A and Router B fails such that Router A does not receive
> HELLOs from Router B and vice versa. After the timer RouterDeadInterval
> has expired at each Router, Router A as well as Router B assumes that the
> other router (or the link to the other router) has crashed. All OSPF
> information concerning the other router is removed from the database of
> Router A and Router B respectively and both Routers are recalculating their
> routing tables.
>
> However Router A as well as Router B have working adjacencies to other
> Routers C...E and F...H respectively and are still sending HELLOs to these
> neighbors.
>
> What happens then?
>
> 1.
> Due to the fact that the ID of Router B is missing in the neighbor list
> of the HELLOs send from Router A to Routers C...E and the ID of Router A
> is missing in the HELLO neighbor list sent from Router B to Router F...H,
> Routers C...E as well as Routers F...H are sending a LINK_STATE_REQUEST to
> Router A and Router B respectively, since they notice that the topology has
> changed (i.e. one link is missing).
> Routers A and B resp. are responding with a LINK_STATE_UPDATE. Then the
> Flooding Procedure starts due to the receipt of such a message at Routers
> C...E and F...H.
>
> OR
>
> 2.
> Routers A and B resp. send a LINK_STATE_UPDATE directly to Routers C...E
> and Router F...H after having updated their routing tables to trigger the
> Flooding Process.
>
> OR
>
> 3. I'm completely wrong, it's working completely different.
>
> Thank you for your comments,
>
> Christian.
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 10 03:04:14 2002
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 DAA06196
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Sep 2002 03:04:14 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0071178D@cherry.ease.lsoft.com>; Tue, 10 Sep 2002 3:05:52 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 164185 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 10 Sep 2002 03:05:52 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 10 Sep 2002 03:05:52 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0A54Y>; Tue, 10 Sep 2002 03:05:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A3287915C3@india_exch.hyderabad.mindspeed.com>
Date:         Tue, 10 Sep 2002 03:08:13 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: Message Flow after Link Failure
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Christian,

I will add to what Acee has already said. I will correct a few things you
have stated.

a) After the RouterDeadInterval when an adjacency to a neighbor is broken
the statement that

"All OSPF information concerning the other router is removed from the
database of
Router A and Router B respectively and both Routers are recalculating their
routing tables."

is wrong, we do not remove the other routers information(I assue u meant
LSA's) at all. We just update our Router LSA to state the neighbor is no
more reachable.

b) The neighbor list in a hello consists of neighbor on that particular
interface not all neighbors on all interfaces.

Or are you talking about all routers A...H on one LAN? If thats the case, if
the LAN becomes partitioned, each partition will have its own DR, and will
work accordingly.

Also check the SPF section Section 16 in RFC2328.

Thanks,
Vishwas


-----Original Message-----
From: Christian Glomb [mailto:christian.glomb@SIEMENS.COM]
Sent: Monday, September 09, 2002 7:42 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Message Flow after Link Failure


Dear all,

let's assume we are monitoring the flow of OSPF messages within one OSPF
area. All routers have successfully come up and are running stable, i.e.
only HELLO messages are exchanged between adjacent routers. Now the link
between Router A and Router B fails such that Router A does not receive
HELLOs from Router B and vice versa. After the timer RouterDeadInterval
has expired at each Router, Router A as well as Router B assumes that the
other router (or the link to the other router) has crashed. All OSPF
information concerning the other router is removed from the database of
Router A and Router B respectively and both Routers are recalculating their
routing tables.

However Router A as well as Router B have working adjacencies to other
Routers C...E and F...H respectively and are still sending HELLOs to these
neighbors.

What happens then?

1.
Due to the fact that the ID of Router B is missing in the neighbor list
of the HELLOs send from Router A to Routers C...E and the ID of Router A
is missing in the HELLO neighbor list sent from Router B to Router F...H,
Routers C...E as well as Routers F...H are sending a LINK_STATE_REQUEST to
Router A and Router B respectively, since they notice that the topology has
changed (i.e. one link is missing).
Routers A and B resp. are responding with a LINK_STATE_UPDATE. Then the
Flooding Procedure starts due to the receipt of such a message at Routers
C...E and F...H.

OR

2.
Routers A and B resp. send a LINK_STATE_UPDATE directly to Routers C...E
and Router F...H after having updated their routing tables to trigger the
Flooding Process.

OR

3. I'm completely wrong, it's working completely different.

Thank you for your comments,

Christian.


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 10 05:20:33 2002
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 FAA08059
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Sep 2002 05:20:32 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00711988@cherry.ease.lsoft.com>; Tue, 10 Sep 2002 5:22:12 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 164600 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 10 Sep 2002 05:22:11 -0400
Received: from 192.11.222.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 10 Sep 2002 05:22:11 -0400
Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com
          [135.252.18.18]) by ihemail1.firewall.lucent.com
          (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8A9M9K07695 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 10 Sep 2002 05:22:09 -0400 (EDT)
Received: by CI0026EXCH001U with Internet Mail Service (5.5.2653.19) id
          <ST99M6JF>; Tue, 10 Sep 2002 17:22:07 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Message-ID:  <31C0F08B0D18D511ACC800508BAE7B4702B9D04E@CI0026EXCH001U>
Date:         Tue, 10 Sep 2002 17:22:06 +0800
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Li, Ke Qin (Peter)" <keqinli@LUCENT.COM>
Subject: about NEXT for OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Dear all,

I've read an Internet Draft "Network Engineering Extensions (NEXT) for
OSPFv3" authored by Spencer Giacalone. And I noticed that its expire date is
September 2001. I want to
know is there any new version of the draft? Is there any related draft about
this topic? Thank you very much!

I have tried to send email to the author, but my email to the address
provided in the Draft is rejected.

Keqin Li


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 10 07:58:48 2002
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 HAA09921
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Sep 2002 07:58:47 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00711E8D@cherry.ease.lsoft.com>; Tue, 10 Sep 2002 8:00:25 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 166666 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 10 Sep 2002 08:00:25 -0400
Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 10 Sep 2002 08:00:23 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <19.00711C9D@cherry.ease.lsoft.com>;
          Tue, 10 Sep 2002 8:00:22 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <OSPF%2002091008002545@DISCUSS.MICROSOFT.COM>
Date:         Tue, 10 Sep 2002 08:00:22 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Christian Glomb <christian.glomb@SIEMENS.COM>
Subject: Re: Message Flow after Link Failure
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA09921

Acee, Vishwas,

thank you for your comments. I will try to summarize what
I've learned now:

1.
At Router A the state (in the neighbor conversation state
machine) for Router B goes to state "Down".

The following operations are then performed:
- Clear the LS Retransmission List, Database Summary List
  and the LS Request list for this neighbor.
- Cancel any pending timers.
- Destroy any pending retransmission messages.

In the interface state machine the state for the interface
connecting to Router B also goes to state "Down". Is this
true?

Refering to section 12.4 of RFC 2328 a LINK_STATE_UPDATE
containing a Router-LSA is then originated since
"
 (2) An interface's state changes (see Section 9.1).  This may
     mean that it is necessary to produce a new instance of the
     router-LSA.
"
and
"
 (4) One of the neighboring routers changes to/from the FULL
     state.  This may mean that it is necessary to produce a new
     instance of the router-LSA.  ...
"

2.
At the receipt of the LINK_STATE_UPDATE message at the remaining
neighbor routers of Router A, the flooding procedure as described
in section 13 of RFC 2328 starts at these remaining neighbors.

3.
Vishwas said: "The neighbor list in a hello consists of neighbor on
that particular interface not all neighbors on all interfaces."

Assuming that we have no networks within an area, there is always
one neighbor router connected to one interface and thus there is
only one NEIGHBOR ID per HELLO message. Is this true?
What happens if we have networks within an area? Are there HELLOs
from all routers of these networks sent to the DR of each network
which in turn includes all NEIGHBOR IDs in the HELLO message sent
to the neighbor in the area? Or does the area neighbor of the DR
only see the NEIGHBOR ID from itself?

For clarification:

            AS
       ´     |   `
    ´        |      `
  ´          |         `
Area_1     Area_2    Area_n
         ´   |   `
       ´     |     `
     NW_1   NW_2   NW_n


Thanks again a lot!

Christian.


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 10 09:34:28 2002
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 JAA13236
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Sep 2002 09:34:28 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00711E27@cherry.ease.lsoft.com>; Tue, 10 Sep 2002 9:35:05 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 166889 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 10 Sep 2002 09:35:05 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 10 Sep 2002 09:35:05 -0400
Received: from redback.com (login001.redback.com [155.53.12.18]) by
          prattle.redback.com (Postfix) with ESMTP id ACF65CAB75 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 10 Sep 2002 06:35:03 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <OSPF%2002091008002545@DISCUSS.MICROSOFT.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID:  <3D7DF4FD.2040507@redback.com>
Date:         Tue, 10 Sep 2002 09:34:53 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Message Flow after Link Failure
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit

Hello Christian,

I'm assuming the event triggering this is a neighbor
inactivity timeout between routers A and B on a single
OSPF interface.

Christian Glomb wrote:

> Acee, Vishwas,
>
> thank you for your comments. I will try to summarize what
> I've learned now:
>
> 1.
> At Router A the state (in the neighbor conversation state
> machine) for Router B goes to state "Down".
>
> The following operations are then performed:
> - Clear the LS Retransmission List, Database Summary List
>   and the LS Request list for this neighbor.
> - Cancel any pending timers.
> - Destroy any pending retransmission messages.
>
> In the interface state machine the state for the interface
> connecting to Router B also goes to state "Down". Is this
> true?


No. OSPF neighbor FSM changes will not bring the OSPF
interface FSM down.


>
> Refering to section 12.4 of RFC 2328 a LINK_STATE_UPDATE
> containing a Router-LSA is then originated since
> "
>  (2) An interface's state changes (see Section 9.1).  This may
>      mean that it is necessary to produce a new instance of the
>      router-LSA.
> "
> and
> "
>  (4) One of the neighboring routers changes to/from the FULL
>      state.  This may mean that it is necessary to produce a new
>      instance of the router-LSA.  ...
> "
>
> 2.
> At the receipt of the LINK_STATE_UPDATE message at the remaining
> neighbor routers of Router A, the flooding procedure as described
> in section 13 of RFC 2328 starts at these remaining neighbors.
>
> 3.
> Vishwas said: "The neighbor list in a hello consists of neighbor on
> that particular interface not all neighbors on all interfaces."
>
> Assuming that we have no networks within an area, there is always
> one neighbor router connected to one interface and thus there is
> only one NEIGHBOR ID per HELLO message. Is this true?
> What happens if we have networks within an area? Are there HELLOs
> from all routers of these networks sent to the DR of each network
> which in turn includes all NEIGHBOR IDs in the HELLO message sent
> to the neighbor in the area? Or does the area neighbor of the DR
> only see the NEIGHBOR ID from itself?


I think there is some confusion here. Neighbors are maintained on
an OSPF interface level. The only neighbors IDs included in HELLO
messages are those for neighbor on that interface (of course, the
areas also need to match or the hello will be rejected).


>
> For clarification:
>
>             AS
>        ´     |   `
>     ´        |      `
>   ´          |         `
> Area_1     Area_2    Area_n
>          ´   |   `
>        ´     |     `
>      NW_1   NW_2   NW_n
>
>
> Thanks again a lot!
>
> Christian.
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 10 09:37:43 2002
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 JAA13387
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Sep 2002 09:37:43 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00711F27@cherry.ease.lsoft.com>; Tue, 10 Sep 2002 9:39:23 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 166919 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 10 Sep 2002 09:39:23 -0400
Received: from 166.111.68.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 10 Sep 2002 09:39:22 -0400
Received: from chinahero ([192.168.1.192]) by csnet1.cs.tsinghua.edu.cn
          (8.9.2/8.9.2) with SMTP id WAA04407 for <OSPF@DISCUSS.MICROSOFT.COM>;
          Tue, 10 Sep 2002 22:26:53 +0900 (CDT)
References: <005b01c25668$bc22cce0$c001a8c0@chinahero> 
            <3D7A05C7.4D714D65@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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:  <008801c258d1$0520f3d0$c001a8c0@chinahero>
Date:         Tue, 10 Sep 2002 21:50:27 +0800
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Li Zhongjie <lzj@CSNET1.CS.TSINGHUA.EDU.CN>
Subject: Re: What is a MIB-II IfIndex like
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA13387

Then, in a router-LSA, how can I tell an IP address representation of "link id" from the IfIndex representation?

----- Original Message ----- 
From: "Santhosh Ram" <smanohar@CISCO.COM>
To: <OSPF@DISCUSS.MICROSOFT.COM>
Sent: Saturday, September 07, 2002 9:57 PM
Subject: Re: What is a MIB-II IfIndex like


> Zhongjie Li,
> 
> Here is the ifIndex definition from RFC 1213 which defines MIB II...
> 
>           ifIndex OBJECT-TYPE
>               SYNTAX  INTEGER
>               ACCESS  read-only
>               STATUS  mandatory
> 
>               DESCRIPTION
>                       "A unique value for each interface.  Its value
>                       ranges between 1 and the value of ifNumber.  The
>                       value for each interface must remain constant at
>                       least from one re-initialization of the entity's
>                       network management system to the next re-
>                       initialization."
>               ::= { ifEntry 1 }
> 
> HTH,
> 
> cheers,
> Santhosh.
> 
> Li Zhongjie wrote:
> >
> > I am not familiar with MIBs. A question is what a MIB-II IfIndex looks like.
> > Could it be distinguished from IP address? An example is better.
> > ---
> > Best Regards,
> >
> > Zhongjie Li
> >
> > ********************************************************************
> > *    Zhongjie Li                                                   *
> > *    Ph.D candidate, Department of Computer Science & Technology   *
> > *    Tsinghua University, Beijing, 100084, P.R.China               *
> > *    Tel: +86+10-62788109     Fax:  +86+10-62788109                *
> > *    Email: lzj@csnet1.cs.tsinghua.edu.cn                          *
> > ********************************************************************
> 


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 10 10:46:42 2002
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 KAA16267
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Sep 2002 10:46:41 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.007121A9@cherry.ease.lsoft.com>; Tue, 10 Sep 2002 10:48:21 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 167327 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 10 Sep 2002 10:48:21 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 10 Sep 2002 10:48:21 -0400
Received: from redback.com (login001.redback.com [155.53.12.18]) by
          prattle.redback.com (Postfix) with ESMTP id C54BECAB75 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 10 Sep 2002 07:48:19 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <005b01c25668$bc22cce0$c001a8c0@chinahero>            
            <3D7A05C7.4D714D65@cisco.com>
            <008801c258d1$0520f3d0$c001a8c0@chinahero>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D7E0629.2050509@redback.com>
Date:         Tue, 10 Sep 2002 10:48:09 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: What is a MIB-II IfIndex like
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Li Zhongjie wrote:

> Then, in a router-LSA, how can I tell an IP address representation of "link id" from the IfIndex representation?


Zhongjie Li,

There are ways you could be ascertain with a high degree of
success whether or not a particular router LSA link is unnumbered.
However, you really don't need to know for the SPF computation. Why
do you think it matters?


>
> ----- Original Message -----
> From: "Santhosh Ram" <smanohar@CISCO.COM>
> To: <OSPF@DISCUSS.MICROSOFT.COM>
> Sent: Saturday, September 07, 2002 9:57 PM
> Subject: Re: What is a MIB-II IfIndex like
>
>
>
>>Zhongjie Li,
>>
>>Here is the ifIndex definition from RFC 1213 which defines MIB II...
>>
>>          ifIndex OBJECT-TYPE
>>              SYNTAX  INTEGER
>>              ACCESS  read-only
>>              STATUS  mandatory
>>
>>              DESCRIPTION
>>                      "A unique value for each interface.  Its value
>>                      ranges between 1 and the value of ifNumber.  The
>>                      value for each interface must remain constant at
>>                      least from one re-initialization of the entity's
>>                      network management system to the next re-
>>                      initialization."
>>              ::= { ifEntry 1 }
>>
>>HTH,
>>
>>cheers,
>>Santhosh.
>>
>>Li Zhongjie wrote:
>>
>>>I am not familiar with MIBs. A question is what a MIB-II IfIndex looks like.
>>>Could it be distinguished from IP address? An example is better.
>>>---
>>>Best Regards,
>>>
>>>Zhongjie Li
>>>
>>>********************************************************************
>>>*    Zhongjie Li                                                   *
>>>*    Ph.D candidate, Department of Computer Science & Technology   *
>>>*    Tsinghua University, Beijing, 100084, P.R.China               *
>>>*    Tel: +86+10-62788109     Fax:  +86+10-62788109                *
>>>*    Email: lzj@csnet1.cs.tsinghua.edu.cn                          *
>>>********************************************************************
>>>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 10 21:50:21 2002
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 VAA02009
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Sep 2002 21:50:21 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00713D5B@cherry.ease.lsoft.com>; Tue, 10 Sep 2002 21:51:59 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 169295 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 10 Sep 2002 21:51:59 -0400
Received: from 192.11.222.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 10 Sep 2002 21:51:59 -0400
Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com
          [135.252.18.18]) by ihemail2.firewall.lucent.com
          (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8B1pvs28140 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 10 Sep 2002 21:51:58 -0400 (EDT)
Received: by CI0026EXCH001U with Internet Mail Service (5.5.2653.19) id
          <ST99NDWK>; Wed, 11 Sep 2002 09:51:51 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="gb2312"
Message-ID:  <31C0F08B0D18D511ACC800508BAE7B4702B9D04F@CI0026EXCH001U>
Date:         Wed, 11 Sep 2002 09:51:50 +0800
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Li, Ke Qin (Peter)" <keqinli@LUCENT.COM>
Subject: Opaque LSA for OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi all,

Is there any RFC or Internet Draft about Opaque LSA for OSPFv3? In OSPFv3,
type 9 LSA is intra-area-prefix-LSA, so the opaque LSAs defined in RFC2370
can not be used with OSPFv3.

Thank you.

Keqin Li
Bell Labs Research China
Tel: 86-010-68748088-8438


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 11 01:02:07 2002
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 BAA04828
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Sep 2002 01:02:07 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.007143DB@cherry.ease.lsoft.com>; Wed, 11 Sep 2002 1:03:45 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 169819 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 11 Sep 2002 01:03:45 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 11 Sep 2002 01:03:45 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0A7WD>; Wed, 11 Sep 2002 01:03:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="gb2312"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A3287915CD@india_exch.hyderabad.mindspeed.com>
Date:         Wed, 11 Sep 2002 01:05:46 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: Opaque LSA for OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Keqin Li,

In OSPFv3 we do not drop LSA's if the type is unknown they are still
processed and flooded according to the flooding scope, if U-bit is set to 1.
This mechanism makes all unrecognized LSA's as if they are opaque LSA's.

For running OSPFv3 we do not use the ships in the night approach(ie the same
stack running OSPFv3/OSPFv2), instead we use a different stack for it. Hence
overlapping types between OSPFv2 and OSPFv3 would not cause a problem.
Besides the LS-type of Intra-Area-Prefix-LSA is 0x2009. Check section A.4.2.
1 RFC2740.

Please let me know if it clears ur doubt.

Thanks,
Vishwas

-----Original Message-----
From: Li, Ke Qin (Peter) [mailto:keqinli@LUCENT.COM]
Sent: Wednesday, September 11, 2002 7:22 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Opaque LSA for OSPFv3


Hi all,

Is there any RFC or Internet Draft about Opaque LSA for OSPFv3? In OSPFv3,
type 9 LSA is intra-area-prefix-LSA, so the opaque LSAs defined in RFC2370
can not be used with OSPFv3.

Thank you.

Keqin Li
Bell Labs Research China
Tel: 86-010-68748088-8438


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 11 01:02:29 2002
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 BAA04847
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Sep 2002 01:02:29 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0071432D@cherry.ease.lsoft.com>; Wed, 11 Sep 2002 1:04:08 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 169851 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 11 Sep 2002 01:04:08 -0400
Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 11 Sep 2002 01:04:08 -0400
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by
          motgate.mot.com (motgate 2.1) with ESMTP id WAA22532 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 10 Sep 2002 22:04:07 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38])
          by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id WAA24527 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 10 Sep 2002 22:01:23 -0700 (MST)]
Received: from arc.corp.mot.com (arthurd.arc.corp.mot.com [10.238.80.59]) by
          homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g8B4uK7C024190
          for <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 11 Sep 2002 14:56:21 +1000
          (EST)
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <31C0F08B0D18D511ACC800508BAE7B4702B9D04F@CI0026EXCH001U>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D7ECCF3.BCBAE99E@arc.corp.mot.com>
Date:         Wed, 11 Sep 2002 14:56:19 +1000
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Arthur Dimitrelis <arthurd@ARC.CORP.MOT.COM>
Subject: Re: Opaque LSA for OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi,

this has come up quite recently. Yasuhiro and Vishwas have pointed out that
the handling of opaque LSAs is built in to OSPFv3 because it is possible to
specify how a particular unknown LSA is to be handled (see 2.9 of RFC2740). So
the ideas presented in RFC2370 for OSPFv2 are rolled into the OSPFv3
specification.

I was thrown off by the fact that 2370 uses the word 'opaque' whereas 2740
does not. My understanding is that a 2370 compliant router provides the same
functionality as a 2740 compliant router in terms of handling LSAs of unknown
type.

cheers,
Arthur

"Li, Ke Qin (Peter)" wrote:

> Hi all,
>
> Is there any RFC or Internet Draft about Opaque LSA for OSPFv3? In OSPFv3,
> type 9 LSA is intra-area-prefix-LSA, so the opaque LSAs defined in RFC2370
> can not be used with OSPFv3.
>
> Thank you.
>
> Keqin Li
> Bell Labs Research China
> Tel: 86-010-68748088-8438


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 11 01:16:25 2002
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 BAA04964
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Sep 2002 01:16:25 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0071432D@cherry.ease.lsoft.com>; Wed, 11 Sep 2002 1:18:04 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 169879 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 11 Sep 2002 01:18:04 -0400
Received: from 192.11.222.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 11 Sep 2002 01:18:04 -0400
Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com
          [135.252.18.18]) by ihemail1.firewall.lucent.com
          (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8B5I2D03810 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 11 Sep 2002 01:18:02 -0400 (EDT)
Received: by CI0026EXCH001U with Internet Mail Service (5.5.2653.19) id
          <ST99N2H0>; Wed, 11 Sep 2002 13:18:00 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="gb2312"
Message-ID:  <31C0F08B0D18D511ACC800508BAE7B4702B9D053@CI0026EXCH001U>
Date:         Wed, 11 Sep 2002 13:18:00 +0800
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Li, Ke Qin (Peter)" <keqinli@LUCENT.COM>
Subject: Re: Opaque LSA for OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Thank you very much!

Keqin Li

> -----Original Message-----
> From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM]
> Sent: Wednesday, September 11, 2002 1:06 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: Opaque LSA for OSPFv3
>
>
> Hi Keqin Li,
>
> In OSPFv3 we do not drop LSA's if the type is unknown they are still
> processed and flooded according to the flooding scope, if
> U-bit is set to 1.
> This mechanism makes all unrecognized LSA's as if they are
> opaque LSA's.
>
> For running OSPFv3 we do not use the ships in the night
> approach(ie the same
> stack running OSPFv3/OSPFv2), instead we use a different
> stack for it. Hence
> overlapping types between OSPFv2 and OSPFv3 would not cause a problem.
> Besides the LS-type of Intra-Area-Prefix-LSA is 0x2009. Check
> section A.4.2.
> 1 RFC2740.
>
> Please let me know if it clears ur doubt.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Li, Ke Qin (Peter) [mailto:keqinli@LUCENT.COM]
> Sent: Wednesday, September 11, 2002 7:22 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Opaque LSA for OSPFv3
>
>
> Hi all,
>
> Is there any RFC or Internet Draft about Opaque LSA for
> OSPFv3? In OSPFv3,
> type 9 LSA is intra-area-prefix-LSA, so the opaque LSAs
> defined in RFC2370
> can not be used with OSPFv3.
>
> Thank you.
>
> Keqin Li
> Bell Labs Research China
> Tel: 86-010-68748088-8438
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 11 11:05:04 2002
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 LAA12099
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Sep 2002 11:05:04 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00715940@cherry.ease.lsoft.com>; Wed, 11 Sep 2002 11:06:43 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 175031 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 11 Sep 2002 11:06:43 -0400
Received: from 166.111.68.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 11 Sep 2002 11:06:42 -0400
Received: from chinahero ([192.168.1.192]) by csnet1.cs.tsinghua.edu.cn
          (8.9.2/8.9.2) with SMTP id OAA06285 for <OSPF@DISCUSS.MICROSOFT.COM>;
          Wed, 11 Sep 2002 14:33:44 +0900 (CDT)
References: <005b01c25668$bc22cce0$c001a8c0@chinahero>                       
            <3D7A05C7.4D714D65@cisco.com>           
            <008801c258d1$0520f3d0$c001a8c0@chinahero> 
            <3D7E0629.2050509@redback.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
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:  <003a01c25958$17d42b50$c001a8c0@chinahero>
Date:         Wed, 11 Sep 2002 13:56:26 +0800
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Li Zhongjie <lzj@CSNET1.CS.TSINGHUA.EDU.CN>
Subject: Re: What is a MIB-II IfIndex like
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA12099

Hi Acee,
     yes, it matters in one of my researches. I have to determine the interface type just by its router LSAs.
    Would you suggest some means to achieve this? 

----- Original Message ----- 
From: "Acee Lindem" <acee@REDBACK.COM>
To: <OSPF@DISCUSS.MICROSOFT.COM>
Sent: Tuesday, September 10, 2002 10:48 PM
Subject: Re: What is a MIB-II IfIndex like


> Li Zhongjie wrote:
> 
> > Then, in a router-LSA, how can I tell an IP address representation of "link id" from the IfIndex representation?
> 
> 
> Zhongjie Li,
> 
> There are ways you could be ascertain with a high degree of
> success whether or not a particular router LSA link is unnumbered.
> However, you really don't need to know for the SPF computation. Why
> do you think it matters?
> 
> 
> >
> > ----- Original Message -----
> > From: "Santhosh Ram" <smanohar@CISCO.COM>
> > To: <OSPF@DISCUSS.MICROSOFT.COM>
> > Sent: Saturday, September 07, 2002 9:57 PM
> > Subject: Re: What is a MIB-II IfIndex like
> >
> >
> >
> >>Zhongjie Li,
> >>
> >>Here is the ifIndex definition from RFC 1213 which defines MIB II...
> >>
> >>          ifIndex OBJECT-TYPE
> >>              SYNTAX  INTEGER
> >>              ACCESS  read-only
> >>              STATUS  mandatory
> >>
> >>              DESCRIPTION
> >>                      "A unique value for each interface.  Its value
> >>                      ranges between 1 and the value of ifNumber.  The
> >>                      value for each interface must remain constant at
> >>                      least from one re-initialization of the entity's
> >>                      network management system to the next re-
> >>                      initialization."
> >>              ::= { ifEntry 1 }
> >>
> >>HTH,
> >>
> >>cheers,
> >>Santhosh.
> >>
> >>Li Zhongjie wrote:
> >>
> >>>I am not familiar with MIBs. A question is what a MIB-II IfIndex looks like.
> >>>Could it be distinguished from IP address? An example is better.
> >>>---
> >>>Best Regards,
> >>>
> >>>Zhongjie Li
> >>>
> >>>********************************************************************
> >>>*    Zhongjie Li                                                   *
> >>>*    Ph.D candidate, Department of Computer Science & Technology   *
> >>>*    Tsinghua University, Beijing, 100084, P.R.China               *
> >>>*    Tel: +86+10-62788109     Fax:  +86+10-62788109                *
> >>>*    Email: lzj@csnet1.cs.tsinghua.edu.cn                          *
> >>>********************************************************************
> >>>
> 
> 
> --
> Acee
> 
> 


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 11 11:30:06 2002
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 LAA13061
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Sep 2002 11:30:06 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00715A88@cherry.ease.lsoft.com>; Wed, 11 Sep 2002 11:31:47 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 175338 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 11 Sep 2002 11:31:47 -0400
Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 11 Sep 2002 11:31:46 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id LAA13676 for <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 11 Sep 2002
          11:31:44 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA12786
          for <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 11 Sep 2002 11:31:45 -0400
          (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R68QSNSJ>; Wed, 11 Sep 2002 11:31:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <39469E08BD83D411A3D900204840EC55763326@vie-msgusr-01.dc.fore.com>
Date:         Wed, 11 Sep 2002 11:31:41 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Naidu, Venkata" <Venkata.Naidu@MARCONI.COM>
Subject: Re: What is a MIB-II IfIndex like
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Li,

->      yes, it matters in one of my researches. I have to
-> determine the interface type just by its router LSAs.
->     Would you suggest some means to achieve this?

  You can assume that, if the first byte in the Link Data
  is zero then it can be an unnumbered link else it is
  numbered.

  Most of the implementations (including Moy's) does the
  same trick. It is safe, because, it is assumed that ifindexes
  are increasing starting from 1 and can't grow more than 2 bytes
  Unless, your router is configured with more than 2^27
  links.

--
Venkata.


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 12 08:47:52 2002
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 IAA21530
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Sep 2002 08:47:52 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00717EFE@cherry.ease.lsoft.com>; Thu, 12 Sep 2002 8:49:31 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 183650 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 12 Sep 2002 08:49:30 -0400
Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 12 Sep 2002 08:39:29 -0400
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <SWAWBWPJ>;
          Thu, 12 Sep 2002 18:11:53 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <55E277B99171E041ABF5F4B1C6DDCA0681A452@haritha.hclt.com>
Date:         Thu, 12 Sep 2002 18:11:39 +0530
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Sudharsana V - CTD, Chennai." <vsudharsana@CTD.HCLTECH.COM>
Subject: Recalculating all AS-External routes on reception of ASBR summary LSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi,
Section 13.2 of RFC 2328 says -
"Summary-LSAs
            The best route to the destination described by the summary-
            LSA must be recalculated (see Section 16.5).  If this
            destination is an AS boundary router, it may also be
            necessary to re-examine all the AS-external-LSAs."

When route to an ASBR changes (cost changes or becomes unreachable), is it
not sufficient to recalculate external routes to only the destinations
advertised by the concerned ASBR?
Why should we re-examine all the AS-External-LSAs?

Thanks,
Sudharsana.V


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 12 09:52:23 2002
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 JAA23569
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Sep 2002 09:52:22 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0071819F@cherry.ease.lsoft.com>; Thu, 12 Sep 2002 9:54:03 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 183895 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 12 Sep 2002 09:54:01 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 12 Sep 2002 09:54:01 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id A4788262806 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 12 Sep 2002 06:53:36 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <55E277B99171E041ABF5F4B1C6DDCA0681A452@haritha.hclt.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D809C3C.7070004@redback.com>
Date:         Thu, 12 Sep 2002 09:53:00 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Recalculating all AS-External routes on reception of ASBR summary
         LSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Sudharsana V - CTD, Chennai. wrote:

> Hi,
> Section 13.2 of RFC 2328 says -
> "Summary-LSAs
>             The best route to the destination described by the summary-
>             LSA must be recalculated (see Section 16.5).  If this
>             destination is an AS boundary router, it may also be
>             necessary to re-examine all the AS-external-LSAs."
>
> When route to an ASBR changes (cost changes or becomes unreachable), is it
> not sufficient to recalculate external routes to only the destinations
> advertised by the concerned ASBR?


Yes.


> Why should we re-examine all the AS-External-LSAs?


You can make this optimization if you wish. In the case of the intra-area
SPF, RFC 2328 explicitly states that optimizations are possible. The same
statement would apply to incremental calculation corner cases. Keep in
mind that if the path to one ASBR changes, there is chance that the cost
to other ASBRs will change as well.


>
> Thanks,
> Sudharsana.V
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 12 12:42:28 2002
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 MAA28856
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Sep 2002 12:42:27 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.007186F6@cherry.ease.lsoft.com>; Thu, 12 Sep 2002 12:44:08 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 184699 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 12 Sep 2002 12:44:08 -0400
Received: from 157.181.1.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 12 Sep 2002 12:44:08 -0400
Received: from pandora.inf.elte.hu (pandora.inf.elte.hu [157.181.161.17]) by
          mx1.elte.hu (Postfix) with ESMTP id 1F7FA4404D for
          <ospf@discuss.microsoft.com>; Thu, 12 Sep 2002 18:44:07 +0200 (CEST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.A41.4.31.0209121813350.64668-100000@pandora.inf.elte.hu>
Date:         Thu, 12 Sep 2002 18:44:07 +0200
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Nohl Attila Rajmund <nar@INF.ELTE.HU>
Subject: When to calculate DR?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hello!

I configured an Ethernet link between two GNU zebra routers into an other
area, when I observed the following: after I configured both interfaces,
the routers waited for about RouterDeadInterval before they formed full
adjacency. During this time their respective neighbor state machines were
in 2-Way state. According to the RFC 2328, they should advance from the
2-Way state to the ExStart state, when the 2-WayReceived event happens
and and "an adjacency should be established with the neighbor (see
Section 10.4)". Unfortunately, according to the rules in 10.4, they
cannot form an adjacency, because both the router and its neighbor does
not mark itself as as Designated Router. But after about
RouterDeadInterval seconds, one of them marks itself as Designated
Router, and they form adjacency.

My question is: when I configure an interface into a new area, and it
receives a Hello from the new area, why does it not elect a Designated
Router? In the scenario above, the routers exchanged several Hello
packets without electing a DR.

My guess is that when I change the area of an interface, the interface's
state machine somehow goes into DROther (at least this is, what 'show ip
ospf neighbor' shows), and only leaves it after the WaitTimer fires.
What I don't understand is that "somehow" above.

                                Bye,NAR


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 12 14:19:29 2002
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 OAA02103
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Sep 2002 14:19:29 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00718E5B@cherry.ease.lsoft.com>; Thu, 12 Sep 2002 14:19:17 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 185227 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 12 Sep 2002 14:19:16 -0400
Received: from 134.56.3.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 12 Sep 2002 14:09:16 -0400
Received: from unet.net.com (fremont-ns2.net.com [134.56.112.30]) by
          relay1.net.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16499 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 12 Sep 2002 11:05:12 -0700 (PDT)
Received: from west-mail.net.com by unet.net.com (8.9.3/SMI-SVR4) id LAA02003;
          Thu, 12 Sep 2002 11:10:05 -0700 (PDT)
Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging
          Server 3.6)  with ESMTP id AAA1DEB for <OSPF@DISCUSS.MICROSOFT.COM>;
          Thu, 12 Sep 2002 11:09:14 -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:  <3D80D849.3207E443@net.com>
Date:         Thu, 12 Sep 2002 11:09:13 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: Question about NSSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi all,
                                   ASBR
      -----     -----     -----    -----     -----
     |     |   |     |   |     |  |     |   |     |
     | R1  |   | R2  |   |  R3 |  |  R4 |   | R5  |
     |     |   |     |   |     |  |     |   |     |
      -----     -----     -----    -----     -----
          |     |   |      |  |     |  |     |
           -----     ------    -----    -----
           AREA1     AREA 0    AREA2    RIP Network

If I configure for the above setup and do a redistribution
on ASBR, R1 will recieve the type-5 LSA for the externa
network. In that case rechability between R1 and R5 is working
fine.

If I change the Area2 to NSSA but I dont load the config
for redistribution on the NSSA ASBR(R4), does the external
rip network will be still reachable from the R1(as it has
the type5 LSA in its LSD)

Thanks in advance,
Mani


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 12 15:19:48 2002
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 PAA04394
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Sep 2002 15:19:48 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00718FEE@cherry.ease.lsoft.com>; Thu, 12 Sep 2002 15:21:27 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 185531 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 12 Sep 2002 15:21:28 -0400
Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 12 Sep 2002 15:21:27 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392)
          id <01KMEVTHZOKM8WYXDY@omega7.wr.usgs.gov> for
          OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Sep 2002 12:21:25 -0700 (PDT)
X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM
X-VMS-Cc: PMURPHY
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Message-ID:  <01KMEVTHZPIG8WYXDY@omega7.wr.usgs.gov>
Date:         Thu, 12 Sep 2002 12:21:25 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: Question about NSSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Mani,

This depends on the implementation. Anytime you change the OSPF area
type and don't reset, strange things might happen. Since changing the
area type from Standard to NSSA forces every one of the area's
adjacencies to reset, there is some hope the old standard area's type
4 summary LSAs and its type 5 external LSAs will be flushed. If just
the type 4 LSAs are flushed, the original Type 5 LSA should no longer
compute a forwarding path.

Note that by default cisco's implementation requires that
redistribution into the NSSA must be specifically disabled. I can't
speak for other implementations. In this case if you don't
specifically disabled redistribution into the NSSA when you change
the area type to NSSA, then a new Type 5 advertisement will be
generated by the NSSA translator, presumably R3, with perhaps the
same forwarding address. This Type 5 LSA should install.

Pat


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 12 16:42:39 2002
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 QAA07517
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Sep 2002 16:42:39 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.007191DB@cherry.ease.lsoft.com>; Thu, 12 Sep 2002 16:44:18 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 185691 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 12 Sep 2002 16:44:18 -0400
Received: from 134.56.3.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 12 Sep 2002 16:34:18 -0400
Received: from unet.net.com (fremont-ns2.net.com [134.56.112.30]) by
          relay1.net.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23880 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 12 Sep 2002 13:30:13 -0700 (PDT)
Received: from west-mail.net.com by unet.net.com (8.9.3/SMI-SVR4) id NAA02876;
          Thu, 12 Sep 2002 13:35:07 -0700 (PDT)
Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging
          Server 3.6)  with ESMTP id AAA51E8 for <OSPF@DISCUSS.MICROSOFT.COM>;
          Thu, 12 Sep 2002 13:34:16 -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
References: <01KMEVTHZPIG8WYXDY@omega7.wr.usgs.gov>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D80FA47.D4B1CC07@net.com>
Date:         Thu, 12 Sep 2002 13:34:15 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: Re: Question about NSSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Pat,
 Thanks for the explanation.

 But still my doubt is not fully cleared.
 This is what I understood from your explanation,
 correct me if i am wrong.

 On changing Area2 to NSSA,

 1 - if redistribution is not disabled, then R3 will
     translate the type7 to type5 LSA and inject it in to
     backbone. So that connectivity is not broken in between
     R1 and R5.

 2 - if redistribution is disabled, R4 will flush the
     type 4 and type5 LSA which it generated previously.
     So that R1 will not be able to reach the external
     network.

Thanks,
Mani


"Pat Murphy - (650)329-4044" wrote:
>
> Mani,
>
> This depends on the implementation. Anytime you change the OSPF area
> type and don't reset, strange things might happen. Since changing the
> area type from Standard to NSSA forces every one of the area's
> adjacencies to reset, there is some hope the old standard area's type
> 4 summary LSAs and its type 5 external LSAs will be flushed. If just
> the type 4 LSAs are flushed, the original Type 5 LSA should no longer
> compute a forwarding path.
>
> Note that by default cisco's implementation requires that
> redistribution into the NSSA must be specifically disabled. I can't
> speak for other implementations. In this case if you don't
> specifically disabled redistribution into the NSSA when you change
> the area type to NSSA, then a new Type 5 advertisement will be
> generated by the NSSA translator, presumably R3, with perhaps the
> same forwarding address. This Type 5 LSA should install.
>
> Pat


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 12 17:40:41 2002
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 RAA08870
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Sep 2002 17:40:41 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0071940F@cherry.ease.lsoft.com>; Thu, 12 Sep 2002 17:42:22 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 185913 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 12 Sep 2002 17:42:22 -0400
Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 12 Sep 2002 17:42:22 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392)
          id <01KMF0R6JX728WYXDY@omega7.wr.usgs.gov> for
          OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Sep 2002 14:42:20 -0700 (PDT)
X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM
X-VMS-Cc: PMURPHY,mani_devarajan@net.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Message-ID:  <01KMF0R6JX6O8WYXDY@omega7.wr.usgs.gov>
Date:         Thu, 12 Sep 2002 14:42:20 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: Question about NSSA
Comments: cc: MANI_DEVARAJAN@NET.COM
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Mani,

> 1 - if redistribution is not disabled, then R3 will
>     translate the type7 to type5 LSA and inject it in to
>     backbone. So that connectivity is not broken in between
>     R1 and R5.

Correct.


> 2 - if redistribution is disabled, R4 will flush the
>     type 4 and type5 LSA which it generated previously.
>     So that R1 will not be able to reach the external
>     network.

There is no relationship between the disabling of
redistribution and the flushing of the standard area's type 4
and type 5 LSAs. The latter should be done regardless when
the area type is changed to NSSA. Assuming they are flushed
(again it depends on the completeness of the implementation)
the disabling of redistribution will prevent R1 from reaching
the original Type 5 LSA's network through R4, as there won't
be a Type 5 LSA for the network with a forwarding address
from R4.

Pat


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 12 23:15:04 2002
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 XAA14573
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Sep 2002 23:15:04 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0071A113@cherry.ease.lsoft.com>; Thu, 12 Sep 2002 23:16:44 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 186459 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 12 Sep 2002 23:16:44 -0400
Received: from 134.56.3.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 12 Sep 2002 23:06:44 -0400
Received: from isis.net.com (fremont-ns1.net.com [134.56.112.20]) by
          relay1.net.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12684 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 12 Sep 2002 20:02:40 -0700 (PDT)
Received: from west-mail.net.com by isis.net.com (8.9.3/SMI-SVR4) id UAA09168;
          Thu, 12 Sep 2002 20:07:33 -0700 (PDT)
Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging
          Server 3.6)  with ESMTP id AAA6473 for <OSPF@DISCUSS.MICROSOFT.COM>;
          Thu, 12 Sep 2002 20:06:42 -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:  <3D815641.AF55C3F9@net.com>
Date:         Thu, 12 Sep 2002 20:06:41 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: Question about the default route in NSSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi all,

                ASBR
      -----     -----     -----    -----     -----     -----
     |     |   |     |   |     |  |     |   |     |   |     |
     | R1  |   | R2  |   |  R3 |  |  R4 |   | R5  |   |  R6 |
     |     |   |     |   |     |  |     |   |     |   |     |
      -----     -----     -----    -----     -----     -----
          |     |   |      |  |     |  |     |   |     |
           -----     ------    -----    -----     -----
           RIP-I     AREA 1    AREA 0   AREA 2    RIP-II
                                        NSSA

In the above setup, If R2 is configured to redistribute for
RIP-I destination into ospf cloud, the type-5 LSA will not
reach the AREA 2 as it is configured as NSSA.

So the External network RIP-I will be unreachable from AREA2.

So my question is, does NSSA ABR(R4) must inject type7 default
route in to AREA2 or we need manually configure default route
on R4 for the RIP I destination network.

Thanks in advance,
Mani


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep 13 00:25:26 2002
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 AAA15654
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Sep 2002 00:25:26 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0071A534@cherry.ease.lsoft.com>; Fri, 13 Sep 2002 0:27:07 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 186705 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 13 Sep 2002 00:27:07 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 13 Sep 2002 00:27:07 -0400
Received: from redback.com (login001.redback.com [155.53.12.18]) by
          prattle.redback.com (Postfix) with ESMTP id 5180E18D3ED for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 12 Sep 2002 21:27:05 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <Pine.A41.4.31.0209121813350.64668-100000@pandora.inf.elte.hu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D8168EC.6020903@redback.com>
Date:         Fri, 13 Sep 2002 00:26:20 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: When to calculate DR?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Nohl Attila Rajmund wrote:

> Hello!
>
> I configured an Ethernet link between two GNU zebra routers into an other
> area, when I observed the following: after I configured both interfaces,
> the routers waited for about RouterDeadInterval before they formed full
> adjacency. During this time their respective neighbor state machines were
> in 2-Way state. According to the RFC 2328, they should advance from the
> 2-Way state to the ExStart state, when the 2-WayReceived event happens
> and and "an adjacency should be established with the neighbor (see
> Section 10.4)". Unfortunately, according to the rules in 10.4, they
> cannot form an adjacency, because both the router and its neighbor does
> not mark itself as as Designated Router. But after about
> RouterDeadInterval seconds, one of them marks itself as Designated
> Router, and they form adjacency.
>
> My question is: when I configure an interface into a new area, and it
> receives a Hello from the new area, why does it not elect a Designated
> Router? In the scenario above, the routers exchanged several Hello
> packets without electing a DR.

>
> My guess is that when I change the area of an interface, the interface's
> state machine somehow goes into DROther (at least this is, what 'show ip
> ospf neighbor' shows), and only leaves it after the WaitTimer fires.
> What I don't understand is that "somehow" above.


Nar,

Refer to figure 11 on page 68 in RFC 2328 and you'll see that this behavior
is correct. However, the interface state should be displayed as "Waiting" rather
than "DROther". Over the years, I've received complaints about this from
lots of people testing OSPF but not from people actually operating OSPF
networks. Has anyone implemented a proprietary mechanism to speed up
DR election in cases like these?

Thanks,
Acee


>
>                                 Bye,NAR
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep 13 05:43:54 2002
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 FAA29741
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Sep 2002 05:43:54 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0071ADF4@cherry.ease.lsoft.com>; Fri, 13 Sep 2002 5:45:34 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 187755 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 13 Sep 2002 05:45:34 -0400
Received: from 216.136.173.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Fri, 13 Sep 2002 05:45:34 -0400
Received: from [203.200.20.226] by web12404.mail.yahoo.com via HTTP; Fri, 13
          Sep 2002 02:45:33 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020913094533.39373.qmail@web12404.mail.yahoo.com>
Date:         Fri, 13 Sep 2002 02:45:33 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Rohit Gupta <rohitgupta416@YAHOO.COM>
Subject: rfc 2370 doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi,
RFC 2370 in its abstract says that "This memo defines
enhancements to the OSPF protocol to support a new ..
application-specific information.  The information
field may be used directly by OSPF or by other
applications"

My doubt is that how can OSPF use Opaque LSAs for its
own purposes as it doesnt run SPF over these LSAs?

I can understand their use for TE/MPLS/GMPLS but their
use with OSPF is not clear.

Thanks in advance

-- Rohit




__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep 13 10:27:39 2002
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 KAA06874
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Sep 2002 10:27:38 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0071B39C@cherry.ease.lsoft.com>; Fri, 13 Sep 2002 10:29:18 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 189688 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 13 Sep 2002 10:29:17 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 13 Sep 2002 10:29:17 -0400
Received: from redback.com (login001.redback.com [155.53.12.18]) by
          prattle.redback.com (Postfix) with ESMTP id 34BCECAB74 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 13 Sep 2002 07:29:17 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <20020913094533.39373.qmail@web12404.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D81F60B.5090802@redback.com>
Date:         Fri, 13 Sep 2002 10:28:27 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: rfc 2370 doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Rohit Gupta wrote:

> Hi,
> RFC 2370 in its abstract says that "This memo defines
> enhancements to the OSPF protocol to support a new ..
> application-specific information.  The information
> field may be used directly by OSPF or by other
> applications"
>
> My doubt is that how can OSPF use Opaque LSAs for its
> own purposes as it doesnt run SPF over these LSAs?


Rohit,

You can lay your doubts to rest. RFC 2370 describes the generic
handling of opaque LSAs. An OSPF opaque LSA application may
not require examination of these LSAs during the SPF computation.
For example, OSPF hitless restart does not. There is nothing
precluding a new OSPF opaque LSA application from requiring
reachability to the originating router as determined by the
SPF computation.

Hope this helps,
Acee


>
> I can understand their use for TE/MPLS/GMPLS but their
> use with OSPF is not clear.
>
> Thanks in advance
>
> -- Rohit
>
>
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! News - Today's headlines
> http://news.yahoo.com
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep 13 11:10:40 2002
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 LAA08456
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Sep 2002 11:10:40 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0071B4C1@cherry.ease.lsoft.com>; Fri, 13 Sep 2002 11:12:21 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 189939 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 13 Sep 2002 11:12:21 -0400
Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 13 Sep 2002 11:12:21 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id LAA00326 for <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 13 Sep 2002
          11:12:19 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03494
          for <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 13 Sep 2002 11:12:19 -0400
          (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <SW7D4KAG>; Fri, 13 Sep 2002 11:12:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <39469E08BD83D411A3D900204840EC55763334@vie-msgusr-01.dc.fore.com>
Date:         Fri, 13 Sep 2002 11:12:05 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Naidu, Venkata" <Venkata.Naidu@MARCONI.COM>
Subject: Re: rfc 2370 doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Rohit,

-> Hi,
-> RFC 2370 in its abstract says that "This memo defines
-> enhancements to the OSPF protocol to support a new ..
-> application-specific information.  The information
-> field may be used directly by OSPF or by other
-> applications"
->
-> My doubt is that how can OSPF use Opaque LSAs for its
-> own purposes as it doesnt run SPF over these LSAs?

  It is a very naive idea that `all the information exchanged
  by OSPF LSAs must be used in SPF. If not, then the
  information is not for OSPF use`. OSPF floods/uses lot of
  flooded information for *optimization*, *reliability*,
  *accuracy* etc reasons (other than just SPF purpose).

-> I can understand their use for TE/MPLS/GMPLS but their
-> use with OSPF is not clear.

  For example, OSPF uses Opaque LSAs for its own purpose:
    - Hitless Restart
    - Flooding Optimizations
    - Dynamic Hostname
    - Dynamic Mesh Groups
    - If CSPF is implemented in OSPF then TE LSAs are also
      considered as part of OSPF (not part of application).
      There are some implementations that did this too.
      In the history, there are implementations where,
      new LSA types are used, instead of Opaque LSAs.
      (for example, draft-zhang-qos-ospf-01 and SriSuresh
      TE LSAs etc)

  For that matter, what is the difference between an *application*
  and *self* ? Where is the clear demarcation ? If you look at
  protocols so closely, you can *differentiate* each sub-module
  as a separate application (using some services provided by
  other sub-modules). If you look at protocols at 1000 ft view,
  you can see *integrated* view, such that the whole protocol
  itself is an application on top of some lower layer protocols.

--
Venkata.


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep 13 13:34:03 2002
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 NAA13193
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 13 Sep 2002 13:34:03 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0071B8B9@cherry.ease.lsoft.com>; Fri, 13 Sep 2002 13:35:44 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 190697 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 13 Sep 2002 13:35:44 -0400
Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 13 Sep 2002 13:35:44 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392)
          id <01KMG6FP0H348WZH2D@omega7.wr.usgs.gov> for
          OSPF@DISCUSS.MICROSOFT.COM; Fri, 13 Sep 2002 10:35:39 -0700 (PDT)
X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM
X-VMS-Cc: PMURPHY,mani_devarajan@net.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Message-ID:  <01KMG6FP0IZ68WZH2D@omega7.wr.usgs.gov>
Date:         Fri, 13 Sep 2002 10:35:39 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: Question about the default route in NSSA
Comments: cc: MANI_DEVARAJAN@NET.COM
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Mani,

>So my question is, does NSSA ABR(R4) must inject type7 default
>route in to AREA2 or we need manually configure default route
>on R4 for the RIP I destination network.

A default route is not necessary on R4 for it to reach the RIP-I
destinations since R4 can compute their next hops from their Type 5
LSAs. However if R4 originates a default Type 7 LSA into NSSA 2 that R5
prefers, then R5 could reach the RIP-I destinations through R4 via its
default..

By default, all of an NSSA ABRs, such as R4, are expected to originate a
type 7 LSA for default when none of the NSSA's internal routers, such as
R5, orignate a Type 7 LSA for default, even when they don't possess an
installed default path. I am not sure about RFC 1587, but this
requirement is explicitly described in the lastest NSSA draft.

Compliments of a suggestion of Alex Zinin's, I posted a draft titled

        Type 5 to Type 7 Translation

which is still available. It would allow the partial import of Type 5
LSAs, such as your RIP I routes, with aggregation. You can also find it
at

        ftp://noc.usgs.net/ietf/draft-ietf-ospf-5to7-01.txt

Quite frankly it seems logical that an NSSA should be able to import a
subset of an OSPF domain's Type 5 external LSAs complete with
aggregation, given that it can import external routes to networks
outside the AS via its external links. While I hope to repost this draft
soon, its current content is fairly clean.

Pat


From owner-ospf@DISCUSS.MICROSOFT.COM  Sun Sep 15 08:16:24 2002
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 IAA03334
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 15 Sep 2002 08:16:23 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0071E8FC@cherry.ease.lsoft.com>; 15 Sep 2002 8:18:01 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 195866 for OSPF@DISCUSS.MICROSOFT.COM;
          Sun, 15 Sep 2002 08:18:01 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Sun, 15 Sep 2002 08:18:00 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0BC2C>; Sun, 15 Sep 2002 08:17:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A32879160C@india_exch.hyderabad.mindspeed.com>
Date:         Sun, 15 Sep 2002 08:20:00 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: Multiple Interfaces to a Link
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Darshan,

As all the interfaces are advertized in LSA's all will be considered during
routing table calculations, so will play a role in other routers routing
table calculations.

As each interface has its own cost the interface with the lowest cost would
be preferred.  However if all three interfaces have the same cost I guess we
will have all three as next-hops in the routing table.

Thanks,
Vishwas

-----Original Message-----
From: Darshan Purohit [mailto:darshan.purohit@NOKIA.COM]
Sent: Thursday, September 05, 2002 11:57 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Multiple Interfaces to a Link


Hi All,
I had a question about multiple interfaces on the same link. The setup
is:

      __
     |  | --1--|
E1---|R1| --2--|
     |__| --3--|
               |   __
               |_1|  |
                  |R2|
                  |__|


As mentioned in 2740, section 3.9, R1 uses only interface 1 (say), for
control traffic and setting up adjacency with R2. However,
R1 originates a router LSA for each interface 1,2 and 3  ,
and it generates a separate Link LSA for each interface. Now, for a
route
through R1, how is R2 supposed to pick the nexthop link local address.
Will it be I1 - the interface which is being used for control traffic,
OR any one of the routers Link LSA , OR all three of them.

In the setup above, will the passive interfaces of R1 be used just as
backups in case the primary fails, or will they really play a role when
R2 (or any other Router in the area) does its routing table
calculation.

Thanks.
Darshan


From owner-ospf@DISCUSS.MICROSOFT.COM  Sun Sep 15 08:33:31 2002
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 IAA03516
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 15 Sep 2002 08:33:30 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0071E99D@cherry.ease.lsoft.com>; 15 Sep 2002 8:35:14 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 195895 for OSPF@DISCUSS.MICROSOFT.COM;
          Sun, 15 Sep 2002 08:35:14 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Sun, 15 Sep 2002 08:35:14 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0BC2P>; Sun, 15 Sep 2002 08:35:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A32879160D@india_exch.hyderabad.mindspeed.com>
Date:         Sun, 15 Sep 2002 08:37:35 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: about NEXT for OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Keqin Li,

I do not think any new version of the draft came out after the version-02 of
the draft which expired in September 2001.

I am not aware of any draft that talks about TE extensions for OSPFv3(which
is what I guess u r looking for). Is there interest for this in the working
group rite now?

Thanks,
Vishwas

-----Original Message-----
From: Li, Ke Qin (Peter) [mailto:keqinli@LUCENT.COM]
Sent: Tuesday, September 10, 2002 2:52 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: about NEXT for OSPFv3


Dear all,

I've read an Internet Draft "Network Engineering Extensions (NEXT) for
OSPFv3" authored by Spencer Giacalone. And I noticed that its expire date is
September 2001. I want to
know is there any new version of the draft? Is there any related draft about
this topic? Thank you very much!

I have tried to send email to the author, but my email to the address
provided in the Draft is rejected.

Keqin Li


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 16 04:15:48 2002
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 EAA28281
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 Sep 2002 04:15:47 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00720809@cherry.ease.lsoft.com>; Mon, 16 Sep 2002 4:17:31 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 198196 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 16 Sep 2002 04:17:31 -0400
Received: from 192.36.125.99 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 16 Sep 2002 04:07:31 -0400
Received: from zipf.pilsnet.sunet.se (zipf.pilsnet.sunet.se [192.36.125.132])
          by skybar.pilsnet.sunet.se (8.9.3/8.9.3) with ESMTP id KAA46040 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 16 Sep 2002 10:07:28 +0200 (CEST)
X-X-Sender: fimblo@zipf.pilsnet.sunet.se
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Message-ID:  <Pine.LNX.4.44.0209160942530.7060-100000@zipf.pilsnet.sunet.se>
Date:         Mon, 16 Sep 2002 10:06:46 +0200
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mattias Jansson <fimblo@SUNET.SE>
Subject: OSPF ISIS popularity
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id EAA28281

Hi, I've been following this work group for quite some time now, and I
read the ISIS/OSPF comparison thread with interest. It was a great read!

One thing I've been wondering for a while now is if one of the protocols
is more popular than the other. Im aware that the word "popular" is a
little vague, so I'll rephrase the question:

1) Is one of the protocols more usual in large ASs?
2) Does anyone know if one of the protocols is more popular in transit
   ASs?
3) Has anyone noticed a non-homogenous geographical popularity
   distribution? (eg ISIS more popular in Japan or in Northern Europe)


Regards,
Mattias Jansson


+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
| Mattias Jansson
|
| KTHNOC, NADA
| Drottning Kristinas väg 37b
| 100 44 STOCKHOLM
| S W E D E N
|
|
| http://www.sunet.se/~fimblo
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

What is the purpose of dreams...if they never become reality?


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 16 04:42:08 2002
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 EAA28542
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 Sep 2002 04:42:08 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0072093C@cherry.ease.lsoft.com>; Mon, 16 Sep 2002 4:43:52 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 198294 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 16 Sep 2002 04:43:52 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 16 Sep 2002 04:43:51 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0BC6Z>; Mon, 16 Sep 2002 04:43:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A32879161B@india_exch.hyderabad.mindspeed.com>
Date:         Mon, 16 Sep 2002 04:45:44 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: OSPF ISIS popularity
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA28542

Hi Mattias,

A discussion in this regard did take place in NANOG. Check the archives at
http://www.cctec.com/maillists/nanog/historical/9810/threads.html#00484

However it is preferable to keep these questions out of the working-group
list to prevent any misunderstanding. We have a group working on similar
issues, if you are interested you can mail me in private and join in there.

Thanks,
Vishwas

-----Original Message-----
From: Mattias Jansson [mailto:fimblo@SUNET.SE]
Sent: Monday, September 16, 2002 1:37 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF ISIS popularity


Hi, I've been following this work group for quite some time now, and I
read the ISIS/OSPF comparison thread with interest. It was a great read!

One thing I've been wondering for a while now is if one of the protocols
is more popular than the other. Im aware that the word "popular" is a
little vague, so I'll rephrase the question:

1) Is one of the protocols more usual in large ASs?
2) Does anyone know if one of the protocols is more popular in transit
   ASs?
3) Has anyone noticed a non-homogenous geographical popularity
   distribution? (eg ISIS more popular in Japan or in Northern Europe)


Regards,
Mattias Jansson


+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
| Mattias Jansson
|
| KTHNOC, NADA
| Drottning Kristinas väg 37b
| 100 44 STOCKHOLM
| S W E D E N
|
|
| http://www.sunet.se/~fimblo
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

What is the purpose of dreams...if they never become reality?


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 16 17:12:22 2002
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 RAA17548
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 Sep 2002 17:12:22 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00721956@cherry.ease.lsoft.com>; Mon, 16 Sep 2002 17:14:05 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 201589 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 16 Sep 2002 17:14:05 -0400
Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 16 Sep 2002 17:14:05 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <18.00721930@cherry.ease.lsoft.com>;
          Mon, 16 Sep 2002 17:14:04 -0400
Message-ID:  <OSPF%2002091617140529@DISCUSS.MICROSOFT.COM>
Date:         Mon, 16 Sep 2002 17:14:05 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Darshan Purohit <darshan.purohit@NOKIA.COM>
Subject: Re: Multiple Interfaces to a Link
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Thanks Vishwas, for the response.

When R2 has a route with nexthop R1, would the costs of interfaces
I1, I2, I3 matter for R2. It seems to me that R2 would do the same
thing no matter what the costs of I1, I2, I3 are.



           __       N
          |  | --I1-|
R3--///---|R1| --I2-|
          |__| --I3-|
                    |   __
                    |_1|  |
                       |R2|
                       |__|


Section 3.8.1.1 in 2740 ( Next hop calculation ) says
"Calculating router assigns the next hop IPv6 address to be the
link-local interface address contained in Router X's link-lsa for the
link"

--In this case R1 has three such link-LSAs. How should they be treated?

I see how each interface description in R1s router LSA will be
considered in the routing table calculation for the area.
When R3 calculates a path to N through R1, its cost to N will be based
on the least interface cost among interfaces I1,, I2, I3.

But i cant seem to figure out how each link lsa will be used.

Any help would be greatly appreciated.

Darshan








>
>        __       N
>       |  | --I1-|
>  R3---|R1| --I2-|
>       |__| --I3-|
>                 |   __
>                 |_1|  |
>                    |R2|
>                    |__|
>
>



On Sun, 15 Sep 2002 08:20:00 -0400, Manral, Vishwas
<VishwasM@NETPLANE.COM> wrote:

>Hi Darshan,
>
>As all the interfaces are advertized in LSA's all will be considered
during
>routing table calculations, so will play a role in other routers
routing
>table calculations.
>
>As each interface has its own cost the interface with the lowest cost
would
>be preferred.  However if all three interfaces have the same cost I
guess we
>will have all three as next-hops in the routing table.
>
>Thanks,
>Vishwas
>
>-----Original Message-----
>From: Darshan Purohit [mailto:darshan.purohit@NOKIA.COM]
>Sent: Thursday, September 05, 2002 11:57 PM
>To: OSPF@DISCUSS.MICROSOFT.COM
>Subject: Multiple Interfaces to a Link
>
>


>Hi All,
>I had a question about multiple interfaces on the same link. The setup
>is:
>
>      __
>     |  | --1--|
>E1---|R1| --2--|
>     |__| --3--|
>               |   __
>               |_1|  |
>                  |R2|
>                  |__|
>
>
>As mentioned in 2740, section 3.9, R1 uses only interface 1 (say), for
>control traffic and setting up adjacency with R2. However,
>R1 originates a router LSA for each interface 1,2 and 3  ,
>and it generates a separate Link LSA for each interface. Now, for a
>route
>through R1, how is R2 supposed to pick the nexthop link local address.
>Will it be I1 - the interface which is being used for control traffic,
>OR any one of the routers Link LSA , OR all three of them.
>
>In the setup above, will the passive interfaces of R1 be used just as
>backups in case the primary fails, or will they really play a role when
>R2 (or any other Router in the area) does its routing table
>calculation.
>
>Thanks.
>Darshan


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 16 20:44:51 2002
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 UAA21081
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 Sep 2002 20:44:51 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00721ECF@cherry.ease.lsoft.com>; Mon, 16 Sep 2002 20:46:34 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 202023 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 16 Sep 2002 20:46:34 -0400
Received: from 134.56.3.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 16 Sep 2002 20:36:34 -0400
Received: from isis.net.com (fremont-ns1.net.com [134.56.112.20]) by
          relay1.net.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12157 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 16 Sep 2002 17:32:28 -0700 (PDT)
Received: from west-mail.net.com by isis.net.com (8.9.3/SMI-SVR4) id RAA13434;
          Mon, 16 Sep 2002 17:37:22 -0700 (PDT)
Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging
          Server 3.6)  with ESMTP id AAA4EAF for <OSPF@DISCUSS.MICROSOFT.COM>;
          Mon, 16 Sep 2002 17:36:31 -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:  <3D86790E.95FE3DB@net.com>
Date:         Mon, 16 Sep 2002 17:36:30 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: NSSA Question
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi all,
 I have basic doubts in NSSA, which i guess  might
 have been discussed in this mailing list before. It would
 be great if someone could explain me or direct me to the
 previous discussion.

                                   ASBR
      -----     -----     -----    -----     -----
     |     |   |     |   |     |  |     |   |     |
     | R1  |   | R2  |   |  R3 |  |  R4 |   | R5  |
     |     |   |     |   |     |  |     |   |     |
      -----     -----     -----    -----     -----
          |     |   |      |  |     |  |     |
           -----     ------    -----    -----
           AREA1     AREA 0    AREA2    RIP Network
                                NSSA

    * In the above setup, Does R3(NSSA ABR) must be advertised
      as ASBR(type 4 LSA), as it is the orginator of type-5 LSA
      for the OSPF domain.
      Otherwise the routes for the RIP External network
      will not be configured on R1.

      In this case the type-4 LSA for the NSSA ASBR(R4) will
      not needed in R1 as it doesnt recieve the type-7 LSAs
      generated by R4.

Thanks in advance,
Mani


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 17 08:10:09 2002
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 IAA11660
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 Sep 2002 08:10:08 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00722EB1@cherry.ease.lsoft.com>; Tue, 17 Sep 2002 8:11:52 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 204132 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 17 Sep 2002 08:11:51 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 17 Sep 2002 08:01:51 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id IAA11234; Tue, 17 Sep 2002 08:00:05
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200209171200.IAA11234@ietf.org>
Date:         Tue, 17 Sep 2002 08:00:04 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-srisuresh-ospf-te-03.txt
Comments: cc: te-wg@ops.ietf.org, ccamp@ops.ietf.org
To: OSPF@DISCUSS.MICROSOFT.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 Internet Traffic Engineering Working Group of the IETF.

        Title           : TE LSAs to extend OSPF for Traffic Engineering
        Author(s)       : P. Srisuresh, P. Joseph
        Filename        : draft-srisuresh-ospf-te-03.txt
        Pages           : 42
        Date            : 2002-9-16

OSPF is a link state routing protocol used for IP-network
topology discovery and collection and dissemination of link
access metrics. The resulting Link State Database (LSDB) is
used to compute IP address forwarding table based on
shortest-path criteria. Traffic Engineering extensions(OSPF-TE)
outlined in this document are built on the native OSPF
foundation, utilizing new LSAs, designed specifically for TE.
OSPF-TE sets out to discover TE network topology and perform
collection and dissemination of TE metrics within the TE network.
This results in the generation of an independent TE-LSDB, that
would permit computation of TE circuit paths. Unlike the native
OSPF link metrics, TE metrics can be rapidly changing and
varied across different elements of the network. TE circuit
paths are computed using varied TE criteria, often different
from the shortest-path, to route traffic around congestion
paths. Principal motivations to designing the OSPF-TE over
[OPQLSA-TE] and transition path for vendors currently using
[OPQLSA-TE] to adapt the OSPF-TE are outlined in separate
sections within the document. OSPF-TE provides a single unified
mechanism for traffic engineering across packet and non-packet
networks, and may be adapted for a peer networking model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-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-srisuresh-ospf-te-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-srisuresh-ospf-te-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:     <2002-9-16151944.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-srisuresh-ospf-te-03.txt

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

Content-Type: text/plain
Content-ID:     <2002-9-16151944.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 17 08:16:06 2002
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 IAA11737
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 Sep 2002 08:16:05 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0072305E@cherry.ease.lsoft.com>; Tue, 17 Sep 2002 8:17:50 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 204209 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 17 Sep 2002 08:17:49 -0400
Received: from 216.136.173.133 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 17 Sep 2002 08:17:48 -0400
Received: from [203.200.20.226] by web12406.mail.yahoo.com via HTTP; Tue, 17
          Sep 2002 05:17:49 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020917121749.29579.qmail@web12406.mail.yahoo.com>
Date:         Tue, 17 Sep 2002 05:17:49 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Rohit Gupta <rohitgupta416@YAHOO.COM>
Subject: Re: I-D ACTION:draft-srisuresh-ospf-te-03.txt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <200209171200.IAA11234@ietf.org>
Precedence: list

Hi,
What exactly is the difference between this draft and
the one proposed by Yeoung and Katz on TE extensions
to OSPF?

Both appear to do the same.

-- Rohit
--- Internet-Drafts@IETF.ORG wrote:
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Internet Traffic
> Engineering Working Group of the IETF.
>
>         Title           : TE LSAs to extend OSPF for
> Traffic Engineering
>         Author(s)       : P. Srisuresh, P. Joseph
>         Filename        :
> draft-srisuresh-ospf-te-03.txt
>         Pages           : 42
>         Date            : 2002-9-16
>
> OSPF is a link state routing protocol used for
> IP-network
> topology discovery and collection and dissemination
> of link
> access metrics. The resulting Link State Database
> (LSDB) is
> used to compute IP address forwarding table based on
> shortest-path criteria. Traffic Engineering
> extensions(OSPF-TE)
> outlined in this document are built on the native
> OSPF
> foundation, utilizing new LSAs, designed
> specifically for TE.
> OSPF-TE sets out to discover TE network topology and
> perform
> collection and dissemination of TE metrics within
> the TE network.
> This results in the generation of an independent
> TE-LSDB, that
> would permit computation of TE circuit paths. Unlike
> the native
> OSPF link metrics, TE metrics can be rapidly
> changing and
> varied across different elements of the network. TE
> circuit
> paths are computed using varied TE criteria, often
> different
> from the shortest-path, to route traffic around
> congestion
> paths. Principal motivations to designing the
> OSPF-TE over
> [OPQLSA-TE] and transition path for vendors
> currently using
> [OPQLSA-TE] to adapt the OSPF-TE are outlined in
> separate
> sections within the document. OSPF-TE provides a
> single unified
> mechanism for traffic engineering across packet and
> non-packet
> networks, and may be adapted for a peer networking
> model.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-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-srisuresh-ospf-te-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-srisuresh-ospf-te-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.
>


__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 17 08:47:45 2002
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 IAA12713
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 Sep 2002 08:47:45 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00722F43@cherry.ease.lsoft.com>; Tue, 17 Sep 2002 8:49:29 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 204367 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 17 Sep 2002 08:49:27 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 17 Sep 2002 08:49:27 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id DFE571DCC61 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 17 Sep 2002 05:49:26 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D86790E.95FE3DB@net.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D872470.4040201@redback.com>
Date:         Tue, 17 Sep 2002 08:47:44 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: NSSA Question
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Mani Devarajan wrote:

> Hi all,
>  I have basic doubts in NSSA, which i guess  might
>  have been discussed in this mailing list before. It would
>  be great if someone could explain me or direct me to the
>  previous discussion.
>
>                                    ASBR
>       -----     -----     -----    -----     -----
>      |     |   |     |   |     |  |     |   |     |
>      | R1  |   | R2  |   |  R3 |  |  R4 |   | R5  |
>      |     |   |     |   |     |  |     |   |     |
>       -----     -----     -----    -----     -----
>           |     |   |      |  |     |  |     |
>            -----     ------    -----    -----
>            AREA1     AREA 0    AREA2    RIP Network
>                                 NSSA
>
>     * In the above setup, Does R3(NSSA ABR) must be advertised
>       as ASBR(type 4 LSA), as it is the orginator of type-5 LSA
>       for the OSPF domain.


Mani,

R3 will set it's E bit in it's area 0 router LSA and
R2 will advertise a type 4 summary LSA into area 1 for R3.

Thanks,
Acee


>       Otherwise the routes for the RIP External network
>       will not be configured on R1.
>
>       In this case the type-4 LSA for the NSSA ASBR(R4) will
>       not needed in R1 as it doesnt recieve the type-7 LSAs
>       generated by R4.
>
> Thanks in advance,
> Mani
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 17 13:12:44 2002
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 NAA22173
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 Sep 2002 13:12:44 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00723C0D@cherry.ease.lsoft.com>; Tue, 17 Sep 2002 13:14:26 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 205382 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 17 Sep 2002 13:14:26 -0400
Received: from 207.68.165.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 17 Sep 2002 13:14:26 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue,
          17 Sep 2002 10:14:21 -0700
Received: from 193.116.20.220 by sea2fd.sea2.hotmail.msn.com with HTTP; Tue, 17
          Sep 2002 17:14:21 GMT
X-Originating-IP: [193.116.20.220]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 17 Sep 2002 17:14:21.0538 (UTC)
                       FILETIME=[A9F0EC20:01C25E6D]
Message-ID:  <F244rhYQYx3G5aYY61L0001360b@hotmail.com>
Date:         Tue, 17 Sep 2002 18:14:21 +0100
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: gab jones <seun_ewulomi@HOTMAIL.COM>
Subject: serial link question
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Sorry if this sounsds stupid. But what would you categorize a link as in
duplex terms. Half or Full. be it T1, DS3 e.t.c. Any opinions appreciated.

regards


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 17 15:26:10 2002
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 PAA27248
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 Sep 2002 15:26:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00723ECF@cherry.ease.lsoft.com>; Tue, 17 Sep 2002 15:26:53 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 205887 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 17 Sep 2002 15:26:53 -0400
Received: from 134.56.3.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 17 Sep 2002 15:16:52 -0400
Received: from isis.net.com (fremont-ns1.net.com [134.56.112.20]) by
          relay1.net.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13015 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 17 Sep 2002 12:12:46 -0700 (PDT)
Received: from west-mail.net.com by isis.net.com (8.9.3/SMI-SVR4) id MAA21221;
          Tue, 17 Sep 2002 12:17:40 -0700 (PDT)
Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging
          Server 3.6)  with ESMTP id AAA1566 for <OSPF@DISCUSS.MICROSOFT.COM>;
          Tue, 17 Sep 2002 12:16:45 -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
References: <3D86790E.95FE3DB@net.com> <3D872470.4040201@redback.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D877F9C.77AAD941@net.com>
Date:         Tue, 17 Sep 2002 12:16:44 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: Re: NSSA Question
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Acee Lindem wrote:
>
> Mani Devarajan wrote:
>
> > Hi all,
> >  I have basic doubts in NSSA, which i guess  might
> >  have been discussed in this mailing list before. It would
> >  be great if someone could explain me or direct me to the
> >  previous discussion.
> >
> >                                    ASBR
> >       -----     -----     -----    -----     -----
> >      |     |   |     |   |     |  |     |   |     |
> >      | R1  |   | R2  |   |  R3 |  |  R4 |   | R5  |
> >      |     |   |     |   |     |  |     |   |     |
> >       -----     -----     -----    -----     -----
> >           |     |   |      |  |     |  |     |
> >            -----     ------    -----    -----
> >            AREA1     AREA 0    AREA2    RIP Network
> >                                 NSSA
> >
> >     * In the above setup, Does R3(NSSA ABR) must be advertised
> >       as ASBR(type 4 LSA), as it is the orginator of type-5 LSA
> >       for the OSPF domain.
>
> Mani,
>
> R3 will set it's E bit in it's area 0 router LSA and
> R2 will advertise a type 4 summary LSA into area 1 for R3.
>
> Thanks,
> Acee

Acee,
 Thanks for your information.

 I read one of the mails sent by Pat, saying that type-4 LSAs
 are not generated for NSSA ASBR. But in one of the implemenatation
 I am testing, I can see the type-4 Summary LSA for the NSSA ASBR
 in the Area1. But the routes for the external destination are not
 configured reporting that no route to Adv. router ASBR. But Actually
 I am able to reach ASBR from R1. Is this behaviour correct ?

 And if I configure R3 with some redistribution commands, type 4 LSA
 are generated for R3 and as you said, the summary LSA get relayed
 into Area1 by R2 and then routes are programmed for External
destination
 on R1.

 My question is, if R1 in Area1 recieves type-4 Summary LSA for
 NSSA ASBR and able to reach the ASBR through inter-area path,
 the external destination must be reachable without advertising
 type-4 LSA for R3 into area1. Is my understanding correct ....

Thanks in advance,
Mani



>
> >       Otherwise the routes for the RIP External network
> >       will not be configured on R1.
> >
> >       In this case the type-4 LSA for the NSSA ASBR(R4) will
> >       not needed in R1 as it doesnt recieve the type-7 LSAs
> >       generated by R4.
> >
> > Thanks in advance,
> > Mani
> >
> >
>
> --
> Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 17 15:38:14 2002
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 PAA27708
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 Sep 2002 15:38:14 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00723F9D@cherry.ease.lsoft.com>; Tue, 17 Sep 2002 15:39:58 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 205980 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 17 Sep 2002 15:39:58 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 17 Sep 2002 15:39:58 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id B200EF2C59 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 17 Sep 2002 12:39:56 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D86790E.95FE3DB@net.com> <3D872470.4040201@redback.com>
            <3D877F9C.77AAD941@net.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D8784A3.7030301@redback.com>
Date:         Tue, 17 Sep 2002 15:38:11 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: NSSA Question
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Mani,

See responses below.

Mani Devarajan wrote:

> Acee Lindem wrote:
>
>>Mani Devarajan wrote:
>>
>>
>>>Hi all,
>>> I have basic doubts in NSSA, which i guess  might
>>> have been discussed in this mailing list before. It would
>>> be great if someone could explain me or direct me to the
>>> previous discussion.
>>>
>>>                                   ASBR
>>>      -----     -----     -----    -----     -----
>>>     |     |   |     |   |     |  |     |   |     |
>>>     | R1  |   | R2  |   |  R3 |  |  R4 |   | R5  |
>>>     |     |   |     |   |     |  |     |   |     |
>>>      -----     -----     -----    -----     -----
>>>          |     |   |      |  |     |  |     |
>>>           -----     ------    -----    -----
>>>           AREA1     AREA 0    AREA2    RIP Network
>>>                                NSSA
>>>
>>>    * In the above setup, Does R3(NSSA ABR) must be advertised
>>>      as ASBR(type 4 LSA), as it is the orginator of type-5 LSA
>>>      for the OSPF domain.
>>>
>>Mani,
>>
>>R3 will set it's E bit in it's area 0 router LSA and
>>R2 will advertise a type 4 summary LSA into area 1 for R3.
>>
>>Thanks,
>>Acee
>>
>
> Acee,
>  Thanks for your information.
>
>  I read one of the mails sent by Pat, saying that type-4 LSAs
>  are not generated for NSSA ASBR.


This is true. But, an ABR translating for an NSSA is an ASBR in the
non-NSSA areas (since that is where the router is flooding type 5 LSAs).


> But in one of the implemenatation
>  I am testing, I can see the type-4 Summary LSA for the NSSA ASBR
>  in the Area1.


You should.

> But the routes for the external destination are not
>  configured reporting that no route to Adv. router ASBR.


I don't understand this statement.

> But Actually
>  I am able to reach ASBR from R1. Is this behaviour correct ?


Yes.


>
>  And if I configure R3 with some redistribution commands, type 4 LSA
>  are generated for R3 and as you said, the summary LSA get relayed
>  into Area1 by R2 and then routes are programmed for External
> destination
>  on R1.
>
>  My question is, if R1 in Area1 recieves type-4 Summary LSA for
>  NSSA ASBR and able to reach the ASBR through inter-area path,
>  the external destination must be reachable without advertising
>  type-4 LSA for R3 into area1. Is my understanding correct ....


No. The type 4 summary that is suppressed for NSSAs is the one for R4
that would be originated if area 2 were a regular area.


>
> Thanks in advance,
> Mani
>
>
>
>
>>>      Otherwise the routes for the RIP External network
>>>      will not be configured on R1.
>>>
>>>      In this case the type-4 LSA for the NSSA ASBR(R4) will
>>>      not needed in R1 as it doesnt recieve the type-7 LSAs
>>>      generated by R4.
>>>
>>>Thanks in advance,
>>>Mani
>>>
>>>
>>>
>>--
>>Acee
>>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 18 09:26:35 2002
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 JAA12058
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 18 Sep 2002 09:26:34 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00725F53@cherry.ease.lsoft.com>; Wed, 18 Sep 2002 9:28:19 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 209372 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 18 Sep 2002 09:28:19 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 18 Sep 2002 09:28:19 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id 487FA5E459 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 18 Sep 2002 06:28:17 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <F244rhYQYx3G5aYY61L0001360b@hotmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D887EFD.6080606@redback.com>
Date:         Wed, 18 Sep 2002 09:26:21 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: serial link question
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

gab jones wrote:

> Sorry if this sounsds stupid. But what would you categorize a link as in
> duplex terms. Half or Full. be it T1, DS3 e.t.c. Any opinions appreciated.


Conceivably, this could be considered when assigning interface costs.
However, I'm not aware of any vendors doing this in their automatic
cost commensurate with bandwidth computations.


>
> regards
>
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 18 11:53:48 2002
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 LAA18501
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 18 Sep 2002 11:53:48 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0072649C@cherry.ease.lsoft.com>; Wed, 18 Sep 2002 11:55:30 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 210443 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 18 Sep 2002 11:55:29 -0400
Received: from 66.218.78.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 18 Sep 2002 11:55:27 -0400
Received: from [12.36.127.12] by web40404.mail.yahoo.com via HTTP; Wed, 18 Sep
          2002 08:55:25 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020918155525.31406.qmail@web40404.mail.yahoo.com>
Date:         Wed, 18 Sep 2002 08:55:25 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Pyda Srisuresh <srisuresh@YAHOO.COM>
Subject: Re: I-D ACTION:draft-srisuresh-ospf-te-03.txt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <20020917121749.29579.qmail@web12406.mail.yahoo.com>
Precedence: list

Hi Rohit,

The draft-srisuresh-ospf-te-xx uses OSPF-TE LSAs, unlike the draft-katz-yeung
draft, which uses Opaque LSAs. As such the draft-srisuresh-ospf-te-xx
is scalable to networks with multiple areas, usable in TE/non-TE mixed networks
and extensable to packet/non-packet mixed networks. Section 4.0 in the draft
explains the motivations for designing the OSPF-TE LSAs as opposed to using
Opaque LSAs. Section 6 is devoted to describing a transition strategy for
implementations using Opaque LSAs.

The draft also complements the draft-katz-yeung draft in that it uses the
Link-TE TLAs used by the draft-katz-yeung draft.


The following TE-LSAs give a flavor of what to expect from the draft.

     - TE-Router LSA (0x81) describes TE capabilities of the Router and
       all its TE-links using router-TE TLVs and Link-TE TLVs.

       The LSDB built by draft-katz-yeung has no knowledge of the
       TE capabilities of the routers.

     - TE-incremental-link-Update LSA (0x8d) is used to disseminate
       incremental updates (i.e., Delta TLVs) for the TE-links.

       Opaque LSAs are not suited to advertising incremental TLV
       changes. A change in any TLV of a TE-link will mandate the
       entire Opaque-LSA (with all the TLVs included) to be transmitted.

     - TE-Circuit-paths LSA(0x8C) is used to announce availability of
       pre-established circuit paths in the network meetign a certain
       criteria. The LSA advertisement can include the duration of the
       static path, including the setup and teardown times.

       Opaque LSAs are not suited to advertising static circuit paths.

Hope this helps.

regards,
suresh

--- Rohit Gupta <rohitgupta416@YAHOO.COM> wrote:
> Hi,
> What exactly is the difference between this draft and
> the one proposed by Yeoung and Katz on TE extensions
> to OSPF?
>
> Both appear to do the same.
>
> -- Rohit
> --- Internet-Drafts@IETF.ORG wrote:
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> > This draft is a work item of the Internet Traffic
> > Engineering Working Group of the IETF.
> >
> >         Title           : TE LSAs to extend OSPF for
> > Traffic Engineering
> >         Author(s)       : P. Srisuresh, P. Joseph
> >         Filename        :
> > draft-srisuresh-ospf-te-03.txt
> >         Pages           : 42
> >         Date            : 2002-9-16
> >
> > OSPF is a link state routing protocol used for
> > IP-network
> > topology discovery and collection and dissemination
> > of link
> > access metrics. The resulting Link State Database
> > (LSDB) is
> > used to compute IP address forwarding table based on
> > shortest-path criteria. Traffic Engineering
> > extensions(OSPF-TE)
> > outlined in this document are built on the native
> > OSPF
> > foundation, utilizing new LSAs, designed
> > specifically for TE.
> > OSPF-TE sets out to discover TE network topology and
> > perform
> > collection and dissemination of TE metrics within
> > the TE network.
> > This results in the generation of an independent
> > TE-LSDB, that
> > would permit computation of TE circuit paths. Unlike
> > the native
> > OSPF link metrics, TE metrics can be rapidly
> > changing and
> > varied across different elements of the network. TE
> > circuit
> > paths are computed using varied TE criteria, often
> > different
> > from the shortest-path, to route traffic around
> > congestion
> > paths. Principal motivations to designing the
> > OSPF-TE over
> > [OPQLSA-TE] and transition path for vendors
> > currently using
> > [OPQLSA-TE] to adapt the OSPF-TE are outlined in
> > separate
> > sections within the document. OSPF-TE provides a
> > single unified
> > mechanism for traffic engineering across packet and
> > non-packet
> > networks, and may be adapted for a peer networking
> > model.
> >
> > A URL for this Internet-Draft is:
> >
> http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-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-srisuresh-ospf-te-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-srisuresh-ospf-te-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.
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! News - Today's headlines
> http://news.yahoo.com


=====


__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 18 15:44:28 2002
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 PAA27649
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 18 Sep 2002 15:44:28 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.007289EF@cherry.ease.lsoft.com>; Wed, 18 Sep 2002 15:46:13 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 211256 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 18 Sep 2002 15:46:13 -0400
Received: from 134.56.3.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 18 Sep 2002 15:36:12 -0400
Received: from unet.net.com (fremont-ns2.net.com [134.56.112.30]) by
          relay1.net.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09904 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 18 Sep 2002 12:32:05 -0700 (PDT)
Received: from west-mail.net.com by unet.net.com (8.9.3/SMI-SVR4) id MAA11115;
          Wed, 18 Sep 2002 12:37:02 -0700 (PDT)
Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging
          Server 3.6)  with ESMTP id AAA3FA1 for <OSPF@DISCUSS.MICROSOFT.COM>;
          Wed, 18 Sep 2002 12:36:11 -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:  <3D88D5A9.8C4F4268@net.com>
Date:         Wed, 18 Sep 2002 12:36:09 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: Question about choosing NSSA ABR
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi all,

RFC 1587:
 If this router has the highest router ID, it will be the
 one translating type-7 LSAs into type-5 LSAs for the NSSA, otherwise
 the translation algorithm should not be performed.


Why do we choose the NSSA ABR with the highest router ID to do
type-7 to type-5 LSA translation.

Why cant we choose a NSSA ABR which has the best cost path to
NSSA ASBR to do the type-7 to type-5 translation.

Thanks in advance,
Mani


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 18 16:52:33 2002
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 QAA29631
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 18 Sep 2002 16:52:32 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00728C02@cherry.ease.lsoft.com>; Wed, 18 Sep 2002 16:54:18 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 211535 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 18 Sep 2002 16:54:18 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 18 Sep 2002 16:54:18 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id A1C6B5E446 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 18 Sep 2002 13:54:16 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D88D5A9.8C4F4268@net.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D88E781.4020109@redback.com>
Date:         Wed, 18 Sep 2002 16:52:17 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Question about choosing NSSA ABR
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Mani Devarajan wrote:

> Hi all,
>
> RFC 1587:
>  If this router has the highest router ID, it will be the
>  one translating type-7 LSAs into type-5 LSAs for the NSSA, otherwise
>  the translation algorithm should not be performed.
>
>
> Why do we choose the NSSA ABR with the highest router ID to do
> type-7 to type-5 LSA translation.
>
> Why cant we choose a NSSA ABR which has the best cost path to
> NSSA ASBR to do the type-7 to type-5 translation.


Mani,

The translated type 5 advertisements alway contain a forwarding
addresses. Hence, the cost from the translating ABR to the NSSA
ASBR is not important.

Thanks,
---
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 18 17:22:45 2002
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 RAA00560
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 18 Sep 2002 17:22:45 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00728D69@cherry.ease.lsoft.com>; Wed, 18 Sep 2002 17:24:31 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 211563 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 18 Sep 2002 17:24:31 -0400
Received: from 134.56.3.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 18 Sep 2002 17:14:30 -0400
Received: from unet.net.com (fremont-ns2.net.com [134.56.112.30]) by
          relay1.net.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00098 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 18 Sep 2002 14:10:25 -0700 (PDT)
Received: from west-mail.net.com by unet.net.com (8.9.3/SMI-SVR4) id OAA02333;
          Wed, 18 Sep 2002 14:15:19 -0700 (PDT)
Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging
          Server 3.6)  with ESMTP id AAA5F44 for <OSPF@DISCUSS.MICROSOFT.COM>;
          Wed, 18 Sep 2002 14:14:25 -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
References: <3D88D5A9.8C4F4268@net.com> <3D88E781.4020109@redback.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D88ECAF.B2166154@net.com>
Date:         Wed, 18 Sep 2002 14:14:23 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: Re: Question about choosing NSSA ABR
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Acee Lindem wrote:
>
> Mani Devarajan wrote:
>
> > Hi all,
> >
> > RFC 1587:
> >  If this router has the highest router ID, it will be the
> >  one translating type-7 LSAs into type-5 LSAs for the NSSA, otherwise
> >  the translation algorithm should not be performed.
> >
> >
> > Why do we choose the NSSA ABR with the highest router ID to do
> > type-7 to type-5 LSA translation.
> >
> > Why cant we choose a NSSA ABR which has the best cost path to
> > NSSA ASBR to do the type-7 to type-5 translation.
>
> Mani,
>
> The translated type 5 advertisements alway contain a forwarding
> addresses. Hence, the cost from the translating ABR to the NSSA
> ASBR is not important.

 Acee,
  I understand that it makes no difference when the forwarding
  address is set in the type-5 LSA translated from type-7 LSA.

  If I assume that all NSSA ABRs have same address-range configuration,
  and the NSSA ABR with the highest routerid will do
  type7 to type5 translation and external network comes
  with in configured address range, it will set the forwarding
  address to 0.0.0.0 .  If the forwarding
  is 0.0.0.0, all the traffic for NSSA ASBR will be passing
  thorugh the NSSA ABR which did the type-7 to type-5 translation.
  In this case choosing the NSSA ABR with best cost path to the NSSA
ASBR
  will be a better option. Is my understanding correct?

Thanks,
Mani




>
> Thanks,
> ---
> Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 18 17:34:47 2002
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 RAA00961
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 18 Sep 2002 17:34:46 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00728C88@cherry.ease.lsoft.com>; Wed, 18 Sep 2002 17:36:32 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 211602 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 18 Sep 2002 17:36:33 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 18 Sep 2002 17:36:32 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id 104A21DCC60 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 18 Sep 2002 14:36:31 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D88D5A9.8C4F4268@net.com> <3D88E781.4020109@redback.com>
            <3D88ECAF.B2166154@net.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D88F167.80205@redback.com>
Date:         Wed, 18 Sep 2002 17:34:31 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Question about choosing NSSA ABR
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Mani Devarajan wrote:

> Acee Lindem wrote:
>
>>Mani Devarajan wrote:
>>
>>
>>>Hi all,
>>>
>>>RFC 1587:
>>> If this router has the highest router ID, it will be the
>>> one translating type-7 LSAs into type-5 LSAs for the NSSA, otherwise
>>> the translation algorithm should not be performed.
>>>
>>>
>>>Why do we choose the NSSA ABR with the highest router ID to do
>>>type-7 to type-5 LSA translation.
>>>
>>>Why cant we choose a NSSA ABR which has the best cost path to
>>>NSSA ASBR to do the type-7 to type-5 translation.
>>>
>>Mani,
>>
>>The translated type 5 advertisements alway contain a forwarding
>>addresses. Hence, the cost from the translating ABR to the NSSA
>>ASBR is not important.
>>
>
>  Acee,
>   I understand that it makes no difference when the forwarding
>   address is set in the type-5 LSA translated from type-7 LSA.
>
>   If I assume that all NSSA ABRs have same address-range configuration,
>   and the NSSA ABR with the highest routerid will do
>   type7 to type5 translation and external network comes
>   with in configured address range, it will set the forwarding
>   address to 0.0.0.0 .  If the forwarding
>   is 0.0.0.0, all the traffic for NSSA ASBR will be passing
>   thorugh the NSSA ABR which did the type-7 to type-5 translation.
>   In this case choosing the NSSA ABR with best cost path to the NSSA
> ASBR
>   will be a better option. Is my understanding correct?


In general, any time you aggregate routing information you have
the potential for a suboptimal routing. I don't necessarily view
introducing a corner case to handle this one as a better option.
You always have the choice of not configuring an NSSA address
range.


>
> Thanks,
> Mani
>
>
>
>
>
>>Thanks,
>>---
>>Acee
>>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 19 01:47:45 2002
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 BAA12146
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Sep 2002 01:47:45 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0072A2EE@cherry.ease.lsoft.com>; Thu, 19 Sep 2002 1:49:31 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 213456 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 19 Sep 2002 01:49:31 -0400
Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 19 Sep 2002 01:49:30 -0400
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <TA10CJH2>;
          Thu, 19 Sep 2002 11:23:03 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <55E277B99171E041ABF5F4B1C6DDCA068ABF14@HARITHA>
Date:         Thu, 19 Sep 2002 11:21:39 +0530
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Sudharsana V - CTD, Chennai." <vsudharsana@CTD.HCLTECH.COM>
Subject: On detecting change in TransitCapability of an area
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi,
When TransitCapability of an area (say a1) changes, the Backbone prefixes
need to be re-aggregated or de-aggregated in to it.
On doing so, should we flush the summary LSAs describing backbone prefixes
that were earlier(before change in TransitCapability) flooded in to a1?
(if we do not flush the old LSAs, they will be in a1's database for MaxAge).

In the case where a1 becomes transitCapable,
We will de-aggregate and the LSAs with more specific prefixes will be in use
in a1, despite the presence of old aggregated LSAs in a1's database for
MaxAge.

In the case where a1 loses transit capability,
We will re-aggregate - But the area a1 will not have the benefit of
aggregation for MaxAge because of the presence of old LSAs for specific
prefixes.

I do not see any other side effect. Are there any other implications that I
am missing?
Regards,
Sudharsana.V


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 19 02:25:11 2002
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 CAA21652
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Sep 2002 02:25:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0072A608@cherry.ease.lsoft.com>; Thu, 19 Sep 2002 2:26:57 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 213580 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 19 Sep 2002 02:26:58 -0400
Received: from 64.12.136.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 19 Sep 2002 02:26:57 -0400
Received: from Jjsyed@aol.com by imo-m08.mx.aol.com (mail_out_v34.10.) id
          c.102.1b20723a (16087); Thu, 19 Sep 2002 02:26:54 -0400 (EDT)
Received: from  aol.com (mow-m10.webmail.aol.com [64.12.184.138]) by
          air-id10.mx.aol.com (v88.21) with ESMTP id MAILINID104-0919022654;
          Thu, 19 Sep 2002 02:26:54 -0400
X-Mailer: Atlas Mailer 2.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <27525039.0272C82F.0004D071@aol.com>
Date:         Thu, 19 Sep 2002 02:26:54 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Javed Syed <Jjsyed@AOL.COM>
Subject: Re: serial link question
Comments: To: OSPF@DISCUSS.MICROSOFT.COM|Mailing
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit

Hi,

half and full duplex exists in the broadcast media. like ethernet technology. In full duplex csma does not exist because full duplex have two bidirectional pipe one for transmit and other one for recieve.

JS


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 19 18:29:06 2002
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 SAA25147
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Sep 2002 18:29:06 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0072C420@cherry.ease.lsoft.com>; Thu, 19 Sep 2002 18:30:43 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 217460 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 19 Sep 2002 18:30:43 -0400
Received: from 144.189.100.103 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 19 Sep 2002 18:20:42 -0400
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by
          motgate3.mot.com (motgate3 2.1) with ESMTP id PAA08043 for
          <ospf@discuss.microsoft.com>; Thu, 19 Sep 2002 15:18:37 -0700 (MST)]
Received: [from az33exm05.corp.mot.com (az33exm05.corp.mot.com [199.2.84.25])
          by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA19773 for
          <ospf@discuss.microsoft.com>; Thu, 19 Sep 2002 15:17:59 -0700 (MST)]
Received: by az33exm05.corp.mot.com with Internet Mail Service (5.5.2654.52) id
          <S79HCWPG>; Thu, 19 Sep 2002 15:19:55 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7FD24C15A06DD511BF9E00D0B73E99520336A721@az33exm05.corp.mot.com>
Date:         Thu, 19 Sep 2002 15:19:52 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Boffa Stephen-QA4741 <boffa@MOTOROLA.COM>
Subject: clarification of section 9.5.1 of RFC 2328
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

> We have two interpretations of section 9.5.1 (Sending Hello Packets on NBMA networks) of RFC 2328 from the perspective of being a non-eligible DR.  We are configured as a NBMA which we can not be eligible to be the DR.  Our issue involves the initiation of hello packets when we start-up.  The two interpretations are:
>
> 1) The non-eligible NBMA router (which is our environment), will initiate a hello packet to our direct neighbor on each interface.  After the initial exchange and adjacencies are established, hello packets are exchanged every hello-interval.
>
> 2)  Upon startup, no BDR or DR is elected so HELLOs are not sent to any router. The DR election is first triggered by *receipt* of HELLOs from the DR or BDR, which are sending HELLOs at PollInterval intervals because the NBMA router has reached the Down state.
>
> Any clarification on this case would help us in our implementation.
>
> Thanks for your assistance.
> Steve


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 19 18:45:56 2002
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 SAA25497
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Sep 2002 18:45:55 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0072C4C1@cherry.ease.lsoft.com>; Thu, 19 Sep 2002 18:47:41 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 217546 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 19 Sep 2002 18:47:41 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 19 Sep 2002 18:47:41 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id D191C26280D for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 19 Sep 2002 15:47:39 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <7FD24C15A06DD511BF9E00D0B73E99520336A721@az33exm05.corp.mot.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D8A5386.5050907@redback.com>
Date:         Thu, 19 Sep 2002 18:45:26 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: clarification of section 9.5.1 of RFC 2328
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Boffa Stephen-QA4741 wrote:

>>We have two interpretations of section 9.5.1 (Sending Hello Packets on NBMA networks) of RFC 2328 from the perspective of being a non-eligible DR.  We are configured as a NBMA which we can not be eligible to be the DR.  Our issue involves the initiation of hello packets when we start-up.  The two interpretations are:
>>
>>1) The non-eligible NBMA router (which is our environment), will initiate a hello packet to our direct neighbor on each interface.  After the initial exchange and adjacencies are established, hello packets are exchanged every hello-interval.
>>
>>2)  Upon startup, no BDR or DR is elected so HELLOs are not sent to any router. The DR election is first triggered by *receipt* of HELLOs from the DR or BDR, which are sending HELLOs at PollInterval intervals because the NBMA router has reached the Down state.
>>


#2 is the closest.

When non-eligible router starts up, it does not send hellos to anyone. Once a DR and BDR
are elected and poll the non-eligible router, it will send hellos to them.
It also replies to hellos as specified in section 9.5.1. If the DR or BDR neighbor
state goes to DOWN, the non-eligible router discontinues sending hellos to
that neighbor.

I suspect you will find a wide variance in what individual implementations
do with respect to non-eligible neighbors.


>>Any clarification on this case would help us in our implementation.
>>
>>Thanks for your assistance.
>>Steve
>>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 19 20:58:35 2002
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 UAA28217
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Sep 2002 20:58:35 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0072C852@cherry.ease.lsoft.com>; Thu, 19 Sep 2002 21:00:22 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 217875 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 19 Sep 2002 21:00:22 -0400
Received: from 144.189.100.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 19 Sep 2002 21:00:21 -0400
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by
          motgate4.mot.com (motgate4 2.1) with ESMTP id SAA18931 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 19 Sep 2002 18:00:20 -0700 (MST)]
Received: [from az33exm05.corp.mot.com (az33exm05.corp.mot.com [199.2.84.25])
          by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id RAA04261 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 19 Sep 2002 17:57:38 -0700 (MST)]
Received: by az33exm05.corp.mot.com with Internet Mail Service (5.5.2654.52) id
          <S79HCX00>; Thu, 19 Sep 2002 17:59:35 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain
Message-ID:  <7FD24C15A06DD511BF9E00D0B73E99520336A725@az33exm05.corp.mot.com>
Date:         Thu, 19 Sep 2002 17:59:34 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Boffa Stephen-QA4741 <boffa@MOTOROLA.COM>
Subject: Re: clarification of section 9.5.1 of RFC 2328
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Acee,

Thanks for your response.  A question which stems from your response of "If the DR or BDR neighbor state goes to DOWN, the non-eligible router discontinues sending hellos to
that neighbor.".  Does this statement implies that the poll-interval set on the non-eligible router is irrelevant on the non-eligible router?  In otherwords, the non-eligible router should not try to re-establish bi-directional communications with its DR or BDR (as defined in a poll-interval) if the DR or BDR is perceived as down (per the non-eligible router not receiving dead-interval worth of heartbeat responses).

Regards
Steve

-----Original Message-----
From: Acee Lindem [mailto:acee@REDBACK.COM]
Sent: Thursday, September 19, 2002 3:45 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: clarification of section 9.5.1 of RFC 2328


Boffa Stephen-QA4741 wrote:

>>We have two interpretations of section 9.5.1 (Sending Hello Packets on NBMA networks) of RFC 2328 from the perspective of being a non-eligible DR.  We are configured as a NBMA which we can not be eligible to be the DR.  Our issue involves the initiation of hello packets when we start-up.  The two interpretations are:
>>
>>1) The non-eligible NBMA router (which is our environment), will initiate a hello packet to our direct neighbor on each interface.  After the initial exchange and adjacencies are established, hello packets are exchanged every hello-interval.
>>
>>2)  Upon startup, no BDR or DR is elected so HELLOs are not sent to any router. The DR election is first triggered by *receipt* of HELLOs from the DR or BDR, which are sending HELLOs at PollInterval intervals because the NBMA router has reached the Down state.
>>


#2 is the closest.

When non-eligible router starts up, it does not send hellos to anyone. Once a DR and BDR
are elected and poll the non-eligible router, it will send hellos to them.
It also replies to hellos as specified in section 9.5.1. If the DR or BDR neighbor
state goes to DOWN, the non-eligible router discontinues sending hellos to
that neighbor.

I suspect you will find a wide variance in what individual implementations
do with respect to non-eligible neighbors.


>>Any clarification on this case would help us in our implementation.
>>
>>Thanks for your assistance.
>>Steve
>>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 19 21:29:03 2002
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 VAA28823
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Sep 2002 21:29:03 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0072C875@cherry.ease.lsoft.com>; Thu, 19 Sep 2002 21:30:48 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 217968 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 19 Sep 2002 21:30:48 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 19 Sep 2002 21:30:48 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id 00E3F262816 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 19 Sep 2002 18:30:47 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <7FD24C15A06DD511BF9E00D0B73E99520336A725@az33exm05.corp.mot.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D8A79BF.80205@redback.com>
Date:         Thu, 19 Sep 2002 21:28:31 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: clarification of section 9.5.1 of RFC 2328
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Boffa Stephen-QA4741 wrote:

> Acee,
>
> Thanks for your response.  A question which stems from your response of "If the DR or BDR neighbor state goes to DOWN, the non-eligible router discontinues sending hellos to
> that neighbor.".  Does this statement implies that the poll-interval set on the non-eligible router is irrelevant on the non-eligible router?  In otherwords, the non-eligible router should not try to re-establish bi-directional communications with its DR or BDR (as defined in a poll-interval) if the DR or BDR is perceived as down (per the non-eligible router not receiving dead-interval worth of heartbeat responses).
>


Yes - At least that is the way I interpreted and implemented it.


> Regards
> Steve
>
> -----Original Message-----
> From: Acee Lindem [mailto:acee@REDBACK.COM]
> Sent: Thursday, September 19, 2002 3:45 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: clarification of section 9.5.1 of RFC 2328
>
>
> Boffa Stephen-QA4741 wrote:
>
>
>>>We have two interpretations of section 9.5.1 (Sending Hello Packets on NBMA networks) of RFC 2328 from the perspective of being a non-eligible DR.  We are configured as a NBMA which we can not be eligible to be the DR.  Our issue involves the initiation of hello packets when we start-up.  The two interpretations are:
>>>
>>>1) The non-eligible NBMA router (which is our environment), will initiate a hello packet to our direct neighbor on each interface.  After the initial exchange and adjacencies are established, hello packets are exchanged every hello-interval.
>>>
>>>2)  Upon startup, no BDR or DR is elected so HELLOs are not sent to any router. The DR election is first triggered by *receipt* of HELLOs from the DR or BDR, which are sending HELLOs at PollInterval intervals because the NBMA router has reached the Down state.
>>>
>>>
>
>
> #2 is the closest.
>
> When non-eligible router starts up, it does not send hellos to anyone. Once a DR and BDR
> are elected and poll the non-eligible router, it will send hellos to them.
> It also replies to hellos as specified in section 9.5.1. If the DR or BDR neighbor
> state goes to DOWN, the non-eligible router discontinues sending hellos to
> that neighbor.
>
> I suspect you will find a wide variance in what individual implementations
> do with respect to non-eligible neighbors.
>
>
>
>>>Any clarification on this case would help us in our implementation.
>>>
>>>Thanks for your assistance.
>>>Steve
>>>
>>>
>
>
> --
> Acee
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep 20 01:18:02 2002
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 BAA03809
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 Sep 2002 01:18:02 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0072D0AB@cherry.ease.lsoft.com>; Fri, 20 Sep 2002 1:19:49 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 218645 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 20 Sep 2002 01:19:49 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 20 Sep 2002 01:19:49 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id 6B3991DCC7E for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 19 Sep 2002 22:19:46 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <55E277B99171E041ABF5F4B1C6DDCA068ABF14@HARITHA>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D8AAF69.5030707@redback.com>
Date:         Fri, 20 Sep 2002 01:17:29 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: On detecting change in TransitCapability of an area
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Sudharsana V - CTD, Chennai. wrote:

> Hi,
> When TransitCapability of an area (say a1) changes, the Backbone prefixes
> need to be re-aggregated or de-aggregated in to it.
> On doing so, should we flush the summary LSAs describing backbone prefixes
> that were earlier(before change in TransitCapability) flooded in to a1?
> (if we do not flush the old LSAs, they will be in a1's database for MaxAge).
>
> In the case where a1 becomes transitCapable,
> We will de-aggregate and the LSAs with more specific prefixes will be in use
> in a1, despite the presence of old aggregated LSAs in a1's database for
> MaxAge.
>
> In the case where a1 loses transit capability,
> We will re-aggregate - But the area a1 will not have the benefit of
> aggregation for MaxAge because of the presence of old LSAs for specific
> prefixes.
>
> I do not see any other side effect. Are there any other implications that I
> am missing?
> Regards,
> Sudharsana.V


Sudharsana,

In practice, you probabably won't run into many problems with this approach
since I'd guess the combination of virtual links and backbone summarization
is not all that common.

However, did you consider:

  1. If you implement the demand circuit DoNotAge capability, the residual LSAs
     could stay around indefinitely (or at least until a neighbor adjacency is
     lost and the LSA is flooded back to you).

  2. When there are other OSPF implementations acting as ABRs for the transit
     area, some will leave the residual LSAs and others will purge them.
     Potentially, this could cause a routing loop for destinations within the
     range which do not have a less specific de-aggregated route.

  3. You'll need to purge residual summary LSAs if your route
     goes away or changes anyway (since it is no longer correct). This
     complexity in itself seems to be motivation enough to do it correctly
     and purge the residual LSAs.

Thanks,
--
Acee


From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@DISCUSS.MICROSOFT.COM  Fri Sep 20 18:15:08 2002
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 SAA11480
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 Sep 2002 18:15:08 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0072E7AC@cherry.ease.lsoft.com>; Fri, 20 Sep 2002 18:16:51 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 221382 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 20 Sep 2002 18:16:50 -0400
Received: from 134.56.3.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 20 Sep 2002 18:06:48 -0400
Received: from isis.net.com (fremont-ns1.net.com [134.56.112.20]) by
          relay1.net.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22856 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 20 Sep 2002 15:02:41 -0700 (PDT)
Received: from west-mail.net.com by isis.net.com (8.9.3/SMI-SVR4) id PAA01139;
          Fri, 20 Sep 2002 15:07:38 -0700 (PDT)
Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging
          Server 3.6)  with ESMTP id AAA3B18 for <OSPF@DISCUSS.MICROSOFT.COM>;
          Fri, 20 Sep 2002 15:06:47 -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:  <3D8B9BF5.E59563BB@net.com>
Date:         Fri, 20 Sep 2002 15:06:45 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: Question on NSSA ABRs
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi all,

                                   ASBR
      -----     ------     -----    -------     -----
     |     |   |      |   |     |  |       |   |     |
     | R1  |   | R2   |   |  R3 |  |  R5   |   | R6  |
     |     |   |      |   |     |  |       |   |     |
      -----     ------     -----    -------     -----
          |I1 I2|  | |I4  I5|  |I6 I9| |  |I11  |
           -----   |  ------    -----  |   -----
           AREA1   |  AREA 0    AREA2  |    RIP Network
                   |I3                 |I10
                   |      -----        |
                   |   I7|     |I8     |
                    -----|  R4 |-------
                   AREA0 |     | AREA2
                          -----

     * R4 is configured with higher router id than R3.
     * AREA2 is NSSA.

  So on configuring the R5 for redistributing routes,R5 generates
  type7 LSAs for the external destination with I10 as forwarding
  address. R4 becomes a translator and injects the type-5 LSAs
  in to Area0. So now R2 reaches Rip network through R4.

  When I bring down the R4,R3 will become the translator, and
  translates the type-5 from type7 LSAs(with forwarind address I9)
  for the Rip network and so that R2 reaches R6 through R3.

  When I bring up R4 again, R3 does premature aging for the type5
  LSAs it generated and R4 translates the type7 in to type5 for the
  Rip network.  And now R2 reaches the R6 through R4.

  I can understand R3 becomes a translator, when R4 goes down. But
  I cant understand why R3 does premature aging when R4 comes up,
  in this case the forwarding interface I9 is still alive.

Thanks,
Mani


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep 20 18:27:58 2002
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 SAA12044
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 Sep 2002 18:27:58 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0072E693@cherry.ease.lsoft.com>; Fri, 20 Sep 2002 18:29:45 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 221404 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 20 Sep 2002 18:29:45 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 20 Sep 2002 18:29:44 -0400
Received: from redback.com (login002.redback.com [155.53.12.54]) by
          prattle.redback.com (Postfix) with ESMTP id 9AC022CDB4C for
          <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 20 Sep 2002 15:29:42 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D8B9BF5.E59563BB@net.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D8BA0C3.7000802@redback.com>
Date:         Fri, 20 Sep 2002 18:27:15 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Question on NSSA ABRs
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Mani Devarajan wrote:

> Hi all,
>
>                                    ASBR
>       -----     ------     -----    -------     -----
>      |     |   |      |   |     |  |       |   |     |
>      | R1  |   | R2   |   |  R3 |  |  R5   |   | R6  |
>      |     |   |      |   |     |  |       |   |     |
>       -----     ------     -----    -------     -----
>           |I1 I2|  | |I4  I5|  |I6 I9| |  |I11  |
>            -----   |  ------    -----  |   -----
>            AREA1   |  AREA 0    AREA2  |    RIP Network
>                    |I3                 |I10
>                    |      -----        |
>                    |   I7|     |I8     |
>                     -----|  R4 |-------
>                    AREA0 |     | AREA2
>                           -----
>
>      * R4 is configured with higher router id than R3.
>      * AREA2 is NSSA.
>
>   So on configuring the R5 for redistributing routes,R5 generates
>   type7 LSAs for the external destination with I10 as forwarding
>   address. R4 becomes a translator and injects the type-5 LSAs
>   in to Area0. So now R2 reaches Rip network through R4.
>
>   When I bring down the R4,R3 will become the translator, and
>   translates the type-5 from type7 LSAs(with forwarind address I9)
>   for the Rip network and so that R2 reaches R6 through R3.
>
>   When I bring up R4 again, R3 does premature aging for the type5
>   LSAs it generated and R4 translates the type7 in to type5 for the
>   Rip network.  And now R2 reaches the R6 through R4.
>
>   I can understand R3 becomes a translator, when R4 goes down. But
>   I cant understand why R3 does premature aging when R4 comes up,
>   in this case the forwarding interface I9 is still alive.
>
> Thanks,
> Mani
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep 20 18:30:08 2002
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 SAA12134
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 Sep 2002 18:30:08 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0072E684@cherry.ease.lsoft.com>; Fri, 20 Sep 2002 18:31:54 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 221418 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 20 Sep 2002 18:31:54 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 20 Sep 2002 18:31:54 -0400
Received: from redback.com (login002.redback.com [155.53.12.54]) by
          prattle.redback.com (Postfix) with ESMTP id DD9652CDB4D for
          <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 20 Sep 2002 15:31:52 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D8B9BF5.E59563BB@net.com> <3D8BA0C3.7000802@redback.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D8BA146.2040208@redback.com>
Date:         Fri, 20 Sep 2002 18:29:26 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Question on NSSA ABRs
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Sorry for the premature transmission - see answer below.

Acee Lindem wrote:

> Mani Devarajan wrote:
>
>> Hi all,
>>
>>                                    ASBR
>>       -----     ------     -----    -------     -----
>>      |     |   |      |   |     |  |       |   |     |
>>      | R1  |   | R2   |   |  R3 |  |  R5   |   | R6  |
>>      |     |   |      |   |     |  |       |   |     |
>>       -----     ------     -----    -------     -----
>>           |I1 I2|  | |I4  I5|  |I6 I9| |  |I11  |
>>            -----   |  ------    -----  |   -----
>>            AREA1   |  AREA 0    AREA2  |    RIP Network
>>                    |I3                 |I10
>>                    |      -----        |
>>                    |   I7|     |I8     |
>>                     -----|  R4 |-------
>>                    AREA0 |     | AREA2
>>                           -----
>>
>>      * R4 is configured with higher router id than R3.
>>      * AREA2 is NSSA.
>>
>>   So on configuring the R5 for redistributing routes,R5 generates
>>   type7 LSAs for the external destination with I10 as forwarding
>>   address. R4 becomes a translator and injects the type-5 LSAs
>>   in to Area0. So now R2 reaches Rip network through R4.
>>
>>   When I bring down the R4,R3 will become the translator, and
>>   translates the type-5 from type7 LSAs(with forwarind address I9)
>>   for the Rip network and so that R2 reaches R6 through R3.
>>
>>   When I bring up R4 again, R3 does premature aging for the type5
>>   LSAs it generated and R4 translates the type7 in to type5 for the
>>   Rip network.  And now R2 reaches the R6 through R4.
>>
>>   I can understand R3 becomes a translator, when R4 goes down. But
>>   I cant understand why R3 does premature aging when R4 comes up,
>>   in this case the forwarding interface I9 is still alive.


Because R3 loses the translator election to R4 and discontinues
translation.


>>
>> Thanks,
>> Mani
>>
>>
>
>
> --
> Acee
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep 20 19:14:51 2002
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 TAA13607
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 Sep 2002 19:14:51 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0072E724@cherry.ease.lsoft.com>; Fri, 20 Sep 2002 19:16:38 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 221472 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 20 Sep 2002 19:16:38 -0400
Received: from 134.56.3.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 20 Sep 2002 19:06:38 -0400
Received: from isis.net.com (fremont-ns1.net.com [134.56.112.20]) by
          relay1.net.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22554 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 20 Sep 2002 16:02:31 -0700 (PDT)
Received: from west-mail.net.com by isis.net.com (8.9.3/SMI-SVR4) id QAA14645;
          Fri, 20 Sep 2002 16:07:29 -0700 (PDT)
Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging
          Server 3.6)  with ESMTP id AAA4F20 for <OSPF@DISCUSS.MICROSOFT.COM>;
          Fri, 20 Sep 2002 16:06:38 -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
References: <3D8B9BF5.E59563BB@net.com> <3D8BA0C3.7000802@redback.com>
            <3D8BA146.2040208@redback.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D8BA9FC.11D94510@net.com>
Date:         Fri, 20 Sep 2002 16:06:36 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: Re: Question on NSSA ABRs
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Acee Lindem wrote:
>
> Sorry for the premature transmission - see answer below.
>
> Acee Lindem wrote:
>
> > Mani Devarajan wrote:
> >
> >> Hi all,
> >>
> >>                                    ASBR
> >>       -----     ------     -----    -------     -----
> >>      |     |   |      |   |     |  |       |   |     |
> >>      | R1  |   | R2   |   |  R3 |  |  R5   |   | R6  |
> >>      |     |   |      |   |     |  |       |   |     |
> >>       -----     ------     -----    -------     -----
> >>           |I1 I2|  | |I4  I5|  |I6 I9| |  |I11  |
> >>            -----   |  ------    -----  |   -----
> >>            AREA1   |  AREA 0    AREA2  |    RIP Network
> >>                    |I3                 |I10
> >>                    |      -----        |
> >>                    |   I7|     |I8     |
> >>                     -----|  R4 |-------
> >>                    AREA0 |     | AREA2
> >>                           -----
> >>
> >>      * R4 is configured with higher router id than R3.
> >>      * AREA2 is NSSA.
> >>
> >>   So on configuring the R5 for redistributing routes,R5 generates
> >>   type7 LSAs for the external destination with I10 as forwarding
> >>   address. R4 becomes a translator and injects the type-5 LSAs
> >>   in to Area0. So now R2 reaches Rip network through R4.
> >>
> >>   When I bring down the R4,R3 will become the translator, and
> >>   translates the type-5 from type7 LSAs(with forwarind address I9)
> >>   for the Rip network and so that R2 reaches R6 through R3.
> >>
> >>   When I bring up R4 again, R3 does premature aging for the type5
> >>   LSAs it generated and R4 translates the type7 in to type5 for the
> >>   Rip network.  And now R2 reaches the R6 through R4.
> >>
> >>   I can understand R3 becomes a translator, when R4 goes down. But
> >>   I cant understand why R3 does premature aging when R4 comes up,
> >>   in this case the forwarding interface I9 is still alive.
>
> Because R3 loses the translator election to R4 and discontinues
> translation.


Acee,
  Is translator election performed whenever a new ABR is configured
  in NSSA.

  And also If we had stayed with R3, we could have reduced
  the routing updates from R3 (premature aging for the LSAs
  it generated) and R4 translating the type-7 into type-5 LSA
  for the same external destination for which R3 has already
  done it. Is my understanding correct.

Thanks,
Mani

>
> >>
> >> Thanks,
> >> Mani
> >>
> >>
> >
> >
> > --
> > Acee
> >
>
> --
> Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep 20 21:41:54 2002
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 VAA15988
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 20 Sep 2002 21:41:54 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0072E89A@cherry.ease.lsoft.com>; Fri, 20 Sep 2002 21:43:41 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 221647 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 20 Sep 2002 21:43:41 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 20 Sep 2002 21:43:41 -0400
Received: from redback.com (login002.redback.com [155.53.12.54]) by
          prattle.redback.com (Postfix) with ESMTP id 787A91DCC6B for
          <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 20 Sep 2002 18:43:39 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D8B9BF5.E59563BB@net.com> <3D8BA0C3.7000802@redback.com>         
            <3D8BA146.2040208@redback.com> <3D8BA9FC.11D94510@net.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D8BCE37.6040402@redback.com>
Date:         Fri, 20 Sep 2002 21:41:11 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Question on NSSA ABRs
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Mani Devarajan wrote:

> Acee Lindem wrote:
>
>>Sorry for the premature transmission - see answer below.
>>
>>Acee Lindem wrote:
>>
>>
>>>Mani Devarajan wrote:
>>>
>>>
>>>>Hi all,
>>>>
>>>>                                   ASBR
>>>>      -----     ------     -----    -------     -----
>>>>     |     |   |      |   |     |  |       |   |     |
>>>>     | R1  |   | R2   |   |  R3 |  |  R5   |   | R6  |
>>>>     |     |   |      |   |     |  |       |   |     |
>>>>      -----     ------     -----    -------     -----
>>>>          |I1 I2|  | |I4  I5|  |I6 I9| |  |I11  |
>>>>           -----   |  ------    -----  |   -----
>>>>           AREA1   |  AREA 0    AREA2  |    RIP Network
>>>>                   |I3                 |I10
>>>>                   |      -----        |
>>>>                   |   I7|     |I8     |
>>>>                    -----|  R4 |-------
>>>>                   AREA0 |     | AREA2
>>>>                          -----
>>>>
>>>>     * R4 is configured with higher router id than R3.
>>>>     * AREA2 is NSSA.
>>>>
>>>>  So on configuring the R5 for redistributing routes,R5 generates
>>>>  type7 LSAs for the external destination with I10 as forwarding
>>>>  address. R4 becomes a translator and injects the type-5 LSAs
>>>>  in to Area0. So now R2 reaches Rip network through R4.
>>>>
>>>>  When I bring down the R4,R3 will become the translator, and
>>>>  translates the type-5 from type7 LSAs(with forwarind address I9)
>>>>  for the Rip network and so that R2 reaches R6 through R3.
>>>>
>>>>  When I bring up R4 again, R3 does premature aging for the type5
>>>>  LSAs it generated and R4 translates the type7 in to type5 for the
>>>>  Rip network.  And now R2 reaches the R6 through R4.
>>>>
>>>>  I can understand R3 becomes a translator, when R4 goes down. But
>>>>  I cant understand why R3 does premature aging when R4 comes up,
>>>>  in this case the forwarding interface I9 is still alive.
>>>>
>>Because R3 loses the translator election to R4 and discontinues
>>translation.
>>
>
>
> Acee,
>   Is translator election performed whenever a new ABR is configured
>   in NSSA.


Hi Mani,

I do it as part of NSSA area SPF calculation (so only consider reachable
ABRs are considered in the NSSA election process). I don't think the
RFC specifies exactly when the election is done.


>
>   And also If we had stayed with R3, we could have reduced
>   the routing updates from R3 (premature aging for the LSAs
>   it generated) and R4 translating the type-7 into type-5 LSA
>   for the same external destination for which R3 has already
>   done it. Is my understanding correct.


Yes. It might have been possible for the translator to
retain that role as long as it is connected to the NSSA. However,
it wasn't done this way.


>
> Thanks,
> Mani
>
>
>>>>Thanks,
>>>>Mani
>>>>
>>>>
>>>>
>>>
>>>--
>>>Acee
>>>
>>>
>>--
>>Acee
>>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Sat Sep 21 06:09:00 2002
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 GAA08333
	for <ospf-archive@LISTS.IETF.ORG>; Sat, 21 Sep 2002 06:09:00 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0072F350@cherry.ease.lsoft.com>; Sat, 21 Sep 2002 6:10:46 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 222497 for OSPF@DISCUSS.MICROSOFT.COM;
          Sat, 21 Sep 2002 06:10:46 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Sat, 21 Sep 2002 06:10:46 -0400
Received: from redback.com (login002.redback.com [155.53.12.54]) by
          prattle.redback.com (Postfix) with ESMTP id BDFC94BA216 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Sat, 21 Sep 2002 03:10:44 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D8B9BF5.E59563BB@net.com> <3D8BA0C3.7000802@redback.com>         
            <3D8BA146.2040208@redback.com> <3D8BA9FC.11D94510@net.com>
            <3D8BCE37.6040402@redback.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D8C450B.80107@redback.com>
Date:         Sat, 21 Sep 2002 06:08:11 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Question on NSSA ABRs
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Mani,

There is one detail that is neglected here. It is R5 that is
selecting the forwarding address - not the translator.
R5 probably changes the forwarding address due to I10 going
down when R4 is taken down (perhaps you are using
cross-connected fast ethernet).

Thanks,
Acee

Acee Lindem wrote:

>
>
> Mani Devarajan wrote:
>
>> Acee Lindem wrote:
>>
>>> Sorry for the premature transmission - see answer below.
>>>
>>> Acee Lindem wrote:
>>>
>>>
>>>> Mani Devarajan wrote:
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>>                                   ASBR
>>>>>      -----     ------     -----    -------     -----
>>>>>     |     |   |      |   |     |  |       |   |     |
>>>>>     | R1  |   | R2   |   |  R3 |  |  R5   |   | R6  |
>>>>>     |     |   |      |   |     |  |       |   |     |
>>>>>      -----     ------     -----    -------     -----
>>>>>          |I1 I2|  | |I4  I5|  |I6 I9| |  |I11  |
>>>>>           -----   |  ------    -----  |   -----
>>>>>           AREA1   |  AREA 0    AREA2  |    RIP Network
>>>>>                   |I3                 |I10
>>>>>                   |      -----        |
>>>>>                   |   I7|     |I8     |
>>>>>                    -----|  R4 |-------
>>>>>                   AREA0 |     | AREA2
>>>>>                          -----
>>>>>
>>>>>     * R4 is configured with higher router id than R3.
>>>>>     * AREA2 is NSSA.
>>>>>
>>>>>  So on configuring the R5 for redistributing routes,R5 generates
>>>>>  type7 LSAs for the external destination with I10 as forwarding
>>>>>  address. R4 becomes a translator and injects the type-5 LSAs
>>>>>  in to Area0. So now R2 reaches Rip network through R4.
>>>>>
>>>>>  When I bring down the R4,R3 will become the translator, and
>>>>>  translates the type-5 from type7 LSAs(with forwarind address I9)
>>>>>  for the Rip network and so that R2 reaches R6 through R3.
>>>>>
>>>>>  When I bring up R4 again, R3 does premature aging for the type5
>>>>>  LSAs it generated and R4 translates the type7 in to type5 for the
>>>>>  Rip network.  And now R2 reaches the R6 through R4.
>>>>>
>>>>>  I can understand R3 becomes a translator, when R4 goes down. But
>>>>>  I cant understand why R3 does premature aging when R4 comes up,
>>>>>  in this case the forwarding interface I9 is still alive.
>>>>>
>>> Because R3 loses the translator election to R4 and discontinues
>>> translation.
>>>
>>
>>
>> Acee,
>>   Is translator election performed whenever a new ABR is configured
>>   in NSSA.
>
>
>
> Hi Mani,
>
> I do it as part of NSSA area SPF calculation (so only consider reachable
> ABRs are considered in the NSSA election process). I don't think the
> RFC specifies exactly when the election is done.
>
>
>>
>>   And also If we had stayed with R3, we could have reduced
>>   the routing updates from R3 (premature aging for the LSAs
>>   it generated) and R4 translating the type-7 into type-5 LSA
>>   for the same external destination for which R3 has already
>>   done it. Is my understanding correct.
>
>
>
> Yes. It might have been possible for the translator to
> retain that role as long as it is connected to the NSSA. However,
> it wasn't done this way.
>
>
>>
>> Thanks,
>> Mani
>>
>>
>>>>> Thanks,
>>>>> Mani
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Acee
>>>>
>>>>
>>> --
>>> Acee
>>>
>>
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Sun Sep 22 04:27:26 2002
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 EAA04163
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 22 Sep 2002 04:27:25 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00731424@cherry.ease.lsoft.com>; 22 Sep 2002 4:29:07 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 224674 for OSPF@DISCUSS.MICROSOFT.COM;
          Sun, 22 Sep 2002 04:29:07 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Sun, 22 Sep 2002 04:29:07 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0BLQC>; Sun, 22 Sep 2002 04:29:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328791680@india_exch.hyderabad.mindspeed.com>
Date:         Sun, 22 Sep 2002 04:31:12 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: Multiple Interfaces to a Link
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Darshan,

I think the sentence should not be

"Calculating router assigns the next hop IPv6 address to be the
link-local interface address contained in Router X's link-lsa for the
link"

should instead be

"Calculating router assigns the next hop IPv6 address to be the
link-local interface address contained in Router X's link-lsa for the
interface"

In the case we have multiple interfaces on a link the two would refer to
different sets of link LSA's. Will that solve the doubt you have? Though
Yasu or someone else would confirm this.

Thanks,
Vishwas

-----Original Message-----
From: Darshan Purohit [mailto:darshan.purohit@NOKIA.COM]
Sent: Tuesday, September 17, 2002 2:44 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: Multiple Interfaces to a Link


Thanks Vishwas, for the response.

When R2 has a route with nexthop R1, would the costs of interfaces
I1, I2, I3 matter for R2. It seems to me that R2 would do the same
thing no matter what the costs of I1, I2, I3 are.



           __       N
          |  | --I1-|
R3--///---|R1| --I2-|
          |__| --I3-|
                    |   __
                    |_1|  |
                       |R2|
                       |__|


Section 3.8.1.1 in 2740 ( Next hop calculation ) says
"Calculating router assigns the next hop IPv6 address to be the
link-local interface address contained in Router X's link-lsa for the
link"

--In this case R1 has three such link-LSAs. How should they be treated?

I see how each interface description in R1s router LSA will be
considered in the routing table calculation for the area.
When R3 calculates a path to N through R1, its cost to N will be based
on the least interface cost among interfaces I1,, I2, I3.

But i cant seem to figure out how each link lsa will be used.

Any help would be greatly appreciated.

Darshan








>
>        __       N
>       |  | --I1-|
>  R3---|R1| --I2-|
>       |__| --I3-|
>                 |   __
>                 |_1|  |
>                    |R2|
>                    |__|
>
>



On Sun, 15 Sep 2002 08:20:00 -0400, Manral, Vishwas
<VishwasM@NETPLANE.COM> wrote:

>Hi Darshan,
>
>As all the interfaces are advertized in LSA's all will be considered
during
>routing table calculations, so will play a role in other routers
routing
>table calculations.
>
>As each interface has its own cost the interface with the lowest cost
would
>be preferred.  However if all three interfaces have the same cost I
guess we
>will have all three as next-hops in the routing table.
>
>Thanks,
>Vishwas
>
>-----Original Message-----
>From: Darshan Purohit [mailto:darshan.purohit@NOKIA.COM]
>Sent: Thursday, September 05, 2002 11:57 PM
>To: OSPF@DISCUSS.MICROSOFT.COM
>Subject: Multiple Interfaces to a Link
>
>


>Hi All,
>I had a question about multiple interfaces on the same link. The setup
>is:
>
>      __
>     |  | --1--|
>E1---|R1| --2--|
>     |__| --3--|
>               |   __
>               |_1|  |
>                  |R2|
>                  |__|
>
>
>As mentioned in 2740, section 3.9, R1 uses only interface 1 (say), for
>control traffic and setting up adjacency with R2. However,
>R1 originates a router LSA for each interface 1,2 and 3  ,
>and it generates a separate Link LSA for each interface. Now, for a
>route
>through R1, how is R2 supposed to pick the nexthop link local address.
>Will it be I1 - the interface which is being used for control traffic,
>OR any one of the routers Link LSA , OR all three of them.
>
>In the setup above, will the passive interfaces of R1 be used just as
>backups in case the primary fails, or will they really play a role when
>R2 (or any other Router in the area) does its routing table
>calculation.
>
>Thanks.
>Darshan


From owner-ospf@DISCUSS.MICROSOFT.COM  Sun Sep 22 04:33:49 2002
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 EAA04214
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 22 Sep 2002 04:33:49 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0073125B@cherry.ease.lsoft.com>; 22 Sep 2002 4:35:38 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 224688 for OSPF@DISCUSS.MICROSOFT.COM;
          Sun, 22 Sep 2002 04:35:38 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Sun, 22 Sep 2002 04:35:38 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0BLQ2>; Sun, 22 Sep 2002 04:35:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328791681@india_exch.hyderabad.mindspeed.com>
Date:         Sun, 22 Sep 2002 04:37:42 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: serial link question
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

hi,

I am not sure if I got the question right however

Full duplex links - are links that allow two-way communication over seperate
links
Half Duplex - when the two way communication uses a shared channel so
symultaneous transmission is not possible in both directions and
Simplex - when the channel is only one-way.

HTH and Thanks,
Vishwas

-----Original Message-----
From: gab jones [mailto:seun_ewulomi@HOTMAIL.COM]
Sent: Tuesday, September 17, 2002 10:44 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: serial link question


Sorry if this sounsds stupid. But what would you categorize a link as in
duplex terms. Half or Full. be it T1, DS3 e.t.c. Any opinions appreciated.

regards


From owner-ospf@DISCUSS.MICROSOFT.COM  Sun Sep 22 05:00:34 2002
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 FAA04617
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 22 Sep 2002 05:00:33 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00731309@cherry.ease.lsoft.com>; 22 Sep 2002 5:02:23 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 224737 for OSPF@DISCUSS.MICROSOFT.COM;
          Sun, 22 Sep 2002 05:02:23 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Sun, 22 Sep 2002 05:02:22 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0BLRH>; Sun, 22 Sep 2002 05:02:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328791682@india_exch.hyderabad.mindspeed.com>
Date:         Sun, 22 Sep 2002 05:04:29 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: Question about choosing NSSA ABR
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Mani,

Besides what Acee said, you may want to check the section F.4 in the new
NSSA draft. I think sub-optimal routing is a smaller issue in this case, I
think making the translator deterministic is a bigger issue.

The new draft does close a bug in the translator election, which may result
by choosing just a router with the largest Router-id(it may happen for the
shortest route too though, we still use the highest router-id). The problem
is if one or more areas looses connectivity to the Area-0, we will still
have just one router translating. Besides translators are now configureable,
so as to make translators more deterministic.

Thanks,
Vishwas

-----Original Message-----
From: Acee Lindem [mailto:acee@REDBACK.COM]
Sent: Thursday, September 19, 2002 3:05 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: Question about choosing NSSA ABR


Mani Devarajan wrote:

> Acee Lindem wrote:
>
>>Mani Devarajan wrote:
>>
>>
>>>Hi all,
>>>
>>>RFC 1587:
>>> If this router has the highest router ID, it will be the
>>> one translating type-7 LSAs into type-5 LSAs for the NSSA, otherwise
>>> the translation algorithm should not be performed.
>>>
>>>
>>>Why do we choose the NSSA ABR with the highest router ID to do
>>>type-7 to type-5 LSA translation.
>>>
>>>Why cant we choose a NSSA ABR which has the best cost path to
>>>NSSA ASBR to do the type-7 to type-5 translation.
>>>
>>Mani,
>>
>>The translated type 5 advertisements alway contain a forwarding
>>addresses. Hence, the cost from the translating ABR to the NSSA
>>ASBR is not important.
>>
>
>  Acee,
>   I understand that it makes no difference when the forwarding
>   address is set in the type-5 LSA translated from type-7 LSA.
>
>   If I assume that all NSSA ABRs have same address-range configuration,
>   and the NSSA ABR with the highest routerid will do
>   type7 to type5 translation and external network comes
>   with in configured address range, it will set the forwarding
>   address to 0.0.0.0 .  If the forwarding
>   is 0.0.0.0, all the traffic for NSSA ASBR will be passing
>   thorugh the NSSA ABR which did the type-7 to type-5 translation.
>   In this case choosing the NSSA ABR with best cost path to the NSSA
> ASBR
>   will be a better option. Is my understanding correct?


In general, any time you aggregate routing information you have
the potential for a suboptimal routing. I don't necessarily view
introducing a corner case to handle this one as a better option.
You always have the choice of not configuring an NSSA address
range.


>
> Thanks,
> Mani
>
>>Thanks,
>>---
>>Acee

--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Sun Sep 22 05:19:42 2002
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 FAA04799
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 22 Sep 2002 05:19:41 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00731236@cherry.ease.lsoft.com>; 22 Sep 2002 5:21:31 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 224774 for OSPF@DISCUSS.MICROSOFT.COM;
          Sun, 22 Sep 2002 05:21:31 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Sun, 22 Sep 2002 05:21:31 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0BLRN>; Sun, 22 Sep 2002 05:21:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328791683@india_exch.hyderabad.mindspeed.com>
Date:         Sun, 22 Sep 2002 05:23:35 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Regarding draft-ietf-ospf-5to7-01.txt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Pat,

Two small comments: -

a) Shouldn't the translator now set the E-bit in its router LSA into the
NSSA area because according to step 3 Section 3.5 of the NSSA draft none of
the translated NSSA LSA's would be considered for the routing table
calculation and the entire purpose of 5to7 would be defeated.

I couldn't find the fact stated in the draft. Or did I miss it?

b)  Regarding the translator election for the elected translator, we could
as well just have the guy with the lowest router-id become translator this
can be done without actually adding any change to packets and can be done as
part of the 7to5 translator election.

Thanks,
Vishwas


From owner-ospf@DISCUSS.MICROSOFT.COM  Sun Sep 22 06:46:07 2002
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 GAA05673
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 22 Sep 2002 06:46:05 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00731559@cherry.ease.lsoft.com>; 22 Sep 2002 6:47:51 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 225109 for OSPF@DISCUSS.MICROSOFT.COM;
          Sun, 22 Sep 2002 06:47:51 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Sun, 22 Sep 2002 06:47:50 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0BLTX>; Sun, 22 Sep 2002 06:47:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328791684@india_exch.hyderabad.mindspeed.com>
Date:         Sun, 22 Sep 2002 06:49:57 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: Regarding draft-ietf-ospf-5to7-01.txt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Regarding a) I guess we already do it for NSSA anyway setting the E-bit, so
it would already be done for the type5to7 already, so the issue would not
hold.

Thanks,
Vishwas

-----Original Message-----
From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM]
Sent: Sunday, September 22, 2002 2:54 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Regarding draft-ietf-ospf-5to7-01.txt


Hi Pat,

Two small comments: -

a) Shouldn't the translator now set the E-bit in its router LSA into the
NSSA area because according to step 3 Section 3.5 of the NSSA draft none of
the translated NSSA LSA's would be considered for the routing table
calculation and the entire purpose of 5to7 would be defeated.

I couldn't find the fact stated in the draft. Or did I miss it?

b)  Regarding the translator election for the elected translator, we could
as well just have the guy with the lowest router-id become translator this
can be done without actually adding any change to packets and can be done as
part of the 7to5 translator election.

Thanks,
Vishwas


From owner-ospf@DISCUSS.MICROSOFT.COM  Sun Sep 22 10:51:19 2002
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 KAA08776
	for <ospf-archive@LISTS.IETF.ORG>; Sun, 22 Sep 2002 10:51:19 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00731731@cherry.ease.lsoft.com>; 22 Sep 2002 10:53:07 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 225411 for OSPF@DISCUSS.MICROSOFT.COM;
          Sun, 22 Sep 2002 10:53:07 -0400
Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Sun, 22 Sep 2002 10:53:07 -0400
Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by
          shonan.sfc.wide.ad.jp (Postfix) with ESMTP id F28775D012; Sun, 22 Sep
          2002 23:53:05 +0900 (JST)
References: <E7E13AAF2F3ED41197C100508BD6A328791680@india_exch.hyderabad.mindspeed.com>
X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <20020922.234349.125324390.yasu@sfc.wide.ad.jp>
Date:         Sun, 22 Sep 2002 23:43:49 +0900
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Yasuhiro Ohara <yasu@SFC.WIDE.AD.JP>
Subject: Re: Multiple Interfaces to a Link
Comments: To: VishwasM@NETPLANE.COM
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <E7E13AAF2F3ED41197C100508BD6A328791680@india_exch.hyderabad.mindspeed.com>
              <OSPF%2002091617140529@DISCUSS.MICROSOFT.COM>
Precedence: list
Content-Transfer-Encoding: 7bit

VishwasM> I think the sentence should not be
VishwasM>
VishwasM> "Calculating router assigns the next hop IPv6 address to be the
VishwasM> link-local interface address contained in Router X's link-lsa for the
VishwasM> link"
VishwasM>
VishwasM> should instead be
VishwasM>
VishwasM> "Calculating router assigns the next hop IPv6 address to be the
VishwasM> link-local interface address contained in Router X's link-lsa for the
VishwasM> interface"

Agree, but below seems better to me (not sure about my English and
it's acutually bad, as you see ;p):

"Calculating router assigns the next hop IPv6 addresses to be the
collection of the link-local interface address contained in Router X's
Link-LSAs advertised from each of Router X's interface"


Below is my experience, or just mumbling ...

The reason why the control traffic exchange should be disabled on all
but one interface for the same link, is related to the way the OSPF
router identifies his neighbor. Since OSPF router identifies his
neighbor by router-id (RFC2740 2.11) and in practice possibly by on
which interface the neighbor is, the packet sent from the different
interface of the neighbor cannot be distinguished by the receiving
router.

In the example in this thread, the DbDesc packet sent from I2 of R1 can
break the adjacency between R1 and R2 through (say) I1, by letting R2
executes "SeqNum Mismatch" or something.

The only exception to this is Hello packet, it can be distinguished by
receiver by looking into the Interface-ID field in Hello. The receiver
should simply discard the Hello packet which has the different
Interface-ID from the Interface-ID the neighbor have announced, rather
than executing unnecessary "One-Way Received" (because the router may
not be listed as "Seen Router").

If we identify the neighbor not only by router-id but also by *the
neighbor's interface-id* or *link-local address*, even multiple
adjacency between R1 and R2 can be established, I guess. It's demerit
is obviously that there will be some redundant usage of resources to
hold and exchange the link-local scoped LSAs. It's merit is that the
convergence may get faster, in practice (by eliminating some small
fixed timer to keep watching other interfaces at the local router, and
by eliminating the building of adjacency from scratch when primary
interface fails).

# Zebra ospf6d does not support multiple interfaces per link yet,
# sorry.

regards,
yasu

darshan.purohit>            __       N
darshan.purohit>           |  | --I1-|
darshan.purohit> R3--///---|R1| --I2-|
darshan.purohit>           |__| --I3-|
darshan.purohit>                     |   __
darshan.purohit>                     |_1|  |
darshan.purohit>                        |R2|
darshan.purohit>                        |__|


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 23 01:18:33 2002
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 BAA20095
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Sep 2002 01:18:33 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00732B65@cherry.ease.lsoft.com>; Mon, 23 Sep 2002 1:20:21 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 226758 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 23 Sep 2002 01:20:19 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 23 Sep 2002 01:20:19 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <S1D0BM10>; Mon, 23 Sep 2002 01:20:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A328791687@india_exch.hyderabad.mindspeed.com>
Date:         Mon, 23 Sep 2002 01:22:40 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: Multiple Interfaces to a Link
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Darshan/Yasu,

> When R2 has a route with nexthop R1, would the costs of interfaces
> I1, I2, I3 matter for R2. It seems to me that R2 would do the same
> thing no matter what the costs of I1, I2, I3 are.
Yes the costs would not matter.

>            __       N
>           |  | --I1-|
> R3--///---|R1| --I2-|
>           |__| --I3-|
>                     |   __
>                     |_1|  |
>                        |R2|
>                        |__|


> Section 3.8.1.1 in 2740 ( Next hop calculation ) says
> "Calculating router assigns the next hop IPv6 address to be the
> link-local interface address contained in Router X's link-lsa for the
> link"

>--In this case R1 has three such link-LSAs. How should they be treated?
As Yasu put it, it would be nice to state the below instead for section
3.8.1.1 with minor corrections to Yasu's text

"Calculating router assigns the next hop IPv6 addresses to be the
collection of the link-local interface address contained in Router X's
Link-LSAs advertised from each of Router X's interface on the link"

Would this help?

Thanks,
Vishwas

>
>        __       N
>       |  | --I1-|
>  R3---|R1| --I2-|
>       |__| --I3-|
>                 |   __
>                 |_1|  |
>                    |R2|
>                    |__|
>
>



On Sun, 15 Sep 2002 08:20:00 -0400, Manral, Vishwas
<VishwasM@NETPLANE.COM> wrote:

>Hi Darshan,
>
>As all the interfaces are advertized in LSA's all will be considered
during
>routing table calculations, so will play a role in other routers
routing
>table calculations.
>
>As each interface has its own cost the interface with the lowest cost
would
>be preferred.  However if all three interfaces have the same cost I
guess we
>will have all three as next-hops in the routing table.
>
>Thanks,
>Vishwas
>
>-----Original Message-----
>From: Darshan Purohit [mailto:darshan.purohit@NOKIA.COM]
>Sent: Thursday, September 05, 2002 11:57 PM
>To: OSPF@DISCUSS.MICROSOFT.COM
>Subject: Multiple Interfaces to a Link
>
>


>Hi All,
>I had a question about multiple interfaces on the same link. The setup
>is:
>
>      __
>     |  | --1--|
>E1---|R1| --2--|
>     |__| --3--|
>               |   __
>               |_1|  |
>                  |R2|
>                  |__|
>
>
>As mentioned in 2740, section 3.9, R1 uses only interface 1 (say), for
>control traffic and setting up adjacency with R2. However,
>R1 originates a router LSA for each interface 1,2 and 3  ,
>and it generates a separate Link LSA for each interface. Now, for a
>route
>through R1, how is R2 supposed to pick the nexthop link local address.
>Will it be I1 - the interface which is being used for control traffic,
>OR any one of the routers Link LSA , OR all three of them.
>
>In the setup above, will the passive interfaces of R1 be used just as
>backups in case the primary fails, or will they really play a role when
>R2 (or any other Router in the area) does its routing table
>calculation.
>
>Thanks.
>Darshan


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 23 02:34:24 2002
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 CAA00411
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Sep 2002 02:34:23 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00732D29@cherry.ease.lsoft.com>; Mon, 23 Sep 2002 2:36:10 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 226904 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 23 Sep 2002 02:36:08 -0400
Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 23 Sep 2002 02:36:08 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <9.00732CF9@cherry.ease.lsoft.com>;
          Mon, 23 Sep 2002 2:36:09 -0400
Message-ID:  <OSPF%2002092302360832@DISCUSS.MICROSOFT.COM>
Date:         Mon, 23 Sep 2002 02:36:06 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Darshan Purohit <darshan.purohit@NOKIA.COM>
Subject: Re: Multiple Interfaces to a Link
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Vishwas / Yasu,
Thanks a lot for the valuable feedback. It looks clear now how the LSAs
will be treated when a router has more than one interfaces on the link.
Thanks.
Darshan

>Hi Darshan/Yasu,
>
>> When R2 has a route with nexthop R1, would the costs of interfaces
>> I1, I2, I3 matter for R2. It seems to me that R2 would do the same
>> thing no matter what the costs of I1, I2, I3 are.
>Yes the costs would not matter.
>
>>            __       N
>>           |  | --I1-|
>> R3--///---|R1| --I2-|
>>           |__| --I3-|
>>                     |   __
>>                     |_1|  |
>>                        |R2|
>>                        |__|
>
>
>> Section 3.8.1.1 in 2740 ( Next hop calculation ) says
>> "Calculating router assigns the next hop IPv6 address to be the
>> link-local interface address contained in Router X's link-lsa for the
>> link"
>
>>--In this case R1 has three such link-LSAs. How should they be treated?
>As Yasu put it, it would be nice to state the below instead for section
>3.8.1.1 with minor corrections to Yasu's text
>
>"Calculating router assigns the next hop IPv6 addresses to be the
>collection of the link-local interface address contained in Router X's
>Link-LSAs advertised from each of Router X's interface on the link"
>
>Would this help?
>
>Thanks,
>Vishwas
>
>>
>>        __       N
>>       |  | --I1-|
>>  R3---|R1| --I2-|
>>       |__| --I3-|
>>                 |   __
>>                 |_1|  |
>>                    |R2|
>>                    |__|
>>
>>
>
>
>
>On Sun, 15 Sep 2002 08:20:00 -0400, Manral, Vishwas
><VishwasM@NETPLANE.COM> wrote:
>
>>Hi Darshan,
>>
>>As all the interfaces are advertized in LSA's all will be considered
>during
>>routing table calculations, so will play a role in other routers
>routing
>>table calculations.
>>
>>As each interface has its own cost the interface with the lowest cost
>would
>>be preferred.  However if all three interfaces have the same cost I
>guess we
>>will have all three as next-hops in the routing table.
>>
>>Thanks,
>>Vishwas
>>
>>-----Original Message-----
>>From: Darshan Purohit [mailto:darshan.purohit@NOKIA.COM]
>>Sent: Thursday, September 05, 2002 11:57 PM
>>To: OSPF@DISCUSS.MICROSOFT.COM
>>Subject: Multiple Interfaces to a Link
>>
>>
>
>
>>Hi All,
>>I had a question about multiple interfaces on the same link. The setup
>>is:
>>
>>      __
>>     |  | --1--|
>>E1---|R1| --2--|
>>     |__| --3--|
>>               |   __
>>               |_1|  |
>>                  |R2|
>>                  |__|
>>
>>
>>As mentioned in 2740, section 3.9, R1 uses only interface 1 (say), for
>>control traffic and setting up adjacency with R2. However,
>>R1 originates a router LSA for each interface 1,2 and 3  ,
>>and it generates a separate Link LSA for each interface. Now, for a
>>route
>>through R1, how is R2 supposed to pick the nexthop link local address.
>>Will it be I1 - the interface which is being used for control traffic,
>>OR any one of the routers Link LSA , OR all three of them.
>>
>>In the setup above, will the passive interfaces of R1 be used just as
>>backups in case the primary fails, or will they really play a role when
>>R2 (or any other Router in the area) does its routing table
>>calculation.
>>
>>Thanks.
>>Darshan


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 23 08:50:06 2002
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 IAA06793
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Sep 2002 08:50:06 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.007331E8@cherry.ease.lsoft.com>; Mon, 23 Sep 2002 8:51:49 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 228004 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 23 Sep 2002 08:51:48 -0400
Received: from 212.59.42.147 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 23 Sep 2002 08:51:47 -0400
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.7
Mime-Version: 1.0
Message-ID:  <1032785519.11928.14.camel@de-h-jne-lx.de-h.dt.net>
Date:         Mon, 23 Sep 2002 14:51:59 +0200
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Jens Nelke <jens.nelke@DATENTECHNIK.COM>
Subject: Question about draft-katz-yeung-ospf-traffic
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi all,

Under point 2.5.8 Unreserved Bandwidth the authors mention priority
levels. But I don't really understand which priority levels they mean. I
hope someone can explain these priority levels to me.

Regards

Jens
--
-------------------------------------------------------------------------
Dipl.-Ing. Jens Nelke           Datentechnik Intercom GmbH
Entwicklung                     Frankenring 14
                                30855 Langenhagen
-------------------------------------------------------------------------
Tel.: +49 511 978197-657        <http://www.datentechnik.com/>
Fax.: +49 511 978197-670        <mailto:jens.nelke@datentechnik.com>
-------------------------------------------------------------------------

<<< From 1st of October 2002 Datentechnik & Ascom Transmission will
serve you as Keymile >>>


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 23 09:56:02 2002
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 JAA09190
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Sep 2002 09:56:02 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.007335CB@cherry.ease.lsoft.com>; Mon, 23 Sep 2002 9:57:51 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 207857 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 23 Sep 2002 09:57:50 -0400
Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 23 Sep 2002 09:57:50 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id JAA05734 for <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 23 Sep 2002
          09:57:48 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA26095
          for <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 23 Sep 2002 09:57:49 -0400
          (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S8R71NW8>; Mon, 23 Sep 2002 09:57:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <39469E08BD83D411A3D900204840EC5576335E@vie-msgusr-01.dc.fore.com>
Date:         Mon, 23 Sep 2002 09:57:42 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Naidu, Venkata" <Venkata.Naidu@MARCONI.COM>
Subject: Re: Question about draft-katz-yeung-ospf-traffic
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Jens,

-> Under point 2.5.8 Unreserved Bandwidth the authors mention priority
-> levels. But I don't really understand which priority levels
-> they mean. I
-> hope someone can explain these priority levels to me.

  Look at RFC2702 sections 5.7 and 5.8.

--
Venkata.


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 23 19:55:45 2002
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 TAA29755
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Sep 2002 19:55:44 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00734888@cherry.ease.lsoft.com>; Mon, 23 Sep 2002 19:57:33 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 209308 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 23 Sep 2002 19:57:33 -0400
Received: from 207.217.120.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 23 Sep 2002 19:57:32 -0400
Received: from user-2ivfk72.dialup.mindspring.com ([165.247.208.226]
          helo=earthlink.net) by scaup.mail.pas.earthlink.net with esmtp (Exim
          3.33 #1) id 17td4z-0003L4-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 23
          Sep 2002 16:57:30 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <20020904134144.91048.qmail@web12408.mail.yahoo.com>
            <00c901c2541c$5a427f00$b4036c6b@sisodomain.com>
            <200209041618.g84GIF429584@cirrus.juniper.net>
            <04d801c254c8$bb19ae50$b4036c6b@sisodomain.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D8FAD84.4F6F79A3@earthlink.net>
Date:         Mon, 23 Sep 2002 17:10:44 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Manov and Group,

        I wanted to wait to see what comments I saw and then try to give
        a limited response. I realize that you like most of us are not
        technical writers, but hopefully good engineers. So, I am going
        to skip on any verbage except that your first sentance in section
        "1" is the longest I have ever seen at 62 words.. Wow..

        Section 6. Database Granularity
        "key design difference" ...

           If I said that, "OSPF uses a distance vector algorithm for
inter-area
           routes and a link-state protocol for intra-area routes vs IS-IS
using
           link-state protocols for both",  wouldn't this be the key / most
important
           design difference?

        There are a number of more items that I question in this document, but
the
        reader should question them for himself or herself..

        Enough said....


        Mitchell Erblich
        ===================


Manav Bhatia wrote:
>
> Expounding on what Dave just said.
>
> The first two fields in the IP header are the 4-bit version number and the
> 4-bit header length. The value of the first byte is normally 0x45. If there
> are IP header options attached to the IP header, the first byte can be
> between 0x46 and 0x4F. The first byte in an IS-IS packet is always 0x83.
> Thus by looking at the first byte of an incoming packet, the receiver can
> separate IP and IS-IS packets. Because of this feature we do not to depend
> on the ATM layer anymore to help us with the demultiplexing. Routers can
> now send and receive both IS-IS and IP packets using vc mux encaps which is
> what we wanted to do to avoid the atm cell tax.
>
> But is anybody aware of why there aren't any implementations out there for
> this or why this wasn't accepted?
>
> ----- Original Message -----
> From: "Dave Katz" <dkatz@JUNIPER.NET>
> To: <OSPF@DISCUSS.MICROSOFT.COM>
> Sent: Wednesday, September 04, 2002 9:48 PM
> Subject: Re: Paper comparing OSPF and ISIS
>
> | Actually this is not true;  there is the infamous "Henk Hack" whereby
> | you can run ISIS over a VCMUX PVC:  you do protocol identification based
> | on the first byte of the packet.  0x83 (IIRC) is IS-IS, 0x4x is IP.  It's
> | a NLPID stood on its head.
> |
> | I don't know that anybody has implemented this, though we've considered
> it;
> | mostly it took the wind out of the sails of ISIS-over-IP.
> |
> |    IS-IS requires ATM LLC/SNAP encapsulation because its not an IP packet
> |    thereby loosing on the bandwidth efficiency we have with OSPF.


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 23 20:13:00 2002
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 UAA00314
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Sep 2002 20:13:00 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00734ABA@cherry.ease.lsoft.com>; Mon, 23 Sep 2002 20:14:49 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 209371 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 23 Sep 2002 20:14:49 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 23 Sep 2002 20:14:49 -0400
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8O0Emm11193 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 23 Sep 2002 17:14:48 -0700 (PDT)
          (envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id
          g8O0Emi90993; Mon, 23 Sep 2002 17:14:48 -0700 (PDT) (envelope-from
          dkatz@cirrus.juniper.net)
References: <20020904134144.91048.qmail@web12408.mail.yahoo.com>
            <00c901c2541c$5a427f00$b4036c6b@sisodomain.com>
            <200209041618.g84GIF429584@cirrus.juniper.net>
            <04d801c254c8$bb19ae50$b4036c6b@sisodomain.com>
            <3D8FAD84.4F6F79A3@earthlink.net>
Message-ID:  <200209240014.g8O0Emi90993@cirrus.juniper.net>
Date:         Mon, 23 Sep 2002 17:14:48 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Dave Katz <dkatz@JUNIPER.NET>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D8FAD84.4F6F79A3@earthlink.net> (message from Erblichs on Mon,
              23 Sep 2002 17:10:44 -0700)
Precedence: list

This sentence is also fundamentally incorrect.

              If I said that, "OSPF uses a distance vector algorithm for
   inter-area
              routes and a link-state protocol for intra-area routes vs IS-IS
   using
              link-state protocols for both",  wouldn't this be the key / most
   important
              design difference?


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 23 20:44:43 2002
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 UAA01163
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Sep 2002 20:44:42 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00734ABA@cherry.ease.lsoft.com>; Mon, 23 Sep 2002 20:46:32 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 209416 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 23 Sep 2002 20:46:32 -0400
Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 23 Sep 2002 20:46:32 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id UAA09195 for <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 23 Sep 2002
          20:46:28 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA15743
          for <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 23 Sep 2002 20:46:31 -0400
          (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S8R7FMKW>; Mon, 23 Sep 2002 20:46:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <39469E08BD83D411A3D900204840EC5576336C@vie-msgusr-01.dc.fore.com>
Date:         Mon, 23 Sep 2002 20:46:20 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Naidu, Venkata" <Venkata.Naidu@MARCONI.COM>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

All,

  The sentence may be fundamentally incorrect as per the
  deployed base of both protocols (DV routing is deployed
  at the second level in the hierarchy. Moreover, the
  hierarchy level is also not grown).

  But theoretically what is said is possible. Alex tried
  MLOSPF (I think, ISIS can also be done in similar way).

  Interested folks may want to look at below threads:


http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind9908&L=OSPF&P=R2439&I=
-3

http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R1078&I=
-3

  (Un)fortunately, Alex's web page is not working :)

  One more point, it is not required that all multi-level
  hierarchy protocols must follow DV routing at the higher
  levels. *Theoretically* one can do hierarchical routing
  with DV algorithms also.

--
Venkata

-> This sentence is also fundamentally incorrect.
->
->    If I said that, "OSPF uses a distance vector
->    algorithm for inter-area routes and a link-state protocol
->    for intra-area routes vs IS-IS using link-state protocols
->    for both",  wouldn't this be the key / most important
->    design difference?
->


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 23 21:15:13 2002
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 VAA01919
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Sep 2002 21:15:13 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00734B69@cherry.ease.lsoft.com>; Mon, 23 Sep 2002 21:17:02 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 209456 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 23 Sep 2002 21:17:01 -0400
Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 23 Sep 2002 21:17:01 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392)
          id <01KMULFYIUG08WZUQE@omega7.wr.usgs.gov> for
          OSPF@DISCUSS.MICROSOFT.COM; Mon, 23 Sep 2002 18:16:51 -0700 (PDT)
X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM
X-VMS-Cc: pmurphy,mani_devarajan@NET.COM
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Message-ID:  <01KMULFYJ03M8WZUQE@omega7.wr.usgs.gov>
Date:         Mon, 23 Sep 2002 18:16:51 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: NSSA Question
Comments: cc: MANI_DEVARAJAN@NET.COM
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Mani,

> My question is, if R1 in Area1 receives type-4 Summary LSA for
> NSSA ASBR and able to reach the ASBR through inter-area path,
> the external destination must be reachable without advertising
> type-4 LSA for R3 into area1. Is my understanding correct ....

No. Regarding

>                                    ASBR
>       -----     -----     -----    -----     -----
>      |     |   |     |   |     |  |     |   |     |
>      | R1  |   | R2  |   |  R3 |  |  R4 |   | R5  |
>      |     |   |     |   |     |  |     |   |     |
>       -----     -----     -----    -----     -----
>           |     |   |      |  |     |  |     |
>            -----     ------    -----    -----
>            AREA1     AREA 0    AREA2    RIP Network
>                                 NSSA

there should not be a Type 4 summary LSA for R4 in either R1 or R2's
LSDB. However NSSA implementations may be a little sloppy in suppressing
these, since, their existence, while useless, is harmless to the
forwarding process. For R1 to install routes to networks learned by R4
from R5 via RIP, it must have an installed route to R3 (installed by
calculating a route to R3 during the processing of its Type 4 summary
LSA, which was originated by R2), plus installed routes to their Type 5
LSA forwarding addresses (installed during the SPF calculation as
opposed to the processing of Type 4 summary LSAs) that were copied from
R4's Type 7 LSAs during their translation by R3 to Type 5 LSAs. Any Type
4 summary LSA for R4 will never factor in the installation process of
these Type 5 LSAs originated by R3.

Type 4 summary LSAs for NSSA ASBRs do clutter the LSDBs and routing
tables of Area 0 and Area 1 with useless LSAs and routing table entries
respectivelyfor these NSSA ASBRs. Implementations should not originate
Type 4 summary LSAs for NSSA ASBRs. If they do, complain.

Pat


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 23 21:26:09 2002
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 VAA02323
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Sep 2002 21:26:08 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00734AE2@cherry.ease.lsoft.com>; Mon, 23 Sep 2002 21:27:58 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 209501 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 23 Sep 2002 21:27:58 -0400
Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 23 Sep 2002 21:27:58 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392)
          id <01KMULTPFGH48WZUQE@omega7.wr.usgs.gov> for
          OSPF@DISCUSS.MICROSOFT.COM; Mon, 23 Sep 2002 18:27:56 -0700 (PDT)
X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM
X-VMS-Cc: PMURPHY,mani_devarajan@NET.COM
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Message-ID:  <01KMULTPFGH68WZUQE@omega7.wr.usgs.gov>
Date:         Mon, 23 Sep 2002 18:27:56 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: Question about choosing NSSA ABR
Comments: cc: MANI_DEVARAJAN@NET.COM
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Mani,

>If the forwarding is 0.0.0.0, all the traffic for NSSA ASBR
>will be passing thorugh the NSSA ABR which did the type-7
>to type-5 translation. In this case choosing the NSSA ABR
>with best cost path to the NSSA ASBR will be a better
>option. Is my understanding correct?

The latest NSSA draft (soon to be an RFC) allows the network
implementor to configure multiple NSSA ABRs to be
translators regardless of their router ID. Properly
configured the presense of multiple NSSA translators can
cause the best cost path to be chosen. Indeed this was one
of the motivations for this adding this new feature.

Pat


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 23 22:25:35 2002
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 WAA04250
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Sep 2002 22:25:35 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00734E07@cherry.ease.lsoft.com>; Mon, 23 Sep 2002 22:27:25 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 209647 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 23 Sep 2002 22:27:25 -0400
Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 23 Sep 2002 22:27:25 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392)
          id <01KMUNWB0OEO8WZUQE@omega7.wr.usgs.gov> for
          OSPF@DISCUSS.MICROSOFT.COM; Mon, 23 Sep 2002 19:27:18 -0700 (PDT)
X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM
X-VMS-Cc: pmurphy,mani_devarajan@NET.COM
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Message-ID:  <01KMUNWB0PCY8WZUQE@omega7.wr.usgs.gov>
Date:         Mon, 23 Sep 2002 19:27:18 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: Question on NSSA ABRs
Comments: cc: MANI_DEVARAJAN@NET.COM
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Mani,

Regarding this modified diagram of yours

                                   ASBR
      -----     ------     -----    -------     -----
     |     |   |      |   |     |  |       |   |     |
     | R1  |   | R2   |   |  R3 |  |  R5   |   | R6  |
     |     |   |      |   |     |  |       |   |     |
      -----     ------     -----    -------     -----
          |I1 I2|  | |I4  I5|  |I6 I9| |  |I11  |   |
           -----   |  ------    -----  |   -----    |
           AREA1   |  AREA 0    AREA2  |            |
                   |I3                 |I10        N11
                   |      -----        |       RIP learned
                   |   I7|     |I8     |         network
                    -----|  R4 |-------
                   AREA0 |     | AREA2
                          -----

It implies R5 learns an external route to N11 from R6 via
RIP across I11. R5 should pick a single forwarding address
for the RIP learned route to N11 and stick with it provided
the interface associated with that address remains in an Up
state. R5 makes no assumptions about whether R3 or R4 is
translating when picking this address. Its best to make R5's
I11 interface a part of the OSPF cloud (i.e. make it a stub
network). Then the forwarding address can simply be R6's
address on I11. Barring that choice, a local address (i.e.
loopback address) is chosen next since it is always in an Up
state. Stub interface network addresses are chosen after
local addresses. Addresses, such as those assigned to I9 and
I10, are the last choice.

Thus when R3 and R4 toggle their elected translator duties,
the path from R2 to N11 should not change. R2's path to N11
depends only on what forwarding address is picked by R5 for
N11 and the interface costs of I3, I4, I6 and I8. It has
nothing to do with who is translating (unless address ranges
are a factor). Note that an address that is part of I11
might caused both paths to be used.

Finally, in the new NSSA draft, Type 7 LSAs that are
translated into Type 5 LSAs by R3 and R4 with a non-zero
forwarding address (such as the one for N11) are never
flushed by an NSSA elected translator, such as R3, when it
is deposed by another NSSA translator, such as R4, via the
NSSA translator election vehicle. Instead these LSAs are
allowed to simply age out. This is done to prevent the
flushing and reorigination of large amounts of translated
Type 7 LSAs during periods of NSSA border instability. Both
LSAs represent the same path with the same forwarding
address. They just have different originators.

Pat


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 23 22:40:39 2002
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 WAA04859
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Sep 2002 22:40:39 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00734E27@cherry.ease.lsoft.com>; Mon, 23 Sep 2002 22:42:29 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 209677 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 23 Sep 2002 22:42:29 -0400
Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 23 Sep 2002 22:32:29 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <19.00734C92@cherry.ease.lsoft.com>;
          Mon, 23 Sep 2002 22:32:29 -0400
Message-ID:  <OSPF%2002092322422939@DISCUSS.MICROSOFT.COM>
Date:         Mon, 23 Sep 2002 22:32:29 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Muler Pan <umpanj@CC.UMANITOBA.CA>
Subject: OSPF on TOP of ATM network
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi,

I'd like to get some idea how a real carrier type network looks like,
thanks in advance.

Suppose a carrier has a ATM back bone and want to run IP service on top of
it,
1. Is the ATM network normally fully meshed?
2. If OSPF is selected as the IGP, which mode is usually implemented, NBMA
or Point-to-MultiPoint? NBMA is not very reliable in case a route looses
connection to Designated Router, mean while, based on my understanding, in
case of overlaying IP on top of ATM backbone,Point-to-MultiPoint is not
very efficient since traffic may get across ATM network more than once. Is
my understanding correct?

Thanks!
Muler


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 24 00:06:56 2002
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 AAA06372
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Sep 2002 00:06:55 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.007353F9@cherry.ease.lsoft.com>; Tue, 24 Sep 2002 0:08:45 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 209884 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 24 Sep 2002 00:08:45 -0400
Received: from 193.71.199.94 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 23 Sep 2002 23:58:45 -0400
Received: from [10.9.9.110] (helo=snoopy.runbox.com) by tramp.runbox.com with
          esmtp (Exim 4.05-VA-mm1) id 17tgqS-0008JV-00 for
          OSPF@discuss.microsoft.com; Tue, 24 Sep 2002 05:58:44 +0200
Received: from [203.200.20.226] (helo=Manav) (Authenticated Sender=dovek) by
          snoopy.runbox.com with asmtp (Exim 3.35 #1) id 17tgqO-0007pf-00 for
          OSPF@DISCUSS.MICROSOFT.COM; Tue, 24 Sep 2002 05:58:40 +0200
References: <20020904134144.91048.qmail@web12408.mail.yahoo.com>           
            <00c901c2541c$5a427f00$b4036c6b@sisodomain.com>           
            <200209041618.g84GIF429584@cirrus.juniper.net>           
            <04d801c254c8$bb19ae50$b4036c6b@sisodomain.com> 
            <3D8FAD84.4F6F79A3@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID:  <099601c2637e$9823b020$b4036c6b@sisodomain.com>
Date:         Tue, 24 Sep 2002 09:28:04 +0530
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Misha Dovek <dovek@RUNBOX.COM>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

OSPF has distance vector in backbone because all the information required by
the routers inside an area to compute best paths to other areas is "leaked"
to them via summary LSAs. This was not done in the original ISIS spec and
the L1 (internal) routers had just one default exit out of  the L1 area.
This forced ISIS to have strict hierarchical routing in L2 subdomain too.

is my understanding correct?

Misha

----- Original Message -----
From: "Erblichs" <erblichs@EARTHLINK.NET>
To: <OSPF@DISCUSS.MICROSOFT.COM>
Sent: Tuesday, September 24, 2002 5:40 AM
Subject: Re: Paper comparing OSPF and ISIS


> Manov and Group,
>
>         I wanted to wait to see what comments I saw and then try to give
>         a limited response. I realize that you like most of us are not
>         technical writers, but hopefully good engineers. So, I am going
>         to skip on any verbage except that your first sentance in section
>         "1" is the longest I have ever seen at 62 words.. Wow..
>
>         Section 6. Database Granularity
>         "key design difference" ...
>
>            If I said that, "OSPF uses a distance vector algorithm for
> inter-area
>            routes and a link-state protocol for intra-area routes vs IS-IS
> using
>            link-state protocols for both",  wouldn't this be the key /
most
> important
>            design difference?
>
>         There are a number of more items that I question in this document,
but
> the
>         reader should question them for himself or herself..
>
>         Enough said....
>
>
>         Mitchell Erblich
>         ===================
>
>
> Manav Bhatia wrote:
> >
> > Expounding on what Dave just said.
> >
> > The first two fields in the IP header are the 4-bit version number and
the
> > 4-bit header length. The value of the first byte is normally 0x45. If
there
> > are IP header options attached to the IP header, the first byte can be
> > between 0x46 and 0x4F. The first byte in an IS-IS packet is always 0x83.
> > Thus by looking at the first byte of an incoming packet, the receiver
can
> > separate IP and IS-IS packets. Because of this feature we do not to
depend
> > on the ATM layer anymore to help us with the demultiplexing. Routers can
> > now send and receive both IS-IS and IP packets using vc mux encaps which
is
> > what we wanted to do to avoid the atm cell tax.
> >
> > But is anybody aware of why there aren't any implementations out there
for
> > this or why this wasn't accepted?
> >
> > ----- Original Message -----
> > From: "Dave Katz" <dkatz@JUNIPER.NET>
> > To: <OSPF@DISCUSS.MICROSOFT.COM>
> > Sent: Wednesday, September 04, 2002 9:48 PM
> > Subject: Re: Paper comparing OSPF and ISIS
> >
> > | Actually this is not true;  there is the infamous "Henk Hack" whereby
> > | you can run ISIS over a VCMUX PVC:  you do protocol identification
based
> > | on the first byte of the packet.  0x83 (IIRC) is IS-IS, 0x4x is IP.
It's
> > | a NLPID stood on its head.
> > |
> > | I don't know that anybody has implemented this, though we've
considered
> > it;
> > | mostly it took the wind out of the sails of ISIS-over-IP.
> > |
> > |    IS-IS requires ATM LLC/SNAP encapsulation because its not an IP
packet
> > |    thereby loosing on the bandwidth efficiency we have with OSPF.
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 24 01:55:20 2002
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 BAA08542
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Sep 2002 01:55:20 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00735BA0@cherry.ease.lsoft.com>; Tue, 24 Sep 2002 1:57:08 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 210512 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 24 Sep 2002 01:57:08 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 24 Sep 2002 01:57:08 -0400
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8O5v7m27549 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 23 Sep 2002 22:57:07 -0700 (PDT)
          (envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id
          g8O5v7W91545; Mon, 23 Sep 2002 22:57:07 -0700 (PDT) (envelope-from
          dkatz@cirrus.juniper.net)
References: <20020904134144.91048.qmail@web12408.mail.yahoo.com>
            <00c901c2541c$5a427f00$b4036c6b@sisodomain.com>
            <200209041618.g84GIF429584@cirrus.juniper.net>
            <04d801c254c8$bb19ae50$b4036c6b@sisodomain.com>
            <3D8FAD84.4F6F79A3@earthlink.net>
            <099601c2637e$9823b020$b4036c6b@sisodomain.com>
Message-ID:  <200209240557.g8O5v7W91545@cirrus.juniper.net>
Date:         Mon, 23 Sep 2002 22:57:07 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Dave Katz <dkatz@JUNIPER.NET>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <099601c2637e$9823b020$b4036c6b@sisodomain.com> (message from
              Misha Dovek on Tue, 24 Sep 2002 09:28:04 +0530)
Precedence: list

   OSPF has distance vector in backbone because all the information required by
   the routers inside an area to compute best paths to other areas is "leaked"
   to them via summary LSAs. This was not done in the original ISIS spec and
   the L1 (internal) routers had just one default exit out of  the L1 area.
   This forced ISIS to have strict hierarchical routing in L2 subdomain too.

   is my understanding correct?

No.

So long as the L2/Backbone sees some kind of summarization of the contents
of the area (as opposed to the details of the area) then it is inherently
DV.  As the whole point of having areas is to hide the details and summarize,
there's no true LS routing interarea.  The optimality or lack of it is
orthogonal to whether the routing is DV or not.  Even if no summarization
is configured in OSPF, the Summary LSAs that represent each area are
nothing but a distance and a next hop.


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 24 01:56:25 2002
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 BAA08596
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Sep 2002 01:56:25 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00735AD2@cherry.ease.lsoft.com>; Tue, 24 Sep 2002 1:58:13 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 210536 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 24 Sep 2002 01:58:13 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 24 Sep 2002 01:58:13 -0400
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8O5wCm27586 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 23 Sep 2002 22:58:12 -0700 (PDT)
          (envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id
          g8O5wCo91556; Mon, 23 Sep 2002 22:58:12 -0700 (PDT) (envelope-from
          dkatz@cirrus.juniper.net)
References: <20020904134144.91048.qmail@web12408.mail.yahoo.com>
            <00c901c2541c$5a427f00$b4036c6b@sisodomain.com>
            <200209041618.g84GIF429584@cirrus.juniper.net>
            <04d801c254c8$bb19ae50$b4036c6b@sisodomain.com>
            <3D8FAD84.4F6F79A3@earthlink.net>
            <099601c2637e$9823b020$b4036c6b@sisodomain.com>
            <200209240557.g8O5v7W91545@cirrus.juniper.net>
Message-ID:  <200209240558.g8O5wCo91556@cirrus.juniper.net>
Date:         Mon, 23 Sep 2002 22:58:12 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Dave Katz <dkatz@JUNIPER.NET>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <200209240557.g8O5v7W91545@cirrus.juniper.net> (message from Dave
              Katz on Mon, 23 Sep 2002 22:57:07 -0700)
Precedence: list

   is configured in OSPF, the Summary LSAs that represent each area are

Er, that is, "each route."


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 24 08:04:14 2002
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 IAA23936
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Sep 2002 08:04:14 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00736593@cherry.ease.lsoft.com>; Tue, 24 Sep 2002 8:06:02 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 211815 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 24 Sep 2002 08:06:02 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 24 Sep 2002 07:56:01 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id HAA23505; Tue, 24 Sep 2002 07:54:11
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200209241154.HAA23505@ietf.org>
Date:         Tue, 24 Sep 2002 07:54:11 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.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-dc-04.txt
To: OSPF@DISCUSS.MICROSOFT.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           : Detecting Inactive Neighbors over OSPF Demand Circuits
        Author(s)       : S. Rao, A. Zinin, A. Roy
        Filename        : draft-ietf-ospf-dc-04.txt
        Pages           : 5
        Date            : 2002-9-23

OSPF [RFC2328] is a link-state intra-domain routing protocol used in
IP networks. OSPF behavior over demand circuits is optimized in
[RFC1793] to minimize the amount of overhead traffic. A part of OSPF
demand circuit extensions is the Hello suppression mechanism. This
technique allows a demand circuit to go down when no interesting
traffic is going through the link. However, it also introduces a
problem, where it becomes impossible to detect a OSPF-inactive
neighbor over such a link. This memo addresses the above problem by
the neighbor probing mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-04.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-dc-04.txt".

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


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

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-ospf-dc-04.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:     <2002-9-23152137.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID:     <2002-9-23152137.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 24 09:51:10 2002
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 JAA27401
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Sep 2002 09:51:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.007367CA@cherry.ease.lsoft.com>; Tue, 24 Sep 2002 9:52:58 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 212202 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 24 Sep 2002 09:52:58 -0400
Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 24 Sep 2002 09:52:57 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id JAA27728 for <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 24 Sep 2002
          09:52:56 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08302
          for <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 24 Sep 2002 09:52:56 -0400
          (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S8R7F7LS>; Tue, 24 Sep 2002 09:52:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <39469E08BD83D411A3D900204840EC5576336E@vie-msgusr-01.dc.fore.com>
Date:         Tue, 24 Sep 2002 09:52:55 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Naidu, Venkata" <Venkata.Naidu@MARCONI.COM>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

->   hierarchy protocols must follow DV routing at the higher

Er, that is, "link-state."


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 24 11:40:11 2002
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 LAA02827
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Sep 2002 11:40:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00736F0E@cherry.ease.lsoft.com>; Tue, 24 Sep 2002 11:40:48 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 212639 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 24 Sep 2002 11:40:48 -0400
Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 24 Sep 2002 11:40:47 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392)
          id <01KMVFM1FYN48WZ8AZ@omega7.wr.usgs.gov> for
          OSPF@DISCUSS.MICROSOFT.COM; Tue, 24 Sep 2002 08:40:45 -0700 (PDT)
X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM
X-VMS-Cc: pmurphy,VishwasM@NETPLANE.COM
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Message-ID:  <01KMVFM1FYN68WZ8AZ@omega7.wr.usgs.gov>
Date:         Tue, 24 Sep 2002 08:40:45 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: Regarding draft-ietf-ospf-5to7-01.txt
Comments: cc: VISHWASM@NETPLANE.COM
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Vishwas,

>a) Shouldn't the translator now set the E-bit in its router LSA
>into the NSSA area because according to step 3 Section 3.5 of the
>NSSA draft none of the translated NSSA LSA's would be considered
>for the routing table calculation and the entire purpose of 5to7
>would be defeated.

Yes the E-bit should be set. Fortunately, since the translator is
one of the NSSA's ABRs, it will have a routing table entry. It just
won't have one that reflects its ASBR status, which it should. I
will check the draft and make the change.

>b)  Regarding the translator election for the elected translator,
>we could as well just have the guy with the lowest router-id become
>translator this can be done without actually adding any change to
>packets and can be done as part of the 7to5 translator election.

The NSSA Translator election algorithm in the current draft is
somewhat subtle. When I wrote the 5to7 draft I surmised that the
performance criteria used to configure one NSSA ABR as a 7to5
translator over another NSSA ABR would also apply to picking
the same NSSA ABR as the 5to7 translator. The RFC 1587 NSSA
translator was simply chosen as the one with the highest router ID.
The current NSSA draft documents that translators should be chosen
based on performance requirements, not router ID. That is why it
makes them configurable. Other than splitting the translator
processing load, I can't see any performance benefit to picking the
default 5to7 translator as the one with the lowest router-id.
Furthermore, I think it is best if the network implementor can
simply rely on the highest router ID being the translator in both
cases. If he has multiple NSSA ABRs, he may want to lock in the best
performing translator by manipulating the router ID.

Pat


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 24 13:10:25 2002
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 NAA06273
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Sep 2002 13:10:25 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00737053@cherry.ease.lsoft.com>; Tue, 24 Sep 2002 13:12:15 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 213062 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 24 Sep 2002 13:12:15 -0400
Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 24 Sep 2002 13:12:15 -0400
Received: from user-2ivfncl.dialup.mindspring.com ([165.247.221.149]
          helo=earthlink.net) by snipe.mail.pas.earthlink.net with esmtp (Exim
          3.33 #1) id 17ttEL-0003zr-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 24
          Sep 2002 10:12:14 -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: <20020904134144.91048.qmail@web12408.mail.yahoo.com>
            <00c901c2541c$5a427f00$b4036c6b@sisodomain.com>
            <200209041618.g84GIF429584@cirrus.juniper.net>
            <04d801c254c8$bb19ae50$b4036c6b@sisodomain.com>
            <3D8FAD84.4F6F79A3@earthlink.net>
            <099601c2637e$9823b020$b4036c6b@sisodomain.com>
            <200209240557.g8O5v7W91545@cirrus.juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D909FED.EB1212DF@earthlink.net>
Date:         Tue, 24 Sep 2002 10:25:01 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Dave,

        1) In my opinion, this is the most major difference between
           OSPF and IS-IS.

        2) Reference : Cisco's Routing TCP/IP : p. 475
           "So, while OSPF is a link state protocol within an area, it uses
            a distance vector algorithm to find inter-area routes".


        So my statement:

                If I said that, "OSPF uses a distance vector algorithm for
   inter-area
              routes and a link-state protocol for intra-area routes vs
IS-IS
   using
              link-state protocols for both",  wouldn't this be the key
/ most
   important
              design difference?


        So, Dave you disagree with #1, or #2, or both?
        If you disagree with #2 are you disagreeing with "uses a distance
vector
        algorithm"?

        Mitchell Erblich
------------------------------------
Dave Katz wrote:
>
>    OSPF has distance vector in backbone because all the information required by
>    the routers inside an area to compute best paths to other areas is "leaked"
>    to them via summary LSAs. This was not done in the original ISIS spec and
>    the L1 (internal) routers had just one default exit out of  the L1 area.
>    This forced ISIS to have strict hierarchical routing in L2 subdomain too.
>
>    is my understanding correct?
>
> No.
>
> So long as the L2/Backbone sees some kind of summarization of the contents
> of the area (as opposed to the details of the area) then it is inherently
> DV.  As the whole point of having areas is to hide the details and summarize,
> there's no true LS routing interarea.  The optimality or lack of it is
> orthogonal to whether the routing is DV or not.  Even if no summarization
> is configured in OSPF, the Summary LSAs that represent each area are
> nothing but a distance and a next hop.


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 24 13:18:12 2002
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 NAA06535
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Sep 2002 13:18:12 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00736FDF@cherry.ease.lsoft.com>; Tue, 24 Sep 2002 13:20:03 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 213099 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 24 Sep 2002 13:20:03 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 24 Sep 2002 13:20:02 -0400
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8OHK2m61665 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 24 Sep 2002 10:20:02 -0700 (PDT)
          (envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id
          g8OHK2x93106; Tue, 24 Sep 2002 10:20:02 -0700 (PDT) (envelope-from
          dkatz@cirrus.juniper.net)
References: <20020904134144.91048.qmail@web12408.mail.yahoo.com>
            <00c901c2541c$5a427f00$b4036c6b@sisodomain.com>
            <200209041618.g84GIF429584@cirrus.juniper.net>
            <04d801c254c8$bb19ae50$b4036c6b@sisodomain.com>
            <3D8FAD84.4F6F79A3@earthlink.net>
            <099601c2637e$9823b020$b4036c6b@sisodomain.com>
            <200209240557.g8O5v7W91545@cirrus.juniper.net>
            <3D909FED.EB1212DF@earthlink.net>
Message-ID:  <200209241720.g8OHK2x93106@cirrus.juniper.net>
Date:         Tue, 24 Sep 2002 10:20:02 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Dave Katz <dkatz@JUNIPER.NET>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D909FED.EB1212DF@earthlink.net> (message from Erblichs on Tue,
              24 Sep 2002 10:25:01 -0700)
Precedence: list

           1) In my opinion, this is the most major difference between
              OSPF and IS-IS.

Unfortunately it is fundamentally untrue.

           2) Reference : Cisco's Routing TCP/IP : p. 475
              "So, while OSPF is a link state protocol within an area, it uses
               a distance vector algorithm to find inter-area routes".


           So my statement:

                   If I said that, "OSPF uses a distance vector algorithm for
      inter-area
                 routes and a link-state protocol for intra-area routes vs
   IS-IS
      using
                 link-state protocols for both",  wouldn't this be the key
   / most
      important
                 design difference?


           So, Dave you disagree with #1, or #2, or both?
           If you disagree with #2 are you disagreeing with "uses a distance
   vector
           algorithm"?

All of the above.  Both protocols effectively use a DV algorithm for
interarea routes, as both protocols advertise only destination/distance
information across area boundaries, and purposely hide topology information.
The differences between them are only of degree (and even the degree has
been made negligible by the route leaking mods to ISIS.)

Bottom line is that there is no *fundamental* difference between ISIS
and OSPF; it's all in details and style.


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 24 13:26:59 2002
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 NAA06698
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Sep 2002 13:26:59 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.007370DA@cherry.ease.lsoft.com>; Tue, 24 Sep 2002 13:28:48 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 213161 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 24 Sep 2002 13:28:48 -0400
Received: from 207.217.120.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 24 Sep 2002 13:28:48 -0400
Received: from user-2ivfncl.dialup.mindspring.com ([165.247.221.149]
          helo=earthlink.net) by conure.mail.pas.earthlink.net with esmtp (Exim
          3.33 #1) id 17ttUK-0000hs-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 24
          Sep 2002 10:28:44 -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: <39469E08BD83D411A3D900204840EC5576336C@vie-msgusr-01.dc.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D90A3CC.1A99FA7B@earthlink.net>
Date:         Tue, 24 Sep 2002 10:41:32 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Venkata,

        I am just a little lost..

        Are you suggesting that IS-IS L2 only routers
        do not run a SPF algorithm?

        If you think that then read the Cisco's
        Reference IS-IS chapter
        since you guys don't belive me ...

        My understading is that a IS-IS L1, or L2, or
        L1/L2 routers will build level specific
        link state databases. AND OSPF uses
        "See Cisco's Routing TCP/IP p.475" says it
        uses a distance vector algoritm. Assuming
        that you don't believe me..



        Mitchell Erblich
        ==========================


"Naidu, Venkata" wrote:
>
> All,
>
>   The sentence may be fundamentally incorrect as per the
>   deployed base of both protocols (DV routing is deployed
>   at the second level in the hierarchy. Moreover, the
>   hierarchy level is also not grown).
>
>   But theoretically what is said is possible. Alex tried
>   MLOSPF (I think, ISIS can also be done in similar way).
>
>   Interested folks may want to look at below threads:
>
> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind9908&L=OSPF&P=R2439&I=
> -3
>
> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R1078&I=
> -3
>
>   (Un)fortunately, Alex's web page is not working :)
>
>   One more point, it is not required that all multi-level
>   hierarchy protocols must follow DV routing at the higher
>   levels. *Theoretically* one can do hierarchical routing
>   with DV algorithms also.
>
> --
> Venkata
>
> -> This sentence is also fundamentally incorrect.
> ->
> ->    If I said that, "OSPF uses a distance vector
> ->    algorithm for inter-area routes and a link-state protocol
> ->    for intra-area routes vs IS-IS using link-state protocols
> ->    for both",  wouldn't this be the key / most important
> ->    design difference?
> ->


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 24 13:50:17 2002
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 NAA07277
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Sep 2002 13:50:17 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.007371BF@cherry.ease.lsoft.com>; Tue, 24 Sep 2002 13:52:06 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 213283 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 24 Sep 2002 13:52:06 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 24 Sep 2002 13:52:06 -0400
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8OHq5m64745 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 24 Sep 2002 10:52:05 -0700 (PDT)
          (envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id
          g8OHq5O93189; Tue, 24 Sep 2002 10:52:05 -0700 (PDT) (envelope-from
          dkatz@cirrus.juniper.net)
References: <39469E08BD83D411A3D900204840EC5576336C@vie-msgusr-01.dc.fore.com>
            <3D90A3CC.1A99FA7B@earthlink.net>
Message-ID:  <200209241752.g8OHq5O93189@cirrus.juniper.net>
Date:         Tue, 24 Sep 2002 10:52:05 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Dave Katz <dkatz@JUNIPER.NET>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D90A3CC.1A99FA7B@earthlink.net> (message from Erblichs on Tue,
              24 Sep 2002 10:41:32 -0700)
Precedence: list

The DV-ness of these protocols is subtle but there, and the two
protocols work essentially the same way in this respect.

The keystone of a LS algorithm is having a map, and calculating routes
based on the map.  The heart of a DV algorithm is knowing the
destination, a distance to the destination, and a direction to the
destination, but not knowing the paths to get there.

Both protocols use a hybrid in interarea routing; each area advertises
its destinations in some level of detail (from a full route list to a
single summary) but include only the distance, not the path (since the
whole point of areas is to suppress the path information for brevity.)
The nearest ABR/L1L2 router is reached via a LS SPF calculation, but
everything beyond the area boundary is effectively DV, albeit without
some of the failings of classic DV protocols (no holddown or count-to-
infinity, for example.)

   Venkata,

           I am just a little lost..

           Are you suggesting that IS-IS L2 only routers
           do not run a SPF algorithm?

           If you think that then read the Cisco's
           Reference IS-IS chapter
           since you guys don't belive me ...

           My understading is that a IS-IS L1, or L2, or
           L1/L2 routers will build level specific
           link state databases. AND OSPF uses
           "See Cisco's Routing TCP/IP p.475" says it
           uses a distance vector algoritm. Assuming
           that you don't believe me..



           Mitchell Erblich
           ==========================


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 24 15:03:02 2002
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 PAA09201
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Sep 2002 15:03:02 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0073748D@cherry.ease.lsoft.com>; Tue, 24 Sep 2002 15:04:51 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 213486 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 24 Sep 2002 15:04:51 -0400
Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 24 Sep 2002 15:04:50 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id PAA20751 for <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 24 Sep 2002
          15:04:48 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA19867
          for <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 24 Sep 2002 15:04:50 -0400
          (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S8R7GPA7>; Tue, 24 Sep 2002 15:04:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <39469E08BD83D411A3D900204840EC55763371@vie-msgusr-01.dc.fore.com>
Date:         Tue, 24 Sep 2002 15:04:48 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Naidu, Venkata" <Venkata.Naidu@MARCONI.COM>
Subject: Re: Paper comparing OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Mitchell,

->         Are you suggesting that IS-IS L2 only routers
->         do not run a SPF algorithm?

No.

->         If you think that then read the Cisco's
->         Reference IS-IS chapter since you guys don't
->         belive me ...

There is nothing called believing or not believing :)

->         My understading is that a IS-IS L1, or L2, or
->         L1/L2 routers will build level specific
->         link state databases. AND OSPF uses
->         "See Cisco's Routing TCP/IP p.475" says it
->         uses a distance vector algoritm. Assuming
->         that you don't believe me..

I didn't read Cisco's manuals but the answer is in your
response. I can't say that Cisco's manuals are incorrect,
but I can say that the *interpretation* is incorrect.

Yes! L1, L2 or L1/L2 (view it as two logical L1 & L2)
routers build *level specific* link-state database.
The word *level specific* is very important. L1 routers
build its respective LSDB and L2 routers builds its
respective LSDB. But crossing L1's or L2<->L1 routers
(i.e crossing area boundaries) is DV based (or a kind
of DV as Dave pointed out).

-> albeit without some of the failings of classic DV
-> protocols (no holddown or count-to-infinity,
-> for example.)

Those failings of classic DV protocols are solved by
both protocols (OSPF and ISIS) using some *restrictions*
on how to build the hierarchy (like, backbone area must
not be disconnected, split horizon etc etc)

Again, please don't think that we don't believe you.

--
Venkata.


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 24 18:17:27 2002
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 SAA13918
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Sep 2002 18:17:27 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00737998@cherry.ease.lsoft.com>; Tue, 24 Sep 2002 18:19:17 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 214125 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 24 Sep 2002 18:19:17 -0400
Received: from 134.56.3.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 24 Sep 2002 18:09:16 -0400
Received: from unet.net.com (fremont-ns2.net.com [134.56.112.30]) by
          relay1.net.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17068 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 24 Sep 2002 15:05:08 -0700 (PDT)
Received: from west-mail.net.com by unet.net.com (8.9.3/SMI-SVR4) id PAA12377;
          Tue, 24 Sep 2002 15:10:07 -0700 (PDT)
Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging
          Server 3.6)  with ESMTP id AAA3A7F for <OSPF@DISCUSS.MICROSOFT.COM>;
          Tue, 24 Sep 2002 15:09:16 -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:  <3D90E28B.A0099F76@net.com>
Date:         Tue, 24 Sep 2002 15:09:15 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: Question about default route wrt new nssa draft
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi,
 Thanks to Pat,Acee and Manral for answering my previous
 questions.

 I have one more question with respect to ospf-nssa-draft-11,

 Section 2.3:
 ============
 In addition, an NSSA border router should originate a default LSA (IP
 address of 0.0.0.0) into the NSSA.

 Does NSSA ABR should always orginate default LSA or only when
 none of the internal NSSA ASBR doesnt generate default route.
 I read in one of the mails sent by Pat, that

 "By default, all of an NSSA ABRs, such as R4, are expected to
 originate a type 7 LSA for default when none of the NSSA's internal
 such as R5, orignate a Type 7 LSA for default"

 If NSSA ABR and NSSA ASBR both orginate a type-7 default in to
 NSSA, which will one be considered while calculating routes.I havent
 tested this scenario, but curious to know how it is handled.

Thanks in advace,
-Mani


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Sep 24 22:20:57 2002
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 WAA18362
	for <ospf-archive@LISTS.IETF.ORG>; Tue, 24 Sep 2002 22:20:56 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00737E1B@cherry.ease.lsoft.com>; Tue, 24 Sep 2002 22:22:46 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 214469 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 24 Sep 2002 22:22:45 -0400
Received: from 134.56.3.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 24 Sep 2002 22:12:45 -0400
Received: from isis.net.com (fremont-ns1.net.com [134.56.112.20]) by
          relay1.net.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12030 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 24 Sep 2002 19:08:38 -0700 (PDT)
Received: from west-mail.net.com by isis.net.com (8.9.3/SMI-SVR4) id TAA22246;
          Tue, 24 Sep 2002 19:13:37 -0700 (PDT)
Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging
          Server 3.6)  with ESMTP id AAAEAB for <OSPF@DISCUSS.MICROSOFT.COM>;
          Tue, 24 Sep 2002 19:12:46 -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:  <3D911B9C.97169E00@net.com>
Date:         Tue, 24 Sep 2002 19:12:44 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: NSSA address-range external route-tag option
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi,
  RFC1587 says the NSSA address-range
  inclues "external-route tag" as configurable option.

  What does this option is used for?

Thanks in advance,
Mani


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 25 01:21:28 2002
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 BAA22019
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 Sep 2002 01:21:28 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.007385B6@cherry.ease.lsoft.com>; Wed, 25 Sep 2002 1:23:19 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 214947 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 25 Sep 2002 01:23:19 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 25 Sep 2002 01:23:18 -0400
Received: from redback.com (login001.redback.com [155.53.12.18]) by
          prattle.redback.com (Postfix) with ESMTP id 19A0E1DCC73 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 24 Sep 2002 22:23:17 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D911B9C.97169E00@net.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D914848.5000700@redback.com>
Date:         Wed, 25 Sep 2002 01:23:20 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: NSSA address-range external route-tag option
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Mani Devarajan wrote:

> Hi,
>   RFC1587 says the NSSA address-range
>   inclues "external-route tag" as configurable option.

 >
 >   What does this option is used for?


To allow specification of the AS External Tag for the
translated type 5 LSA corresponding to the NSSA range.
Section A.4.5 in RFC 2328 describes the format of
type 5 LSAs.

If an AS external and NSSA LSAs results in the installation
of a route, the AS External Tag can be associated with
the installed route and used for implementing routing polices.


>
> Thanks in advance,
> Mani
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 25 14:23:13 2002
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 OAA05557
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 Sep 2002 14:23:13 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0073967B@cherry.ease.lsoft.com>; Wed, 25 Sep 2002 14:24:58 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 218865 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 25 Sep 2002 14:24:58 -0400
Received: from 216.136.174.182 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 25 Sep 2002 14:14:58 -0400
Received: from [64.60.75.66] by web13114.mail.yahoo.com via HTTP; Wed, 25 Sep
          2002 11:14:56 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020925181456.55158.qmail@web13114.mail.yahoo.com>
Date:         Wed, 25 Sep 2002 11:14:56 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: ospf RFC <ospfv32002@YAHOO.COM>
Subject: OSPFv3: Size of metric of Inter-Area-Prefix-LSA?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi,
Can anybody tell me what are the size of the metric
field of Inter-Area-Prefix-LSA and
Inter-Area-Router-LSA ? I am confused after
the picture of Inter-Area-Prefix-LSA and
Inter-Area-Router-LSA in page 65/66 of RFC2740.

Pingla

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 25 18:43:32 2002
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 SAA12183
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 Sep 2002 18:43:32 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0073A061@cherry.ease.lsoft.com>; Wed, 25 Sep 2002 18:45:23 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 207949 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 25 Sep 2002 18:45:22 -0400
Received: from 129.188.136.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 25 Sep 2002 18:45:22 -0400
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA24934 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 25 Sep 2002 14:20:28 -0700 (MST)]
Received: [from az33exm05.corp.mot.com (az33exm05.corp.mot.com [199.2.84.25])
          by mothost.mot.com (MOT-pobox 2.0) with ESMTP id OAA22815 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 25 Sep 2002 14:20:27 -0700 (MST)]
Received: by az33exm05.corp.mot.com with Internet Mail Service (5.5.2654.52) id
          <S79H1LLN>; Wed, 25 Sep 2002 14:20:27 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain
Message-ID:  <7FD24C15A06DD511BF9E00D0B73E99520336A72D@az33exm05.corp.mot.com>
Date:         Wed, 25 Sep 2002 14:20:22 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Boffa Stephen-QA4741 <boffa@MOTOROLA.COM>
Subject: poll-interval clarification of section 9.5.1 of RFC 2328
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Once again thanks for the response on implementing (or not implementing) a poll-interval as a non-eligible router in a NBMA configuration.  We re-read section 9.5.1 of the RFC and the last paragraph as read appears to contradict the suggested implementation.

>>> last paragraph of 9.5.1


            When sending Hello packets periodically to any neighbor, the
            interval between Hello Packets is determined by the
            neighbor's state.  If the neighbor is in state Down, Hello
            Packets are sent every PollInterval seconds.  Otherwise,
            Hello Packets are sent every HelloInterval seconds.

>>> end of paragraph.

If we paraphrase this paragraph, it appears to state that hello packets between neighbors are sent at the hello-interval pace when full adjacencies are established or at poll-interval pace when a neighbor is determined as down.  This paragraph does not tend to dedicate itself to a DR, BDR, or a non-eligible router.  Which gives us the impression that a poll-interval should be used on a non-eligible router as well as on an eligible router in a NBMA configuration.

Any advice would be helpful.

Thanks
Steve

-----Original Message-----
From: Acee Lindem [mailto:acee@REDBACK.COM]
Sent: Thursday, September 19, 2002 6:29 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: clarification of section 9.5.1 of RFC 2328


Boffa Stephen-QA4741 wrote:

> Acee,
>
> Thanks for your response.  A question which stems from your response of "If the DR or BDR neighbor state goes to DOWN, the non-eligible router discontinues sending hellos to
> that neighbor.".  Does this statement implies that the poll-interval set on the non-eligible router is irrelevant on the non-eligible router?  In otherwords, the non-eligible router should not try to re-establish bi-directional communications with its DR or BDR (as defined in a poll-interval) if the DR or BDR is perceived as down (per the non-eligible router not receiving dead-interval worth of heartbeat responses).
>


Yes - At least that is the way I interpreted and implemented it.


> Regards
> Steve
>
> -----Original Message-----
> From: Acee Lindem [mailto:acee@REDBACK.COM]
> Sent: Thursday, September 19, 2002 3:45 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: clarification of section 9.5.1 of RFC 2328
>
>
> Boffa Stephen-QA4741 wrote:
>
>
>>>We have two interpretations of section 9.5.1 (Sending Hello Packets on NBMA networks) of RFC 2328 from the perspective of being a non-eligible DR.  We are configured as a NBMA which we can not be eligible to be the DR.  Our issue involves the initiation of hello packets when we start-up.  The two interpretations are:
>>>
>>>1) The non-eligible NBMA router (which is our environment), will initiate a hello packet to our direct neighbor on each interface.  After the initial exchange and adjacencies are established, hello packets are exchanged every hello-interval.
>>>
>>>2)  Upon startup, no BDR or DR is elected so HELLOs are not sent to any router. The DR election is first triggered by *receipt* of HELLOs from the DR or BDR, which are sending HELLOs at PollInterval intervals because the NBMA router has reached the Down state.
>>>
>>>
>
>
> #2 is the closest.
>
> When non-eligible router starts up, it does not send hellos to anyone. Once a DR and BDR
> are elected and poll the non-eligible router, it will send hellos to them.
> It also replies to hellos as specified in section 9.5.1. If the DR or BDR neighbor
> state goes to DOWN, the non-eligible router discontinues sending hellos to
> that neighbor.
>
> I suspect you will find a wide variance in what individual implementations
> do with respect to non-eligible neighbors.
>
>
>
>>>Any clarification on this case would help us in our implementation.
>>>
>>>Thanks for your assistance.
>>>Steve
>>>
>>>
>
>
> --
> Acee
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 25 19:55:16 2002
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 TAA13276
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 Sep 2002 19:55:16 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00739EEE@cherry.ease.lsoft.com>; Wed, 25 Sep 2002 19:57:07 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 208085 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 25 Sep 2002 19:57:06 -0400
Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 25 Sep 2002 19:57:06 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA05992;
          Wed, 25 Sep 2002 16:57:05 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id g8PNv4S23015; Wed, 25 Sep 2002 16:57:04
          -0700
X-mProtect: <200209252357> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.19.66.85,
          claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com
          smtpdQ0m8IP; Wed, 25 Sep 2002 16:57:02 PDT
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <3D91A3BE.2070904@6wind.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D924D4D.35EBF621@iprg.nokia.com>
Date:         Wed, 25 Sep 2002 16:57:02 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mukesh Gupta <mgupta@IPRG.NOKIA.COM>
Organization: Nokia
Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt
Comments: To: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
Comments: cc: ipsec@lists.tislabs.com, nmelam@iprg.nokia.com
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Jean-Mickael,

Thanks for the correction. You are right. Word OSPF needs to be removed from
there. The new sentence should be
"In the incoming path, protocol, SPI and ingress interface ID MUST be used
to locate the SA to be applied."
where the protocol can be ESP or AH.

Check against the inbound policy linked to the SA should be done by the
general IPsec implementation. I don't see anything that needs to be handled
differently for OSPFv3. So, I think, we don't need to add anything about it
in this draft.

I will make the suggested correction in the next version of the draft.

Cheers.
Mukesh

Jean-Mickael Guerin wrote:

> Hello,
> I have a question concerning SA granularity. The draft says:
> In the incoming path, OSPF protocol, SPI and ingress interface ID MUST
> be used to locate the SA to be applied.
> If ESP is used with non-null encryption, I think that OSPF protocol
> field is not available.
> If 'm correct, I think in this case we can only use SPI and ingress
> interface. If  incoming packet is decrypted correctly, then we can check
> against an inbound policy linked to this SA, which would have protocol
> selector set to OSPF protocol.
>
> Regards,
>
> Jean-Mickael

--
******************************************************************
Work fascinates me. I can look at it for  hours !
******************************************************************
Mukesh Gupta
Phone: (650) 625-2264
Cell : (650) 868-9111
http://www.iprg.nokia.com/~mgupta
******************************************************************


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Sep 25 21:21:56 2002
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 VAA14662
	for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 Sep 2002 21:21:56 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0073A13F@cherry.ease.lsoft.com>; Wed, 25 Sep 2002 21:23:46 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 208350 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 25 Sep 2002 21:23:46 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 25 Sep 2002 21:23:44 -0400
Received: from redback.com (login002.redback.com [155.53.12.54]) by
          prattle.redback.com (Postfix) with ESMTP id 0BF6FF2C43 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 25 Sep 2002 18:23:43 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <7FD24C15A06DD511BF9E00D0B73E99520336A72D@az33exm05.corp.mot.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D926197.7070507@redback.com>
Date:         Wed, 25 Sep 2002 21:23:35 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: poll-interval clarification of section 9.5.1 of RFC 2328
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Boffa Stephen-QA4741 wrote:

> Once again thanks for the response on implementing (or not implementing) a poll-interval as a non-eligible router in a NBMA configuration.  We re-read section 9.5.1 of the RFC and the last paragraph as read appears to contradict the suggested implementation.
>
>
>>>>last paragraph of 9.5.1
>>>>
>
>
>             When sending Hello packets periodically to any neighbor, the
>             interval between Hello Packets is determined by the
>             neighbor's state.  If the neighbor is in state Down, Hello
>             Packets are sent every PollInterval seconds.  Otherwise,
>             Hello Packets are sent every HelloInterval seconds.


Steve,

It needn't be repeated in this paragraph since the requirements for
sending hello packets on NBMA interfaces are stated in a subsequent
paragraph:

             If the router is eligible to become Designated Router, it
             must periodically send Hello Packets to all neighbors that
             are also eligible.  In addition, if the router is itself the
             Designated Router or Backup Designated Router, it must also
             send periodic Hello Packets to all other neighbors.  This
             means that any two eligible routers are always exchanging
             Hello Packets, which is necessary for the correct operation
             of the Designated Router election algorithm.  To minimize
             the number of Hello Packets sent, the number of eligible
             routers on an NBMA network should be kept small.

Also, if you look at appendix C.5 (NBMA network parameters) you'll
note that it suggests that neighbor configuration or automatic discovery
is only necessary on routers that are eligible to become designated
router (DR).



>
>
>>>>end of paragraph.
>>>>
>
> If we paraphrase this paragraph, it appears to state that hello packets between neighbors are sent at the hello-interval pace when full adjacencies are established or at poll-interval pace when a neighbor is determined as down.  This paragraph does not tend to dedicate itself to a DR, BDR, or a non-eligible router.  Which gives us the impression that a poll-interval should be used on a non-eligible router as well as on an eligible router in a NBMA configuration.
>
> Any advice would be helpful.
>
> Thanks
> Steve
>
> -----Original Message-----
> From: Acee Lindem [mailto:acee@REDBACK.COM]
> Sent: Thursday, September 19, 2002 6:29 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: clarification of section 9.5.1 of RFC 2328
>
>
> Boffa Stephen-QA4741 wrote:
>
>
>>Acee,
>>
>>Thanks for your response.  A question which stems from your response of "If the DR or BDR neighbor state goes to DOWN, the non-eligible router discontinues sending hellos to
>>that neighbor.".  Does this statement implies that the poll-interval set on the non-eligible router is irrelevant on the non-eligible router?  In otherwords, the non-eligible router should not try to re-establish bi-directional communications with its DR or BDR (as defined in a poll-interval) if the DR or BDR is perceived as down (per the non-eligible router not receiving dead-interval worth of heartbeat responses).
>>
>>
>
>
> Yes - At least that is the way I interpreted and implemented it.
>
>
>
>>Regards
>>Steve
>>
>>-----Original Message-----
>>From: Acee Lindem [mailto:acee@REDBACK.COM]
>>Sent: Thursday, September 19, 2002 3:45 PM
>>To: OSPF@DISCUSS.MICROSOFT.COM
>>Subject: Re: clarification of section 9.5.1 of RFC 2328
>>
>>
>>Boffa Stephen-QA4741 wrote:
>>
>>
>>
>>>>We have two interpretations of section 9.5.1 (Sending Hello Packets on NBMA networks) of RFC 2328 from the perspective of being a non-eligible DR.  We are configured as a NBMA which we can not be eligible to be the DR.  Our issue involves the initiation of hello packets when we start-up.  The two interpretations are:
>>>>
>>>>1) The non-eligible NBMA router (which is our environment), will initiate a hello packet to our direct neighbor on each interface.  After the initial exchange and adjacencies are established, hello packets are exchanged every hello-interval.
>>>>
>>>>2)  Upon startup, no BDR or DR is elected so HELLOs are not sent to any router. The DR election is first triggered by *receipt* of HELLOs from the DR or BDR, which are sending HELLOs at PollInterval intervals because the NBMA router has reached the Down state.
>>>>
>>>>
>>>>
>>
>>#2 is the closest.
>>
>>When non-eligible router starts up, it does not send hellos to anyone. Once a DR and BDR
>>are elected and poll the non-eligible router, it will send hellos to them.
>>It also replies to hellos as specified in section 9.5.1. If the DR or BDR neighbor
>>state goes to DOWN, the non-eligible router discontinues sending hellos to
>>that neighbor.
>>
>>I suspect you will find a wide variance in what individual implementations
>>do with respect to non-eligible neighbors.
>>
>>
>>
>>
>>>>Any clarification on this case would help us in our implementation.
>>>>
>>>>Thanks for your assistance.
>>>>Steve
>>>>
>>>>
>>>>
>>
>>--
>>Acee
>>
>>
>>
>
>
> --
> Acee
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 26 10:12:49 2002
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 KAA08527
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 26 Sep 2002 10:12:49 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0073B4E0@cherry.ease.lsoft.com>; Thu, 26 Sep 2002 10:14:39 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 210372 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 26 Sep 2002 10:14:38 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 26 Sep 2002 10:14:38 -0400
Received: from redback.com (login001.redback.com [155.53.12.18]) by
          prattle.redback.com (Postfix) with ESMTP id 8298F1DCC79 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 26 Sep 2002 07:14:37 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D90E28B.A0099F76@net.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D93163E.2090809@redback.com>
Date:         Thu, 26 Sep 2002 10:14:22 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Question about default route wrt new nssa draft
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Mani,

Mani Devarajan wrote:

> Hi,
>  Thanks to Pat,Acee and Manral for answering my previous
>  questions.
>
>  I have one more question with respect to ospf-nssa-draft-11,
>
>  Section 2.3:
>  ============
>  In addition, an NSSA border router should originate a default LSA (IP
>  address of 0.0.0.0) into the NSSA.
>
>  Does NSSA ABR should always orginate default LSA or only when
>  none of the internal NSSA ASBR doesnt generate default route.


Follow draft-ietf-ospf-nssa-update-11.txt.
Excepted from section 2.3:

    In addition, an NSSA border router should originate a default LSA (IP
    address of 0.0.0.0) into the NSSA.  Default routes are necessary
    because NSSAs do not receive full routing information and must have a
    default route in order to route to AS-external destinations.  Like
    stub areas, NSSAs may be connected to the backbone at more than one
    area border router, but may not be used as a transit area.  Note that
    a Type-7 default route originated by an NSSA border router is never
    translated into a Type-5 LSA, however, a Type-7 default route
    originated by an NSSA internal AS boundary router (one that is not
    also an area border router) may be translated into a Type-5 LSA.

Also note that many implementations make it configurable as to whether
or not an NSSA ABR will originate a type 7 default.


>  I read in one of the mails sent by Pat, that
>
>  "By default, all of an NSSA ABRs, such as R4, are expected to
>  originate a type 7 LSA for default when none of the NSSA's internal
>  such as R5, orignate a Type 7 LSA for default"


This is incorrect.


>
>  If NSSA ABR and NSSA ASBR both orginate a type-7 default in to
>  NSSA, which will one be considered while calculating routes.I havent
>  tested this scenario, but curious to know how it is handled.


There are a number of cases here. The best is too follow section 3.5 in
draft-ietf-ospf-nssa-update-11.txt. In short,  routers internal to
the NSSA will install the default route with the lowest cost. NSSAs ABRs
will not install type 7 default unless the P bit is set in the LSA
options.


>
> Thanks in advace,
> -Mani
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Sep 26 23:33:34 2002
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 XAA00112
	for <ospf-archive@LISTS.IETF.ORG>; Thu, 26 Sep 2002 23:33:34 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0073D151@cherry.ease.lsoft.com>; Thu, 26 Sep 2002 23:35:24 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 212418 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 26 Sep 2002 23:35:23 -0400
Received: from 134.56.3.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 26 Sep 2002 23:25:23 -0400
Received: from unet.net.com (fremont-ns2.net.com [134.56.112.30]) by
          relay1.net.com (8.9.3+Sun/8.9.3) with ESMTP id UAA27550 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 26 Sep 2002 20:21:16 -0700 (PDT)
Received: from west-mail.net.com by unet.net.com (8.9.3/SMI-SVR4) id UAA22861;
          Thu, 26 Sep 2002 20:26:16 -0700 (PDT)
Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging
          Server 3.6)  with ESMTP id AAA542A for <OSPF@DISCUSS.MICROSOFT.COM>;
          Thu, 26 Sep 2002 20:25:25 -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:  <3D93CFA3.3F045A63@net.com>
Date:         Thu, 26 Sep 2002 20:25:23 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: Question about choosing forwarding address for type-7 LSAs
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi all,
 draft-ietf-ospf-nssa-update-11.txt
  Section 3.3:

  * "If internal addresses are not available, preference
   should be given to the router's active OSPF stub network addresses to
   avoid the possible extra hop of a transit network's address."

   I am not able to understand why ospf stub interface is
   given preference to type-5 or NSSA interface when loopback is
   not available. Or does stub means it also inclues NSSA network
address
   in this case.

   It would be great if someone could share more information
   on this point.
Thanks in advance,
-Mani


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Sep 27 13:15:53 2002
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 NAA00746
	for <ospf-archive@LISTS.IETF.ORG>; Fri, 27 Sep 2002 13:15:53 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0073E84B@cherry.ease.lsoft.com>; Fri, 27 Sep 2002 13:17:44 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 214445 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 27 Sep 2002 13:17:44 -0400
Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 27 Sep 2002 13:17:44 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA29041;
          Fri, 27 Sep 2002 10:17:42 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id g8RHHeU27358; Fri, 27 Sep 2002 10:17:40
          -0700
X-mProtect: <200209271717> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.19.66.85,
          claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com
          smtpd2LzYkM; Fri, 27 Sep 2002 10:17:39 PDT
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <amuomc$a8h$1@intranet.6wind.com> <3D941441.2030307@6wind.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D9492B3.321113E0@iprg.nokia.com>
Date:         Fri, 27 Sep 2002 10:17:39 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mukesh Gupta <mgupta@IPRG.NOKIA.COM>
Organization: Nokia
Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt
Comments: To: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
Comments: cc: itojun@iijlab.net, ipsec@lists.tislabs.com, nmelam@iprg.nokia.com
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Are you suggesting that we should make the draft generic to all such protocols
instead of being specific to OSPFv3 ??

Jean-Mickael Guerin wrote:

> Finally I think that this way to secure ospfv3 can be applied to other
> protocols that exchange both multicast and unicast packets. I mean that
> for example we can do the same for RIPng. Just need to replace OSPF
> protocol 89 with RIPng/UDP port 521.
> The requirement is just on incoming path since destination address is
> ignored, use static keys, and as Itojun said, SPD aware of link-local
> scope. May be reserved SPI can be recommanded to facilate configuration.
>
> Furthermore I beleive it works for NDP, as far as SPD selectors can
> permit it (e.g. protocol ICMPv6, type=neighbor solicit). But the
> scenario must support the assumption that hosts can share a key.
>
> Regards,
>
> Jean-Mickael
>
> itojun@iijlab.net wrote:
>
> >>Thanks for the correction. You are right. Word OSPF needs to be removed from
> >>there. The new sentence should be
> >>"In the incoming path, protocol, SPI and ingress interface ID MUST be used
> >>to locate the SA to be applied."
> >>where the protocol can be ESP or AH.
> >>
> >
> >       is there any need for documenting it?  i mean, this is exactly
> >       the same as normal IPsec processing.  i think dropping the descrption
> >       and pointing people to ipsec document is the right thing to do.
> >       (the tricky thing is that you need to be aware of link-local scopes,
> >       which may be worth documenting)
> >
> > itojun
> >
> >
>
> --
>
> Jean-Mickael GUERIN
> Tel : +33 1 39 30 92 33
> Web site : www.6wind.com

--
******************************************************************
Your attitude is more important than your aptitude in determining your altitude.
******************************************************************
Mukesh Gupta
Phone: (650) 625-2264
Cell : (650) 868-9111
http://www.iprg.nokia.com/~mgupta
******************************************************************


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 30 01:44:39 2002
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 BAA15240
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Sep 2002 01:44:39 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00744175@cherry.ease.lsoft.com>; Mon, 30 Sep 2002 1:46:29 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 220568 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 30 Sep 2002 01:46:29 -0400
Received: from 195.58.103.125 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 30 Sep 2002 01:46:28 -0400
Received: from utfors.se (nat-sto.utfors.se [212.73.0.237]) by
          blooper.utfors.se (8.12.6/8.12.6) with ESMTP id g8U5kRtA012847; Mon,
          30 Sep 2002 07:46:27 +0200 (MEST)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1)
            Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <3D6DBFBE.4050603@utfors.se> <3D7CC9FF.6010509@utfors.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-MIME-Autoconverted: from 8bit to quoted-printable by blooper.utfors.se id
                      g8U5kRtA012847
Message-ID:  <3D97E533.2020107@utfors.se>
Date:         Mon, 30 Sep 2002 07:46:27 +0200
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Loa Andersson <loa.andersson@UTFORS.SE>
Subject: Last Call: draft-ietf-mpls-bundle-04.txt - has ended
Comments: To: isis-wg <isis-wg@ietf.org>
Comments: cc: MPLS wg <mpls@uu.net>
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA15240

All,

the last call on the

<draft-ietf-mpls-bundle-04.txt>

on the ospf and isis list has ended. Thanks for comments.

/Loa

Loa Andersson wrote:
> All,
> 
> it is my understanding that there has been some hick-ups on
> the is-is list, so I'm re-issueing this last call and extending
> the time to September 29th. At the same time I would like point out
> that there is an acompanying mib draft-ietf-mpls-bundle-mib-03.txt.
> 
> Also comments on the mib is welcome.
> 
> BTW, thanks to those of you who already sent us comments :)
> 
> The wg last call on
> 
>  <draft-ietf-mpls-bundle-04.txt>
>  <draft-ietf-mpls-bundle-mib-03.txt>
> 
> has been extended to September 29.
> 
> /Loa
> 
> Loa Andersson wrote:
> 
>> OSPF and IS-IS working groups, (mpls wg for info)
>>
>> the iesg has started the review of the mpls working group draft
>> draft-ietf-mpls-bundle-04.txt. The immediate response from the iesg
>> is that the draft contains OSPF and ISIS related details (see
>> the included mail). After discussing with the wg chairs for ospf
>> and is-is working groups, there is a feeling that the two weeks
>> the iesg allocated for this last call might not be enough, since the
>> draft has not been widely circulated in the routing working groups.
>>
>> Therefore:
>>
>> This is to initiate a last call for the
>>
>> <draft-ietf-mpls-bundle-04.txt>
>>
>> by the ospf and is-is working groups.
>> The last call ends September 22nd at 12PM CET
>>
>>
>> Please include the mpls mailing list (mpls@uu.net) in your responses.
>>
>> /Loa (co-chair of the mpls wg)
>>
>> -------- Original Message --------
>> Subject: draft-ietf-mpls-bundle-04.txt
>> Date: Tue, 27 Aug 2002 15:06:48 -0400 (EDT)
>> From: Scott Bradner
>> To: loa.andersson@utfors.se, swallow@cisco.com
>>
>>
>> The IESG discussed this ID last week during its teleconference
>> one issue was raised during the discussion
>>
>> "the draft contains OSPF & ISIS
>> related details and I don't remember it being LC'ed or reviewed
>> in the corresponding WGs."
>>
>> can you start a 2 week last call on the IS-IS and OSPF mailing
>> lists for this document?
>>
>> Scott
>>
> 
> 


-- 
     Loa Andersson
     Chief Architect,
     Utfors Research, Architecture and Future Lab (URAX)
     Utfors AB
     Råsundavägen 12
     Box 525, 169 29 Solna
     Office          +46 8 5270 2000
     Office direct   +46 8 5270 5038
     Mobile          +46 70 848 5038
     Email           loa.andersson@utfors.se
     WWW             www.utfors.se


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 30 03:19:30 2002
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 DAA25583
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Sep 2002 03:19:30 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0074439E@cherry.ease.lsoft.com>; Mon, 30 Sep 2002 3:21:25 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 221138 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 30 Sep 2002 03:21:26 -0400
Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 30 Sep 2002 03:11:25 -0400
Received: from kailash.future.futsoft.com (unverified) by
          fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with
          ESMTP id <B0003346256@fsnt.future.futsoft.com> for
          <OSPF@discuss.microsoft.com>; Mon, 30 Sep 2002 12:42:06 +0530
Received: from rajendrapb (rajendrapb.future.futsoft.com [10.4.3.14]) by
          kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id
          g8U7BlYf019461 for <OSPF@discuss.microsoft.com>; Mon, 30 Sep 2002
          12:41:47 +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.2615.200
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID:  <000201c26850$5fbba2c0$0e03040a@future.futsoft.com>
Date:         Mon, 30 Sep 2002 12:39:52 +0530
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Rajendra Prasad B <rajendrapb@FUTURE.FUTSOFT.COM>
Subject: Implementation of Opaque LSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi all,

I am looking for an implementation of Opaque LSAs in OSPF.

Could someone tell me where I would be able to get the code for this?

Thanks in advance

Regards
Rajendra Prasad
***************************************************************************
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@DISCUSS.MICROSOFT.COM  Mon Sep 30 04:06:15 2002
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 EAA26191
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Sep 2002 04:06:14 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00744521@cherry.ease.lsoft.com>; Mon, 30 Sep 2002 4:08:09 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 221310 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 30 Sep 2002 04:08:09 -0400
Received: from 194.250.197.211 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 30 Sep 2002 04:08:06 -0400
Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com
          (Postfix) with ESMTP id B0357450; Mon, 30 Sep 2002 10:13:42 +0200
          (CEST)
Received: from 6wind.com (unknown [10.16.0.239]) by intranet.6wind.com
          (Postfix) with ESMTP id 2050BB4FA; Mon, 30 Sep 2002 10:04:06 +0200
          (CEST)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1)
            Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000201c26850$5fbba2c0$0e03040a@future.futsoft.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D98074D.50205@6wind.com>
Date:         Mon, 30 Sep 2002 10:11:57 +0200
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Vincent Jardin <jardin@6WIND.COM>
Subject: Re: Implementation of Opaque LSA
Comments: cc: Rajendra Prasad B <rajendrapb@FUTURE.FUTSOFT.COM>
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi,

You should check the Zebra's OSPFv2 support (www.zebra.org). It looks
like there is a support of the OSPF's opaque. However I do not know if
it works. There is a Zebra's OSPF API that allows other applications to
obtain the LSDB from the Zebra's OSPF daemon on
http://www.tik.ee.ethz.ch/~keller/ospfapi/

Moreover, the John Moy's OSPFd release 2.0 supports the opaque LSAs, see
http://www.ospf.org/ospfd2_0/

I hope it helps,
 Vincent

Rajendra Prasad B wrote:

>Hi all,
>
>I am looking for an implementation of Opaque LSAs in OSPF.
>
>Could someone tell me where I would be able to get the code for this?
>
>Thanks in advance
>
>Regards
>Rajendra Prasad
>***************************************************************************
>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@DISCUSS.MICROSOFT.COM  Mon Sep 30 11:03:01 2002
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 LAA06862
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Sep 2002 11:03:01 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00746F25@cherry.ease.lsoft.com>; Mon, 30 Sep 2002 11:04:56 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 225575 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 30 Sep 2002 11:04:56 -0400
Received: from 202.54.124.145 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 30 Sep 2002 10:54:55 -0400
Received: (qmail 28757 invoked by uid 510); 30 Sep 2002 14:59:56 -0000
Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 30 Sep 2002
          14:59:56 -0000
MIME-Version: 1.0
Content-type: text/plain; format=flowed
Content-Disposition: inline
Message-ID:  <20020930145956.28756.qmail@webmail30.rediffmail.com>
Date:         Mon, 30 Sep 2002 14:59:56 -0000
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Raghu BK Sham <raghubksham@REDIFFMAIL.COM>
Subject: OSPF and ISIS
Comments: cc: isis-wg@ietf.org
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi,
Which is a better protocol to be used as an IGP today and what are
the factors which one should look into when selecting one over the
other.

I am basically unclear as to what the difference is between these
two protocols. Both have a DR concept on LAN, both are link state,
both need to have complete topology of the network to calculate
the best routes, both use SPF for this, etc .. etc .. etc.

I have gone through some previous (at times heated!) discussions
on the mailing lists in the past but could not find any
authoratative answer.

Any help in this regard will be appreciated.

Regards,
Raghu

__________________________________________________________
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 30 11:20:17 2002
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 LAA07479
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Sep 2002 11:20:16 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00746F7B@cherry.ease.lsoft.com>; Mon, 30 Sep 2002 11:22:12 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 225648 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 30 Sep 2002 11:22:11 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 30 Sep 2002 11:12:10 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id LAA07102; Mon, 30 Sep 2002 11:10:14
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200209301510.LAA07102@ietf.org>
Date:         Mon, 30 Sep 2002 11:10:14 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.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-08.txt
To: OSPF@DISCUSS.MICROSOFT.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-08.txt
        Pages           : 14
        Date            : 2002-9-27

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-08.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-08.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-08.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:     <2002-9-27131812.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID:     <2002-9-27131812.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 30 11:31:12 2002
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 LAA08137
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Sep 2002 11:31:12 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00747048@cherry.ease.lsoft.com>; Mon, 30 Sep 2002 11:33:07 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 225680 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 30 Sep 2002 11:33:07 -0400
Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 30 Sep 2002 11:23:06 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <EB5FFC72F183D411B38200062957342902A7446B@r2d2.axiowave.com>
Date:         Mon, 30 Sep 2002 11:22:57 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Jeff Parker <jparker@AXIOWAVE.COM>
Subject: Re: OSPF and ISIS
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

> Which is a better protocol to be used as an IGP today
>
> I have gone through some previous (at times heated!) discussions
> on the mailing lists in the past but could not find any
> authoratative answer.

Perhaps there is a reason why there hasn't been an
authoritative answer.  The fact that there have been
heated and inconclusive debates in the past is probably
a good predictor of future activity.

If you are interested in learning about the differences,
rather than trying to provoke debate, you can find
references in the previous mail to Dave Katz's NANOG
presentation and to John Moy's and Radia Perlman's
books, both of which spend some time comparing the
protocols.

- jeff parker
- axiowave networks


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 30 15:49:16 2002
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 PAA19082
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Sep 2002 15:49:16 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00747AB1@cherry.ease.lsoft.com>; Mon, 30 Sep 2002 15:51:12 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 227293 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 30 Sep 2002 15:51:12 -0400
Received: from 192.75.23.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 30 Sep 2002 15:41:12 -0400
Received: (qmail 10718 invoked from network); 30 Sep 2002 19:42:38 -0000
Received: (ofmipd 127.0.0.1); 30 Sep 2002 19:42:16 -0000
Received: from alcatel.com ([138.120.51.127]) by kanmail01.ca.newbridge.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA1AC4; Mon, 30 Sep
          2002 15:41:08 -0400
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <200209301510.LAA07102@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D98A8D3.9F2204DD@alcatel.com>
Date:         Mon, 30 Sep 2002 15:41:07 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: KENDALL HARVEY <Kendall.Harvey@ALCATEL.COM>
Organization: Alcatel
Subject: Re: I-D ACTION:draft-katz-yeung-ospf-traffic-08.txt
Comments: cc: dkatz@juniper.net, myeung@procket.com, kireeti@juniper.net
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

One quick (and obvious) comment - the instance field in section 2.2 is 24 bits in length,
while the instance field shown in section 2.3.1 is only 16 bits.  The reserved field should
be removed and the instance field should be expanded to 24 bits in section 2.3.1.

Kendall Harvey

Internet-Drafts@IETF.ORG wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.
>
>         Title           : Traffic Engineering Extensions to OSPF Version 2
>         Author(s)       : D. Katz, D. Yeung, K. Kompella
>         Filename        : draft-katz-yeung-ospf-traffic-08.txt
>         Pages           : 14
>         Date            : 2002-9-27
>
> 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-08.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-08.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-08.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>   ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <2002-9-27131812.I-D@ietf.org>


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 30 16:11:00 2002
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 QAA19658
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Sep 2002 16:11:00 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00747C5A@cherry.ease.lsoft.com>; Mon, 30 Sep 2002 16:12:56 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 227402 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 30 Sep 2002 16:12:56 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 30 Sep 2002 16:12:56 -0400
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8UKCtm70670 for
          <ospf@discuss.microsoft.com>; Mon, 30 Sep 2002 13:12:55 -0700 (PDT)
          (envelope-from kireeti@juniper.net)
Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id
          g8UKCtx69689 for ospf@discuss.microsoft.com; Mon, 30 Sep 2002
          13:12:55 -0700 (PDT) (envelope-from kireeti)
Message-ID:  <200209302012.g8UKCtx69689@kummer.juniper.net>
Date:         Mon, 30 Sep 2002 13:12:55 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Kireeti Kompella <kireeti@JUNIPER.NET>
Subject: update of te doc
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi All,

A new version (draft-katz-yeung-ospf-traffic-08.txt) of the TE doc was
just posted.  One typo has already been pointed out: the LSA ID in
section 2.2 is correct, but it's wrong in section 2.3.1 -- the Instance
field is now 24 bits (thanks, Harvey!).

I've asked the ADs to start a WG Last Call on this doc, as it's now
pretty much fully baked (except for the above typo).  Please send in
your comments to this list.

Thanks,
Kireeti.


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 30 16:31:26 2002
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 QAA20300
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Sep 2002 16:31:26 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00747E3C@cherry.ease.lsoft.com>; Mon, 30 Sep 2002 16:33:23 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 227530 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 30 Sep 2002 16:33:23 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 30 Sep 2002 16:33:22 -0400
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8UKXFm72716; Mon,
          30 Sep 2002 13:33:15 -0700 (PDT) (envelope-from kireeti@juniper.net)
Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id
          g8UKXEU69783; Mon, 30 Sep 2002 13:33:14 -0700 (PDT) (envelope-from
          kireeti)
Message-ID:  <200209302033.g8UKXEU69783@kummer.juniper.net>
Date:         Mon, 30 Sep 2002 13:33:14 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Kireeti Kompella <kireeti@JUNIPER.NET>
Subject: GMPLS OSPF doc
Comments: cc: bwijnen@lucent.com, fenner@research.att.com,
          john.moy@sycamorenet.com, ronald.p.bonica@wcom.com, sob@harvard.edu,
          zinin@psg.com
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi All,

draft-ietf-ccamp-ospf-gmpls-extensions-08.txt (OSPF Extensions in
Support of Generalized MPLS) has been Last Called in the CCAMP WG.

Please review this document, which basically describes the formats
in OSPFv2 for the GMPLS extensions to the Traffic Engineering TLVs.

Note: the functional spec for the above is in
draft-ietf-ccamp-gmpls-routing-05.txt (Routing Extensions in Support
of Generalized MPLS).  This would provide the background and motivation
for these extensions.  A companion document for ISIS is in
draft-ietf-isis-gmpls-extensions-14.txt, in case that is of interest.

This email is an informal Last Call for this document; the comment
period ends Monday Oct 14, 2002, 1700 EDT (EST?)

Thanks,
Kireeti.


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 30 17:20:43 2002
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 RAA21902
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Sep 2002 17:20:43 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0074800C@cherry.ease.lsoft.com>; Mon, 30 Sep 2002 17:22:38 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 227678 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 30 Sep 2002 17:22:38 -0400
Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 30 Sep 2002 17:22:37 -0400
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp
          (Exim 3.36 #1) id 17w7zx-000B7E-00; Mon, 30 Sep 2002 14:22:37 -0700
X-Mailer: The Bat! (v1.51) Personal
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <164185881253.20020930142034@psg.com>
Date:         Mon, 30 Sep 2002 14:20:34 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Alex Zinin <zinin@PSG.COM>
Subject: Last Call: draft-katz-yeung-ospf-traffic-08.txt
Comments: cc: Bill Fenner <fenner@research.att.com>,
          Kireeti Kompella <kireeti@JUNIPER.NET>,
          "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Folks-

 We're starting another WG Last Call for draft-katz-yeung-ospf-traffic.
 The draft is a product of the OSPF WG and has been submitted for
 the AD review and further approval by the IESG for publication as
 Proposed Standard. The -08 version of the draft should reflect the
 consensus on the discussion in the WG triggered by the AD-review
 comments. The Last Call ends on Oct 14th.

--
Alex


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 30 18:41:10 2002
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 SAA23503
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Sep 2002 18:41:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.007483F9@cherry.ease.lsoft.com>; Mon, 30 Sep 2002 18:43:04 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 228018 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 30 Sep 2002 18:43:03 -0400
Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 30 Sep 2002 18:33:02 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <22.0074826E@cherry.ease.lsoft.com>;
          Mon, 30 Sep 2002 18:33:02 -0400
Message-ID:  <OSPF%2002093018430339@DISCUSS.MICROSOFT.COM>
Date:         Mon, 30 Sep 2002 18:33:02 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Vince <vmontoya@NMSU.EDU>
Subject: Flooding AS-external LSAs
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Regarding section 13.3 Next step in flooding procedure: AS-external-LSA's -
"The eligible interfaces are all the router's interfaces ..." This states
what links are qualified to be flooded but does it imply that an
implemenation shall flood AS-external-LSAs via all qualified interfaces?


Vince


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Sep 30 20:36:33 2002
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 UAA26083
	for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Sep 2002 20:36:33 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.007486E4@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 20:38:28 +2000
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 228270 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 30 Sep 2002 20:38:28 -0400
Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 30 Sep 2002 20:28:27 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA15806
          for <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 30 Sep 2002 17:28:26 -0700
          (PDT)
X-Delivered-For: <OSPF@DISCUSS.MICROSOFT.COM>
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id g910SQV22500 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 30 Sep 2002 17:28:26 -0700
X-mProtect: <200210010028> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.1.174,
          claiming to be "shah.iprg.nokia.com") by darkstar.iprg.nokia.com
          smtpdgSKQji; Mon, 30 Sep 2002 17:28:24 PDT
Received: from shah.iprg.nokia.com (localhost [127.0.0.1]) by
          shah.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id RAA09446 for
          <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 30 Sep 2002 17:28:24 -0700 (PDT)
X-Mailer: exmh version 2.1.1 10/15/1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <200210010028.RAA09446@shah.iprg.nokia.com>
Date:         Mon, 30 Sep 2002 17:28:24 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Dhaval Shah <dshah@IPRG.NOKIA.COM>
Subject: when to run in NBMA or P2MP mode?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi
        According to RFC 2328, Ospf can run in one of the two modes on a
non-broadcast networks, NBMA or P2MP. RFC says that you can run in NBMA mode
if all routers attached to the network can communicate directly and you should
run in P2MP mode if thats not possible.
        However, while sending hellos out on non-broadcast networks, irrespective of
which mode you run on, you always send them unicast to your neighbors.
        The essential difference between NBMA and P2MP is only that there is DR/BDR
election and Network LSA generation in NBMA mode and not in P2MP mode.
        So why is the need for the restriction that one MUST be able to reach all
neighbors directly in order to run in NBMA mode? What are some of the example
physical networks where one would like to run in P2MP mode and not in NBMA
mode? How can one determine which mode to run when?

thanks
Dhaval.