Subject: Re: Multi-address and Tunnel Adjacency

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Mon, 16 Feb 2004 09:04:29 -0700

Acee,

Both tools partially meet a requirement that I have long hoped for. If I
have to choose I prefer the multi-area adjacency draft. Corporate
OSPF topologies are built one link at a time to meet specific performance
criteria for carrying the expected load of specific networks. Redundant
links are also planned with that in mind. Indeed sometimes under dire
conditions it is better to just let an area partition; as the shifting of
load could cause even more damage. In addition the multi-area adjacency
draft can support multiple non-backbone areas down the same non-backbone
link, while the TAs of the current draft can only be built over area 0 (a
minor point). The simplicity and added feature of TAs is appealing, but I
would not want to give up controlling the quality of redundant and
preferred paths one link at a time.

Note given the increasing size of router memory that can support
substantially larger routing tables, the requirement to avoid the
adverse impact of area/range summarization during area partitioning is
not the requirement it once was. We use to worry about such things.
Now we simply drop the summarization.

There are a number of reasons I have never found virtual links a useful
tool that also apply to TAs. E.g. transit paths through OSPF areas are
commonly a mixed bag of high-performance paths versus lower performing
paths. The lack of path control requires a careful study of possible
remote outcomes before the tool is deployed. Links with line speeds
greater that 100Mbps are quite common these days even in corporate
networks. This complicates the OSPF costing of links. VLs and TAs work
best in an OSPF domain with a consistent costing algorithm between areas.
The usefulness of VLs and TAs might benefit from the addition of VL and
TA parameters like max-path-cost or max-path-TTL that would control if
and when adjacencies should form. However speed and hop count alone do
not determine path preference. Two single hop paths of the same speed can
have decidedly different performance parameters.

Pat

---

From: Sina Mirtorabi <[email-masked]>
Date: Mon, 16 Feb 2004 13:08:37 -0800

Pat,

->
->Acee,
->
->Both tools partially meet a requirement that I have long
->hoped for. If I have to choose I prefer the multi-area
->adjacency draft. Corporate OSPF topologies are built one link
->at a time to meet specific performance criteria for carrying
->the expected load of specific networks. Redundant links are
->also planned with that in mind.

Your argument for load does not stand, the whole idea of using TA (or
multi-area adj) is to use the high speed backbone path (link) and avoid
going through a suboptimal path through non-backbone area

->Indeed sometimes under dire
->conditions it is better to just let an area partition; as the
->shifting of load could cause even more damage.

I remind you that configuring partition avoidance is optional, if one
does not need (there is no summarization) or has a eventual load problem
you will not configure the partition repair. Note that in absence of
summarization, your area will be automatically repaired through the
backbone and you still have the load problem you describe if it really
exist.

->Note given the increasing size of router memory that can
->support substantially larger routing tables, the requirement
->to avoid the adverse impact of area/range summarization
->during area partitioning is not the requirement it once was.

The memory is irrelevant here. If you are summarizing it is because you
want to minimize the flooding of thousands of LSAs and not really
because you are concerned for holding the advertised prefix in your RIB.

->We use to worry about such things. Now we simply drop the
->summarization.

It depends who is "we". Dropping packet cannot be acceptable for some
customers. Imagine a common hub and spoke topology where you are
summarizing at ABRs. If the intra-area link between the ABR goes down
then you are either dropping the packet or doing suboptimal routing as
described in application section of TA. If you drop packet at ABR then
your remote are isolated...

->
->There are a number of reasons I have never found virtual
->links a useful tool that also apply to TAs. E.g. transit
->paths through OSPF areas are commonly a mixed bag of
->high-performance paths versus lower performing paths.

TA transit area can only be backbone therefore what you state above
although may apply to VL, does NOT apply to TA.

Sina