Re: Default LSA creation

TAKENAGA Yoshinobu <takenaga@SOFT.NET.FUJITSU.CO.JP> Fri, 11 October 2002 10:06 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15369 for <ospf-archive@LISTS.IETF.ORG>; Fri, 11 Oct 2002 06:06:17 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00767305@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 6:08:23 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 280793 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 06:08:23 -0400
Received: from 192.51.44.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 06:08:23 -0400
Received: from m4.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0205-Fujitsu Gateway) id TAA25137; Fri, 11 Oct 2002 19:08:17 +0900 (JST) (envelope-from takenaga@soft.net.fujitsu.co.jp)
Received: from mailhost.soft.net.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.9.3/3.7W-0209-Fujitsu Domain Master) id TAA24456; Fri, 11 Oct 2002 19:08:16 +0900 (JST) (envelope-from takenaga@soft.net.fujitsu.co.jp)
Received: from localhost (fire01.soft.net.fujitsu.co.jp [10.22.111.172]) by mailhost.soft.net.fujitsu.co.jp (8.11.6/8.11.6) with ESMTP id g9BA8FH13326; Fri, 11 Oct 2002 19:08:15 +0900 (JST)
References: <20021011.112101.86422822.takenaga@soft.net.fujitsu.co.jp> <3DA65070.3060309@redback.com>
X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20021011.190815.03870603.takenaga@soft.net.fujitsu.co.jp>
Date: Fri, 11 Oct 2002 19:08:15 +0900
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: TAKENAGA Yoshinobu <takenaga@SOFT.NET.FUJITSU.CO.JP>
Subject: Re: Default LSA creation
Comments: To: acee@REDBACK.COM
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To: <3DA65070.3060309@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Default LSA creation
Date: Fri, 11 Oct 2002 00:15:44 -0400

> TAKENAGA Yoshinobu wrote:
>
> > Hi,
> >
> > I have a question about creation of default lsa into stub areas.
> > (This question may be a FAQ, please suggest the point)
> >
> > Consider this network.
> >
> >    area 1   :  area 0
> >    (stub)   :     +--->>(AS extenal path)
> >             :     |
> >  |--R1--|   :  |--R4--|
> >  |      |--R2--|      |
> >  |          :         |
> >  |      |--R3--|      |
> >  |--R6--|   :  |--R5--|
> >             :
> >
> > Here, R2 and R3 are area border router.
> > R4 is AS boundary router.
> > All link have same cost.
> >
> > In such situation, R2 and R3 will create default Type-3 LSA into area 1.
> > R1 will select R2 as nexthop to the AS extenal path through R4.
> >
> > Now, the link state changes to this (R4 lose the link to N1).
> >
> >    area 1   :  area 0
> >    (stub)   :     +--->>(AS Extenal path)
> >             : N1  |
> >  |--R1--|   :  |XXR4--|
> >  |      |--R2--|      |
> >  |          :         |
> >  |      |--R3--|      |
> >  |--R6--|   :  |--R5--|
> >             :
> >
> > In such situation, R2 becomes a blackhole.
> >
> > What is the minimum requirement for R2 to create default Type-3 LSA
> > into stub areas?
> >   - having configuration of Area0
> >   - having active interface to Area0
> >   - having "Full" status neighbor in Area0
> >   - other??
>
>
> Hi Takenaga,
>
> The answer is other. The minimum requirement is that the
> router be an Area Border Router (ABR). Section 3.3 of RFC 2328 defines
> an ABR as a router that attaches to multiple areas. In the context of
> RFC 2328, area attachment requires at least one active interface in that
> area. Some implementations use other definitions of what constitutes
> an ABR (e.g., refer to draft-ietf-ospf-abr-alt-04.txt). However, using
> a different ABR definition doesn't handle all situations. Consider R6 and
> R3 in the figure below:
>
>
>      area 1   :  area 0
>      (stub)   :     +--->>(AS Extenal path)
>               : N1  |
>    |--R1--|   :  |--R4--|
>    |      |--R2--|      |
>    |          :         |
>    |      |--R3--|      |
>    |--R6--|   :  |--R5XX|
>
>
> In general, a good OSPF network design will minimize the possibility
> that the backbone will become partitioned.

Hi Acee,

Thank you for your response.

I understand. Some other good solutions(in such IDs) may have confused
me.  Now my question is cleard with your advice.

--
TAKENAGA Yoshinobu, Fujitsu.