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

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Thu, 7 Jul 2005 07:50:51 -0700

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

---

From: tajay <[email-masked]>
Date: Fri, 8 Jul 2005 15:20:13 +0530

murthy,
thanks for answering my queries.  I have some more queries in OSPF  - 
NSSA area.

Suppose i have configured summary-address to summarize more than one 
type-7 lsa. In this case we while generating type-5 lsa we follow 
section 4.1 of rfc 1587 .
e.g.

1>  If none of the lsa's LS-Id matches to my summary-address range but 
LS-Id falls under configured summary address range, then we generate 
type-5 as per  rfc 1587 -section 4.1 (2)
and

2> If my LSA has LS-Id equal to summary address range then  we  generate 
type-5 lsa as per rfc 1587 section-4.1(1)

What happens if ospf database has one LSA  with LS-Id matches to my 
summary-address range and some LSAs with LS-Id falling under 
summary-address range.
Then in this case what type of metric or path-type we should set in the 
type-5 lsa?

with regards
ajay