Re: OSPF : Summarization of type-7 lsa's

"Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov> Thu, 07 July 2005 14:47 UTC

Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXfP-0000tD-5S for ospf-archive@megatron.ietf.org; Thu, 07 Jul 2005 10:47:57 -0400
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14001 for <ospf-archive@LISTS.IETF.ORG>; Thu, 7 Jul 2005 10:47:49 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0109DAF2@cherry.ease.lsoft.com>; Thu, 7 Jul 2005 10:47:48 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78251439 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 7 Jul 2005 10:47:44 -0400
Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 7 Jul 2005 10:47:44 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01LQC49EC9G8003LOZ@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 07 Jul 2005 07:50:51 -0700 (PDT)
X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM
X-VMS-Cc: pmurphy
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Message-ID: <01LQC49ECAE2003LOZ@omega7.wr.usgs.gov>
Date: Thu, 07 Jul 2005 07:50:51 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: OSPF : Summarization of type-7 lsa's
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Ajay,

>    1> If path type selected is external type 2 then type 5 metric 
>should be set to the largest type-7 metric subsumed by this net range + 
>1 ;

>****** I have doubt like.. why we add 1 in this cost ..Is there any 
>specific reason behind this?

The only hint comes from RFC 1587/3101 wording

     These metric and path type rules will avoid routing
     loops in the event that path type 1 and 2 are both
     used within the area.

I believe this was done in RFC 1587 to distinguish the Type-5 LSA 
originated via the Type-7 translation/summarization process from a 
Type-7 LSA that has the same prefix. However this is conjecture on my 
part and I don't ever remember verifying it in a discussion with Rob 
Coltun. A tight routing loop seems possible in this case when the tie 
breaker rules of RFC 1587's external route calculation Step 5 are 
applied:

    a. Any type 5 LSA.
    b. A type-7 LSA with the P-bit set and the forwarding
       address non-zero.
    c. Any other type-7 LSA.

An NSSA would need two ABRs and the translator would have to see an NSSA 
path to the Type-7 LSA's prefix through the second ABR for the loop to 
occur. 

The RFC 3101 tie breaker rules deal with this situation completely 
differently, and it is possible that adding +1 is no longer necessary. I 
realized this once, but adding +1 to the type 2 computed metric appeared 
harmless enough that a change seemed unwarranted. I do have a minor 
correction to make to RFC 3101 from an earlier disuccsion, so if the 
current WG feels this should be changed I have no objections.

>2> If the path type selected in external type 1 , the type -5 metric 
>should be set to the largest metric..

>***  In this case we don't add any cost to ASBR. why this is so?

The distance to the originator of the type-7 LSA plays a role in 
computing the translated Type 5's type 1 metric. Hence the second ABR 
above would compute a more preferred path via the Type-7 LSA that does 
not go through the translator ABR

Pat