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

From: Alex Zinin <[email-masked]>
Date: Mon, 10 Nov 2003 16:45:10 -0600

<wg participant>

Here's the question I asked at the mic today:

2328 limits the configuration of the VLs so that they can only transit
through non-backbone areas and always belong to the backbone. Among
other things this prevents "recursive" VLs, i.e., VLs relying on other
VLs.

The draft relaxes this and suggests that the TA can belong to any area
and can transit any area. This opens up a possibility for TA1 that
belongs to area A1 to transit area A2 that has TA2. This means that
it could be possible for packets to be encapsulated more than once.
It seems it could also be possible to have recursive TA resolution,
e.g. in the case above, TA2 transiting area A1.

Seems that this needs to be given more thought.

--
Alex

P.S. Padma also pointed out the possibility for excessive SPF
     calculation, but I'll leave it to her to describe the concern
     she has

---

From: Sina Mirtorabi <[email-masked]>
Date: Wed, 12 Nov 2003 11:50:38 -0800

Alex,

->
-><wg participant>
->
->Here's the question I asked at the mic today:
->
->2328 limits the configuration of the VLs so that they can
->only transit through non-backbone areas and always belong to
->the backbone. Among other things this prevents "recursive"
->VLs, i.e., VLs relying on other VLs.
->
->The draft relaxes this and suggests that the TA can belong to
->any area and can transit any area. This opens up a
->possibility for TA1 that belongs to area A1 to transit area
->A2 that has TA2. This means that it could be possible for
->packets to be encapsulated more than once. It seems it could
->also be possible to have recursive TA resolution, e.g. in the
->case above, TA2 transiting area A1.

Yes, if TA1 has to transit over area 2 to go from ABR1 to ABR2 and its
shortest path goes over another TA ( that is another TA belonging to
area 2 exist ) then the packet could be encapsulated / decapsulated one
more time in the portion that TA2 traverse if they are multi-hop but
note that in any case the packet will be delivered to te remote ABR and
there should not be any problem.

->
->Seems that this needs to be given more thought.

Could you give an example of a case that could introduce a problem

Thanks
Sina

->
->--
->Alex
->
->P.S. Padma also pointed out the possibility for excessive SPF
->     calculation, but I'll leave it to her to describe the concern
->     she has
->

---

From: Alex Zinin <[email-masked]>
Date: Wed, 12 Nov 2003 20:42:00 -0600

Sina,

->>The draft relaxes this and suggests that the TA can belong to
->>any area and can transit any area. This opens up a
->>possibility for TA1 that belongs to area A1 to transit area
->>A2 that has TA2. This means that it could be possible for
->>packets to be encapsulated more than once. It seems it could
->>also be possible to have recursive TA resolution, e.g. in the
->>case above, TA2 transiting area A1.

> there should not be any problem.

In general, because VL in any area can use a VL in any other area, it
seems there can be multiple (more than 2) encapsulations. This
certainly has some TCP path MTU implications that need to be spelled
out.

->>Seems that this needs to be given more thought.

> Could you give an example of a case that could introduce a problem

The most interesting scenario I had in mind was with recursive TAs.
Here is a simple example that would be useful to think through:

 -+---B1---+-- Area0
  |        |
 [R1]     [R2]
  |        |
 -+---B2---+-- Area1

Assume that there are two TA1 between R1 and R2: TA1 belonging to
Area 0 and transiting Area 1, and TA2 belonging to Area 1 transiting
Area 0. The event to consider is when TAs go up and then segments B1
and B2 go down. Since both TAs are used in SPF, it is possible they
will use each other for resolution during SPF.

It's a little hard for me to write down a full analysis of this
scenario during the IETF week :) I'd appreciate if you looked at
this, and I'll try to do so on my flight back on Friday to see if
it really is a problem.

Cheers.
Alex

---

From: Sina Mirtorabi <[email-masked]>
Date: Wed, 12 Nov 2003 21:34:19 -0800

Alex,

->
->Sina,
->
->->>The draft relaxes this and suggests that the TA can belong to any
->->>area and can transit any area. This opens up a possibility for TA1
->->>that belongs to area A1 to transit area A2 that has TA2.
->This means
->->>that it could be possible for packets to be encapsulated more than
->->>once. It seems it could also be possible to have recursive TA
->->>resolution, e.g. in the case above, TA2 transiting area A1.
->
->> Yes, if TA1 has to transit over area 2 to go from ABR1 to
->ABR2 and its
->> shortest path goes over another TA ( that is another TA
->belonging to
->> area 2 exist ) then the packet could be encapsulated / decapsulated
->> one more time in the portion that TA2 traverse if they are
->multi-hop
->> but note that in any case the packet will be delivered to te remote
->> ABR and there should not be any problem.
->
->In general, because VL in any area can use a VL in any other
->area, it seems there can be multiple (more than 2)
->encapsulations.

