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

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

>As I have stated before this is only during a transition time that TA
>are brought down.

In the original posting my only concern was during the transition
(lag) time till the TAs drop. There was never any statement that the
TAs would use one another during normal operation. I do think this is
a concern if you don't want an outage over a specific link adversely
effecting other links. Intermittant packet floods caused by flapping
links are nasty things. While its difficult to devise a simple
example, its not hard to imagine one in real life.

>I believe if there are real concerns for that we can
>do what Acee suggested, i.e never use a TA in the SPT of another TA

How does that help if one TA is in Area 1 and the other TA is in Area
2?

Pat

---

From: Sina Mirtorabi <[email-masked]>
Date: Fri, 14 Nov 2003 14:47:47 -0800

Pat,

P->In the original posting my only concern was during the transition
P->(lag) time till the TAs drop. There was never any statement
P->that the TAs would use one another during normal operation.

Good, we agree on that one.

P->I do think this is a concern if you don't want an outage over a
P->specific link adversely effecting other links.

This may also be true for a normal link. if links goes down, flooding
occur, SPF occur and transient loop exist and  traffic data path can
overload other links

S->>I believe if there are real concerns for that we can
S->>do what Acee suggested, i.e never use a TA in the SPT of another TA

P->How does that help if one TA is in Area 1 and the other TA is
P->in Area 2?

I was thinking to Not use a TA in another TA's SPT in order to take care
of the recursive TA. So if you have TA1 belonging to area 1 and TA2
belonging to area 2, when doing SPF for area 2 you don't want to use TA2
link ( which belong to area 2) however it may not be easy to distinguish
a TA link during SPF since it is a p2p link.

We agree that TA cannot goes over each other during normal operation, if
transition occur and during RouterDeadInterval ( which can be default to
lower values ) and in some corner cases where mutual TA configuration is
done you may have encapsulations during RouterDeadInterval of the TA.

As I have stated before TA usage and design is pretty simple and
consists of the following :

* 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

Therefore I do not see any problem in the current draft. Now if you
would still argue and there are real concerns regarding recursive TA (
which may happen during RouterDeadInterval ) from other WG members, I
can modify the proposal to avoid the recursive TA.

Thanks
Sina