Subject: [OSPF] transit summary lsas

From: p6 c6d6 <[email-masked]>
Date: Mon, 15 Nov 2010 08:17:20 +0530

hi,

why should one recalculate routes using transit areas summary lsas, even if
better paths exist through transit area.  as a virtual link is considered as
an unumbered p2p link, it is as good as the router has an interface to the
backbone.
referring to rfc2328 figure 17, RT1 chooses route network N1 through RT4,
since that
is an intra-area path, that is in accordance to the path preference rules of
ospf.
why do we give special treatment for transit areas. If the link were not a
virtual-link and
if it indeed is real p2p interface in to the backbone, we will not try to
route the data to N1
through RT5, since the route through RT4 would be preferred. why special
treatment for
transit areas, and why can't we extend this treatment to other areas as well
(neglecting
the fact that area routing is protected by bad routing of other areas).

thanks in advance

---

From: Acee Lindem <[email-masked]>
Date: Mon, 15 Nov 2010 04:50:29 -0500

This is due to the fact that paths via transit area ABRs other than the virtual link endpoints can be installed. If I were designing a link-state protocol from scratch, I would not include the complexity of virtual links as they are specified in OSPF. 

Hope this helps,
Acee 

On Nov 14, 2010, at 9:47 PM, p6 c6d6 wrote:

> an unumbered p2p link, it is as good as the router has an interface to the backbone.
> referring to rfc2328 figure 17, RT1 chooses route network N1 through RT4, since that
> is an intra-area path, that is in accordance to the path preference rules of ospf. 
> why do we give special treatment for transit areas. If the link were not a virtual-link and
> if it indeed is real p2p interface in to the backbone, we will not try to route the data to N1
> through RT5, since the route through RT4 would be preferred. why special treatment for
> transit areas, and why can't we extend this treatment to other areas as well (neglecting
> <ATT00001..txt>

---

From: p6 c6d6 <[email-masked]>
Date: Tue, 16 Nov 2010 08:12:46 +0530

On Mon, Nov 15, 2010 at 3:20 PM, Acee Lindem <[email-masked]>wrote:

>
> This is due to the fact that paths via transit area ABRs other than the
> virtual link endpoints can be installed. If I were designing a link-state
> protocol from scratch, I would not include the complexity of virtual links
> as they are specified in OSPF.
>
> Hope this helps,
> Acee
>
oh is it. i thought virtual links is a good idea.
and for the newly calculated route  why do we
have to use the associated area as backbone area
though the path is still through transit area ?

---

From: Acee Lindem <[email-masked]>
Date: Mon, 15 Nov 2010 21:44:30 -0500

p6c6d6 - see inline.
On Nov 15, 2010, at 9:42 PM, p6 c6d6 wrote:

On Mon, Nov 15, 2010 at 3:20 PM, Acee Lindem <[email-masked]<mailto:[email-masked]>> wrote:

Hope this helps,
Acee

Because the virtual link is part of the backbone.

Acee

<ATT00001..txt>

---

From: Anton Smirnov <[email-masked]>
Date: Tue, 16 Nov 2010 10:52:41 +0100

> oh is it. i thought virtual links is a good idea.

Virtual links is just a hack to overcome some most obvious consequences
of limiting area hierarchy to be 1 level deep (backbone as root and
everything else is leaf). In the long term hacks rarely make any good.
I agree with Acee, on new design it would have been better to place
complexity somewhere else. For example, in allowing true area hierarchy.

Anton

On 11/16/2010 03:42 AM, p6 c6d6 wrote:
> 
> On Mon, Nov 15, 2010 at 3:20 PM, Acee Lindem <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>     This is due to the fact that paths via transit area ABRs other than
>     the virtual link endpoints can be installed. If I were designing a
>     link-state protocol from scratch, I would not include the complexity
>     of virtual links as they are specified in OSPF.
> 
>     Hope this helps,
>     Acee
> 
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf