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

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

Sina,

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 2, 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 1, 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: Sina Mirtorabi <[email-masked]>
Date: Wed, 12 Nov 2003 21:11:59 -0800

Pat,

1) The draft specify to send Hello over the TA and one could configure
it as DC if required

2) In your analysis, you did not mention what is the shortest path of
each TA, if they are the direct links then you would follow that next
hop and not through adjacent node which will make the packet to be
dropped since the switch is down

3) Assuming the TA's path goes over each other and later the switch goes
down, what you described could happen during a transition time ( the
time TA will be brought down ) and not a problem with the proposal. As
an analogy when a link goes down and during a transition SPF period in
the network we can have loop however this does not mean that there is a
problem in SPF algorithm.

Thanks
Sina

->
->Sina,
->
->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 2, 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 1, 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: Sina Mirtorabi <[email-masked]>
Date: Fri, 14 Nov 2003 07:18:02 -0800

Pat

One important correction below

->
->Pat,
->
->1) The draft specify to send Hello over the TA and one could
->configure it as DC if required
->
->2) In your analysis, you did not mention what is the shortest
->path of each TA, if they are the direct links then you would
->follow that next hop and not through adjacent node which will
->make the packet to be dropped since the switch is down
->
->3) Assuming the TA's path goes over each other and later the
->switch goes down, what you described could happen during a
->transition time

Actually this can NEVER happen. This is because TA shortest path can
never go through each other as cost are positive ( one can go over the
other but not over each other ) therefore in your example after the
first GRE encapsulation you would drop the packet since the switch is
down.

Thanks
Sina

PS: Alex, this is also true for your example, two TA's SPT can not go
over each other therefore they can never backup each other

( the time TA will be brought down ) and not
->a problem with the proposal. As an analogy when a link goes
->down and during a transition SPF period in the network we can
->have loop however this does not mean that there is a problem
->in SPF algorithm.
->
->Thanks
->Sina
->
->->
->->Sina,
->->
->->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
->2, 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
->1, 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
->->
->