Subject: Multi-address and Tunnel Adjacency

From: Acee Lindem <[email-masked]>
Date: Fri, 13 Feb 2004 16:55:25 -0500

Speaking as a WG member, I think we should accept
one of these drafts as a working group document since the
requirement to share an OSPFv2 link over multiple areas
without additional encapsulation has existed for some
time.

http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunnel-adjacency-01.txt

http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-multi-area-adj-00.txt

The multi-area adjacency draft provides the minimum functionality to
use a link in multiple areas (without additional addressing or encapsulation).
The TA draft solves this problem along with providing a mechanism to
dynamically bring up tunnels  through a transit area (the tunnel will be
used for both data and the adjacency).

Comments?
------
Acee

---

From: Quaizar Vohra <[email-masked]>
Date: Fri, 13 Feb 2004 15:16:01 -0800

I prefer the multi-area adjacency draft as it is simpler and
cleaner in design. The other draft proposes something which is
easier implemented using mechansims outside ospf.

Quaizar

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 13 Feb 2004 15:41:28 -0800

> easier implemented using mechansims outside ospf.

I would agree with that.

rahul

---

From: Sina Mirtorabi <[email-masked]>
Date: Fri, 13 Feb 2004 17:51:21 -0800

Quaizar, Rahul

Although there is a small overlap for a single hop case I do not think
that the two drafts really compete as they solve different problems.

Tunnel adjacency solve the case where ABR are multi-hops and further
provide an automatic partition repair for the non-backbone areas. If you
refer to GRE tunnel as an alternative solution, there are draw backs in
it such as extra configuration overhead, extra IP address for tunnel,
relying on IP reachbility versus SPF reachability and besides the manual
tunnel does not provide automatic partition repair.

I believe an implementation can decide to implement either, both or none
of the solutions however customers needs different solutions and I know
customers who are interested in automatic partition repair solution of
TA.

Thanks
Sina

->-----Original Message-----
->From: Mailing List [mailto:[email-masked]] On
->Behalf Of Quaizar Vohra
->Sent: Friday, February 13, 2004 3:16 PM
->To: [email-masked]
->Subject: Multi-address and Tunnel Adjacency
->
->
->I prefer the multi-area adjacency draft as it is simpler and
->cleaner in design. The other draft proposes something which
->is easier implemented using mechansims outside ospf.
->
->Quaizar
->
-> > Speaking as a WG member, I think we should accept
-> > one of these drafts as a working group document since the
-> > requirement to share an OSPFv2 link over multiple areas
-> > without additional encapsulation has existed for some
-> > time.
-> >
-> >
->http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunne
l-adjacency-01.txt
http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-multi-area-adj-
00.txt
> use a link in multiple areas (without additional addressing or
encapsulation).  > The TA draft solves this problem along with providing
a mechanism to  > dynamically bring up tunnels  through a transit area
(the tunnel will be  > used for both data and the adjacency).  >  >
Comments?  > ------  > Acee

---

From: Quaizar Vohra <[email-masked]>
Date: Tue, 17 Feb 2004 11:51:58 -0800

> tunnel does not provide automatic partition repair.

The extra config for TA is comparable to GRE. GRE tunnels could be run
unnumberred.

Could you please explain (no sarcasm intended, just admitting
ignorance) why SPF reachability is considered superior to IP
reachability. A GRE tunnel could be tied to route reachability of the
tunnel end-point if one wanted it so (which would cover
SPF-reachability).

One could easily simulate an automatic partition repair using GRE
tunnel by giving it a cost which would be higher than the intra-area
cost of the remote end.

My main point being virtual-links add very significantly to the
implementation complexity. TAs would just add to that.

While I find that multi-adjacency draft simpler and elegant
wrt implementation and fullfils a requirement which clearly
falls under the perview of an IGP. Optimal routing is
clearly under the scope of an IGP while reachabiliity is clearly
not.

Quaizar

---

From: Sina Mirtorabi <[email-masked]>
Date: Tue, 17 Feb 2004 13:27:44 -0800

Quaizar,

->The extra config for TA is comparable to GRE. GRE tunnels
->could be run unnumberred.

Well the TA config should be one line of the config ( similar to VL ),
for GRE you have to create tunnel, assign tunnel end point reachability
address, advertise them in OSPF and configure OSPF over the tunnel so it
should not be that comparable

As the number of tunnels increase ( H&S topology with different
non-backbone area ) the above could be significant...

->
->Could you please explain (no sarcasm intended, just admitting
->ignorance) why SPF reachability is considered superior to IP
->reachability. A GRE tunnel could be tied to route
->reachability of the tunnel end-point if one wanted it so
->(which would cover SPF-reachability).

In general IP reachability can take any path while SPF reachability is
through an intended transit area. If your area is partitioned your
tunnel end point reachablity may switch from intra-area route into
Inter-area route which could lead to learning the tunnel endpoint
through the tunnel itself and failing the tunnel. ( although you could
prevent that by assigning a high cost to the GRE tunnel)

->
->One could easily simulate an automatic partition repair using
->GRE tunnel by giving it a cost which would be higher than the
->intra-area cost of the remote end.
->
->My main point being virtual-links add very significantly to
->the implementation complexity. TAs would just add to that.

Any change to OSPF, could be perceived as an implementation complexity.
It is natural for a protocol to be extended if there are requirements
and customer demand behind it. Also one of the complexity of the VL may
be related to TransitCapability and nexthop calculation which does not
exit in TA.

Probably the categories of the draft should be aimed to be Informational
so that it does not force an implementation to implement it.

->
->While I find that multi-adjacency draft simpler and elegant
->wrt implementation and fullfils a requirement which clearly
->falls under the perview of an IGP. Optimal routing is clearly
->under the scope of an IGP while reachabiliity is clearly not.

Considering others comments, looks like there is an agreement to move
forward the multi-adj draft

Sina