I guess you mean TA ;-)
The usage of TA is pretty simple, i.e. use backbone area as a transit
area for non-backbone areas. this is true for

1) using high speed link of the backbone
2) in Hub and spoke topology have multiple TA over backbone link
3)  on demand partition repair for non-backbone area that are summarized

I personally fail to see why one would configure mutual TA, i.e. TA1
going through area X and belonging to Y and TA2 going through area Y and
belonging to X but even in those case there won't be a problem

->This certainly has some TCP path MTU
->implications that need to be spelled out.

Sure, we will add this in the next version

->
->->>Seems that this needs to be given more thought.
->
->> Could you give an example of a case that could introduce a problem
->
->The most interesting scenario I had in mind was with
->recursive TAs. Here is a simple example that would be useful
->to think through:
->
-> -+---B1---+-- Area0
->  |        |
-> [R1]     [R2]
->  |        |
-> -+---B2---+-- Area1
->
->Assume that there are two TA1 between R1 and R2: TA1
->belonging to Area 0 and transiting Area 1, and TA2 belonging
->to Area 1 transiting Area 0. The event to consider is when
->TAs go up and then segments B1 and B2 go down. Since both TAs
->are used in SPF, it is possible they will use each other for
->resolution during SPF.
->
->It's a little hard for me to write down a full analysis of
->this scenario during the IETF week :)

I know, it is pretty good that you responded I was expecting your e-mail
not before next week ;-)

->I'd appreciate if you
->looked at this, and I'll try to do so on my flight back on
->Friday to see if it really is a problem.

Ok

A) I bring up TA1 which transit through area 0 and belong to area 1,
initially its SPT is through link B1
B) I bring up TA2 which transit through area 1 and belong to area 0,
initially its SPT is through link B2
C) TA1 and TA2 could switch from direct link trough each other
D) B1 and B2 goes down
E) TA1 and TA2 are backing each other up

However the Hello will make sure that the TA will be brought down,
therefore we do need to send Hello over TA in those scenarios instead of
considering it as DC

Thanks
Sina

->
->Cheers.
->Alex
->

---

From: Acee Lindem <[email-masked]>
Date: Fri, 14 Nov 2003 10:40:45 -0500

This is in response to Sina's most recent post on this subject. I wanted to
reply to this E-mail to preserve Alex's example.

Hi  Sina,
I must be missing something since I don't understand why it wouldn't be
a problem
if you simultaneously lost physical connectivity through areas 1 and 2.
Without some
extra next-hop checking, it seems that area 0 could use the TA through
area 1 and
vice versa. Granted, packets would not be delivered and the adjacency
would go
down in RouterDeadInterval seconds (which in turn would result in the
TAs being
brought down).

I think it would simplify  implementation/debugging to say that a TA
should not be
considered up unless the best path through its transit area is not over
a another TA.

---

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

Acee,

->
->This is in response to Sina's most recent post on this
->subject. I wanted to reply to this E-mail to preserve Alex's example.

Let's take Alex example,

    TA1 belong to area 1
    ------>
 -+---B1---+-- Area0
  |        |
 [R1]     [R2]
  |        |
 -+---B2---+-- Area1
     ----->
    TA0 belong to area 0

->
->Hi  Sina,
->I must be missing something since I don't understand why it
->wouldn't be a problem if you simultaneously lost physical
->connectivity through areas 1 and 2. Without some extra
->next-hop checking, it seems that area 0 could use the TA
->through area 1 and vice versa.

Before links goes down TA0 and TA1 cannot goes over each other, say TA1
goes over TA0

1) When links goes down, if you don't notice that the links are down (
switch in the middle ) then nothing happen that is TA0 and TA1 are still
not going through each other and after the RouterDeadInterval TA are
delared down

2) If you detect that the link is down in that case the interface
associated with TA could be brought down and still TA are not going over
each other

