Re: Type-7 to Type-5 translation issue

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

Thankyou Acee.

Regards
Santosh

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


-- 
Santosh Esale

Member - Technical Staff

Riverstone Networks India Pvt. Ltd.

Email: sesale@riverstonenet.com