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

[tajay <[e-mail]>]

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


Pat Murphy - [phone] wrote:

>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
>
>  
>