Subject: [OSPF] originating type 4 summary LSAs with RFC1583Compatibility enabled

From: Nischal Sheth <[email-masked]>
Date: Mon, 16 Feb 2009 18:49:09 -0800

I have a question about originating a type 4 summary
LSA when a router has an intra-area route (via area A) to
an ASBR as well as a lower cost inter-area route (via the
backbone) to the same ASBR through another ABR.

According to the sixth bullet in section 12.4.3 of RFC 2328:

   Else, if the destination of this route is an AS boundary
   router, a summary-LSA should be originated if and only
   if the routing table entry describes the preferred path
   to the AS boundary router (see Step 3 of Section 16.4).
   If so, a Type 4 summary-LSA is originated for the
   destination, with Link State ID equal to the AS boundary
   router's Router ID and metric equal to the routing table
   entry's cost. Note: these LSAs should not be generated
   if Area A has been configured as a stub area.

According to section 16.4 item (3), the preferred route to
the ASBR would be the least cost route i.e. the inter-area
route, since RFC1583Compatibility is enabled.

Thus, as far as I can tell,  we would generate a type 4
summary when processing the inter-area route entry and
advertise the summary into area A and not generate the
corresponding summary into the backbone.  This would be
different than RFC 1583 behavior or RFC 2328 behavior
with RFC1583Compatibility disabled. In those two cases,
we would generate a type 4 summary into the backbone and
areas other than A when processing the intra-area route
entry, since the intra-area route would be the preferred
route.

Is this the correct interpretation of sections 12.4.3 and
16.4?

Thanks in advance for any responses.

-Nischal

---

From: Acee Lindem <[email-masked]>
Date: Thu, 19 Feb 2009 05:58:57 -0500

Hi Nischal,
I think this certainly is ambiguous as to whether the route type  
should be taken into consideration when determining the which ASBR  
path is lowest cost. Your literal interpretation seems but reasonable  
but I know of at least one implementation that would consider the  
route type. Luckily, this confusion is eliminated if  
RFC1583Compatiblity is disabled.
Thanks,
Acee

On Feb 16, 2009, at 9:49 PM, Nischal Sheth wrote:

> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Nischal Sheth <[email-masked]>
Date: Thu, 19 Feb 2009 12:56:13 -0800

Hi Acee,

Thanks for the response.

I have a related question about the intent of the RFC1583Compatibility
global parameter.  When set to enabled, is the underlying objective to
emulate a RFC 1583 implementation (w.r.t. path selection among ASBRs and
external LSAs) or is it "just" to allow compatible operation with other
1583 routers in the network.  IOW, does an implementation even need to
maintain multiple routes to an ASBR if RFC1583Compatibility is enabled?

Thanks,
Nischal

Acee Lindem wrote:
> Hi Nischal,
> I think this certainly is ambiguous as to whether the route type should 
> be taken into consideration when determining the which ASBR path is 
> lowest cost. Your literal interpretation seems but reasonable but I know 
> of at least one implementation that would consider the route type. 
> Luckily, this confusion is eliminated if RFC1583Compatiblity is disabled.
> Thanks,
> Acee
>

---

From: Acee Lindem <[email-masked]>
Date: Sun, 22 Feb 2009 09:35:11 -0500

Hi Nischal,

On Feb 19, 2009, at 3:56 PM, Nischal Sheth wrote:

> 1583 routers in the network.

Offhand, I don't see much difference but I might be missing something.

> IOW, does an implementation even need to

I went back to RFC 1583 and a path per area providing ASBR  
reachability is still maintained. I believe an implementation could  
maintain a single path but then you'd have to handle finding an  
alternate path when an ASBR becomes unreachabile.

Thanks,
Acee

>> path is lowest cost. Your literal interpretation seems but  
>> reasonable but I know of at least one implementation that would  
>> consider the route type. Luckily, this confusion is eliminated if

---

From: Nischal Sheth <[email-masked]>
Date: Sun, 22 Feb 2009 22:02:48 -0800

Acee Lindem wrote:

> I went back to RFC 1583 and a path per area providing ASBR reachability 
> is still maintained. I believe an implementation could maintain a single 
> path but then you'd have to handle finding an alternate path when an 
> ASBR becomes unreachabile.
> 

Hi Acee,

I based this on my reading of section 16.2 in RFC 1583.  According to items
(5), (6), (7) we only need to maintain the lowest cost route(s) to the ASBR,
preferring intra-area routes over inter-area routes. Specifically, item 5 does
not say (unlike RFC 2328) to lookup the area specific route entry to N for
type 4 LSAs.  Hence I figured that we would end up with only 1 route to the
ASBR, assuming non equal cost routes.

Thanks,
Nischal

---

From: Acee Lindem <[email-masked]>
Date: Mon, 23 Feb 2009 10:22:08 -0500

Hi Nischal,

On Feb 23, 2009, at 1:02 AM, Nischal Sheth wrote:

>> reachability is still maintained. I believe an implementation  
>> could maintain a single path but then you'd have to handle finding  
>> an alternate path when an ASBR becomes unreachabile.
>
> Hi Acee,
>

I agree. Scratch what I said above, I was thinking in terms of an  
implementation optimization.

Thanks,
Acee

---

From: Nischal Sheth <[email-masked]>
Date: Mon, 23 Feb 2009 13:40:31 -0800

Hi Acee,

Circling back to the original question I posted, my confusion was related to
how a RFC 2328 implementation with RFC1583Compatibility enabled should behave
as far as picking the best ASBR route is concerned.

If you interpret RFC 2328 literally, you would use the lowest cost route to
the ASBR irrespective of the type (intra vs. inter). In contrast, an RFC 1583
implementation would prefer the intra-area route.  It wasn't clear to me if
this difference in behavior is intentional (hence my attempt to differentiate
between "compatibility" and "emulation") or whether it's simply the case that
the relevant sections are a little bit underspecified.

Based on your input, it appears that it's more of the latter than the former.
An RFC 2328 implementation can maintain multiple routes to the ASBR but make
sure that intra-area routes are preferred when RFC1583Compatibility is enabled.
Alternately, it can behave exactly like an RFC 1583 implementation and keep
only the intra-area route.

Does this sound reasonable?

Thanks,
Nischal

---

From: Acee Lindem <[email-masked]>
Date: Mon, 23 Feb 2009 17:53:20 -0500

Hi Nischal,

> Does this sound reasonable?

Yes. My interpretation of the intent of RFC1583Compatibility is to  
maintain the RFC 1583 path selection.

Thanks,
Acee

---

From: Nischal Sheth <[email-masked]>
Date: Tue, 24 Feb 2009 11:45:03 -0800

> maintain the RFC 1583 path selection.

Sounds good.  Many thanks for all your input on this thread.

-Nischal