In any case assuming that in 2)  we don't bring down the interface
associated with TA and since your physical interface is down you use the
other TA to announce adjacency But I do not see why this is different
than when a link is down and the time to detect it through Hello we
still announcing the adjacency over it ?

->Granted, packets would not be
->delivered and the adjacency would go down in
->RouterDeadInterval seconds (which in turn would result in the
->TAs being brought down).

Yes the important point is that even in those corner cases you still
have Hello to bring down the adjacency.

Thanks
Sina

->
->I think it would simplify  implementation/debugging to say
->that a TA should not be considered up unless the best path
->through its transit area is not over a another TA.
->
->Alex Zinin wrote:
->
->>Sina,
->>
->>->>The draft relaxes this and suggests that the TA can belong to any
->>->>area and can transit any area. This opens up a
->possibility for TA1
->>->>that belongs to area A1 to transit area A2 that has TA2.
->This means
->>->>that it could be possible for packets to be encapsulated
->more than
->>->>once. It seems it could also be possible to have recursive TA
->>->>resolution, e.g. in the case above, TA2 transiting area A1.
->>
->>
->>
->>>Yes, if TA1 has to transit over area 2 to go from ABR1 to
->ABR2 and its
->>>shortest path goes over another TA ( that is another TA
->belonging to
->>>area 2 exist ) then the packet could be encapsulated / decapsulated
->>>one more time in the portion that TA2 traverse if they are
->multi-hop
->>>but note that in any case the packet will be delivered to te remote
->>>ABR and there should not be any problem.
->>>
->>>
->>
->>In general, because VL in any area can use a VL in any other
->area, it
->>seems there can be multiple (more than 2) encapsulations. This
->>certainly has some TCP path MTU implications that need to be spelled
->>out.
->>
->>->>Seems that this needs to be given more thought.
->>
->>
->>
->>>Could you give an example of a case that could introduce a problem
->>>
->>>
->>
->>The most interesting scenario I had in mind was with recursive TAs.
->>Here is a simple example that would be useful to think through:
->>
->> -+---B1---+-- Area0
->>  |        |
->> [R1]     [R2]
->>  |        |
->> -+---B2---+-- Area1
->>
->>Assume that there are two TA1 between R1 and R2: TA1
->belonging to Area
->>0 and transiting Area 1, and TA2 belonging to Area 1
->transiting Area 0.
->>The event to consider is when TAs go up and then segments B1
->and B2 go
->>down. Since both TAs are used in SPF, it is possible they
->will use each
->>other for resolution during SPF.
->>
->>It's a little hard for me to write down a full analysis of this
->>scenario during the IETF week :) I'd appreciate if you
->looked at this,
->>and I'll try to do so on my flight back on Friday to see if
->it really
->>is a problem.
->>
->>Cheers.
->>Alex
->>
->>
->>
->

---

From: Peter Psenak <[email-masked]>
Date: Mon, 17 Nov 2003 10:45:25 +0100

Hi Acee,

> considered up unless the best path through its transit area is not over

just wondering how would you distinguish the TA link from any other p2p
link during SPF, given that the TA in each area can be configured
between different set of routers.

thanks,
Peter

---

From: Acee Lindem <[email-masked]>
Date: Mon, 17 Nov 2003 08:57:57 -0500

> between different set of routers.

Hi Peter,

I should have been clearer.  After you run an SPF for a transit area,
you need
to check the TAs to determine if they should be brought up/down or stay the
same (actually you could be smart about which ones you check). I'm proposing
to augment this checking to assure a TA's status is not "up" if the best
path
through a transit area is not via a different locally configured TA in
another transit area.

Make sense?  I could be missing something since this is all based on mental
simulation :^)

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Mon, 17 Nov 2003 15:14:19 +0100

Acee,

> through a transit area is not via a different locally configured TA in

above would work if both TAs are configured between same pair of endpoints.
I was wondering about the case, where two different TAs are configured
on different set of endpoints:

TA1 - endpoints: R1, R2; area 1; transit area 0;
TA1 - endpoints: R3, R4; area 0; transit area 1;

thanks,
Peter

---

From: Acee Lindem <[email-masked]>
Date: Mon, 17 Nov 2003 09:40:07 -0500

> TA1 - endpoints: R3, R4; area 0; transit area 1;

Seems like this could be a problem if R1 and R3 had physical
connectivity  in areas 1 and 0 and R2 and R4 also had physical
connectivity in areas 1 and 0.  What's more the packets would
loop until the TAs went down  due to hello timeout.