Subject: Re: My comment on draft-mirtorabi-ospf-tunnel-adjacency

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Wed, 12 Nov 2003 18:15:25 -0700

Sina,

This is being resent due to a couple of incorrect Area #s. Sorry.

When I last contacted you about this draft I recommended you drop DC and
maintain TAs utilizing Hello processing. Short Router Dead intervals
might mitigate the anomalous behavior described in the example below. At
the time you felt comfortable that excessive LSA Retransmission would
cause these adjacencies to drop in a timely manner. Regardless of how
your draft maintains the Full state of its TAs, there might still be an
unacceptable lag time before the TAs drop after a critical path component
fails. During this lag, packet forwarding may incur endless
retunneling.

Consider this contrived (for simplicity) example:

                        N2
                         .
                         .
                        B0
                       . . .
          Area 1     .   .   .     Area 2
           link    .     .     .    link
                 .    Area 2     .
               .         .         .
            A0..Area 1..Xs..link...C0
               .         .         .
                 .     link      .
                   .     .     .   Area 1
          Area 2     .   .   .      link
           link        . . .
                        D0

where Area 2 has a TA between A0 and C0 across Area 1, and Area 1 has a
TA between B0 and D0 across Area 2. A0, B0, C0, and D0 are Area 0 border
routers. Xs is a non-routing switching component common to paths in both
areas that has just failed. N2 is a network belonging to Area 2. The
intent is for the paths

        A0..Area.1..Xs..link....C0
and
        B0..Area.2..Xs..link....D0

to maintain the Area 1 TA and Area 2 TA respectively. Unfortunately,
following the failure of Xs, the TAs can also be used to maintain each
other until one or the other drops. Here is what happens during the lag.

Stage 1

A0 needs to forward a packet through B0 to N2 across Area 2. The direct
Area 2 path to N2, namely A0-->D0--Xs-->B0-->N2, is broken. However the
Area 1 TA (TA1) between B0 and D0 across Area 2 appears good to A0 (until
the TA fails and is removed from the LSDB), creating an apparent Area 1
path between A0 and C0, namely A0-->B0--TA1-->D0-->C0. This in turn
makes the Area 2 TA (TA2) between A0 and B0 appear good, thus providing
A0 with the illusion of an Area 2 path to N2, namely
A0--TA2-->C0-->B0-->N2.

So A0 encapsulates the Area 2 packet destined for N2 into a GRE packet
destined for C0 in Area 1, and forwards this new GRE packet across its
Area 1 direct link to B0.

Stage 2

B0 receives this latest GRE packet from A0 whose destination is C0 in
Area 1 (not N2 in Area 2). Similar logic causes B0 to ensapsulate this
GRE packet into another GRE packet destined for D0 in Area 2, and then
B0 forwards this new GRE packet across its Area 2 direct link to C0.

Stage 3

C0 receives this latest GRE packet from B0 whose destination is D0 in
Area 2 (not C0 in Area 1). Similar logic causes C0 to ensapsulate this
GRE packet into another GRE packet destined for A0 in Area 1, and then
C0 forwards this latest GRE packet across its Area 1 direct link to D0.

Stage 4

D0 receives this latest GRE packet from C0 whose destination is A0 in
Area 1 (not D0 in Area 2). Similar logic causes D0 to ensapsulate this
GRE packet into another GRE packet destined for B0 in Area 2, and D0
then forwards this new GRE packet across its Area 2 direct link to A0.

Stage 5 and beyond

A0 receives this latest GRE packet from D0 whose destination is B0 in
Area 2 (not A0 in Area 1). This last Area 2 GRE packet destined for B0
in Area 2 is just the original Area 2 packet destined for N2, bundled
underneath four GRE encapsulations. Stages 1 through 4 repeat
continuously until the TAs drop, effectively producing a short (?)
packet flood over the perimeter links of Area 1 and Area 2.

Thoughts anyone? How about a simpler example.

Pat

---

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Fri, 14 Nov 2003 15:11:07 -0700

Sina,

>however it may not be easy to distinguish a TA link during SPF since it
>is a p2p link.

Very true. Keep in mind the example I posted is very contrived for
simplicity but represents what I believe is a subtle sink hole that a
customer could unknowningly fall into. Placing a tunnel here and there may
seem harmless, but once you have more than one in the OSPF domain
topology, all bets are off.

There is nothing wrong with your applications:

>* using high speed link of the backbone for transit area
>* in Hub and spoke topology have multiple TA over backbone link ( path )
>* on demand partition repair for non-backbone area that are summarized

but customers are nortorious for stretching the limits of feature and its
the poor folk on the cisco hot line that have to troubleshoot such subtle
anomalies. This feature needs to be carefully deployed. A cautious
technical writeup is warranted

Its nice to see an OSPF draft that features enterprise applicability.

Pat