Subject: Re: LSP setup across IGP areas

From: Senthil Venkatachalam <[email-masked]>
Date: Thu, 07 Sep 2000 16:10:34 -0400

Hi Darek,

Thanks for your comments, sorry for the delay in our reply
as we were caught up with other stuff..

Please find our comments inline:

Skalecki, Darek (EXCHANGE:CAR:9K12) wrote:

> I have a couple of questions/comments in association with
> draft-venkatachalam-interarea-mpls-te-00.txt about LSP setup across IGP
> areas.
>
> 1. In section 4.4 (Routing algorithm):
>
>    6. If the destination is in this area, calculate an intra-area route
>       from the originating node to the destination that satisfies the
>                ^^^^^^^^^^^^^^^^
>       constraints, and splice the egress of the original LSP and the
>                                                 ^^^^^^^^^^^^
>       ingress of the new LSP.
>
> Shouldn't it be transit ABR instead of originating node, and also upstream
> LSP instead of original LSP.
>

Yes, you are right. The algorithm should be reworded to describe the
creation of each LSP section, the head of which is either the
originating node or the head ABR of the section.

"originating node" should be "head node of the new LSP section"
and
"original LSP" should be "upstream LSP section"

>
> 2. Is there some special software entity besides the signaling entity
> (RSVP-TE or CR-LDP) at ABR that splices upstream LSP section to downstream
> LSP section. Is this entity what you call routing process in step 4 of
> section 4.4. Is this entity responsible for intercepting LABEL_REQUEST and
> PATH (as well as other CR-LDP and RSVP) messages at ABRs.
>

The two major entities are signaling and routing entities. Our proposal does
not add any new componets
to the LSP setup mechanisms. The only extensions we have to support our idea
is to extend these
components to use primary and secondary criteria related concepts at the
ABRs.

>
> 3. About crankback. It is stated that crankback is to the previous nearest
> ABR from the point of failure. At that ABR the routing algorithm by
> routing process is repeated.  Is there any mechanism that prevents the
> selection of the same ABR as was used previously. For example, refering to
> the following example
>
> Area 1                      Area 0                    Area 2
> --------------------    ------------------     ------------------------
> |                  |    |                 |    |                       |
> |  |N1  PPS1       -------    PPS3       --------      PPS5      |N2   |
> |  |-------------- |ABR1  |--------------|ABR 2 |--------X-------|     |
> |  |-------|       -------               -------- --|PPS7 |------|     |
> |   PSS2   |       -------    PSS4       --------   |-----| PSS6       |
> |          --------|ABR 3 |--------------|ABR 4  |---------            |
> |                  -------               --------                      |
> |                  |    |                 |    |                       |
> --------------------    -------------------    -------------------------
>
> Let's assume PPS5 failed and we initially cranked back to ABR 2 but there
> was no intra-area route to the destination so we cranked back to ABR1. At
> ABR1 when performing the algorithm of section 4.4 we should not consider
> ABR2 as this is from where we cranked back and we know that ABR2 already
> tried unsuccessfully to route to the destination.
>

Good point. In our companion draft
(draft-dharanikota-interarea-mpls-te-ext-00.txt), we have to extend
the signaling error conditions to include the ABR information, which is not
considered presently. We will
include it in the next revision. Using this ABR information, the routing
protocol can prune the ABR from its
calculation, and hence avoid it in the next attempt.

>
> Also, routing in response to crankback really depends on whether the
> failure causing the crankback was within the current area or another
> downstream area. If it was within the current area then same downstream
> ABR can be selected. If it was outside of the current area then a
> different ABR should be selected. For example, if PPS5 fails and we crank
> back to ABR2 then to ABR1 (as I eluded to above) then ABR2 should not be
> considered when routing at ABR1. On the other hand, if PPS3 fails and we
> crank back to ABR1 then ABR2 should be considered.
>
> 4. Have you given some thought to the idea that an LSP section failure in
> one area should not have an effect on surrounding LSP sections in other
> areas. For example, refering to the above picture, if PPS3 fails then
> another intra-area route through Area 0 between ABR1 and ABR2 is computed
> and LSP section reestablished along that route without affecting LSP
> sections PPS1 and PPS5. This would be similar to "local repair" where
> local = area.
>

Local repair is an interesting concept, in conjunction with our draft -
it will be a good candidate for the next revision.

> Cheers,
> Darek

Thanks and appreciate your comments,
Senthil & Sudheer.

--
Senthil K. Venkatachalam     [email-masked]
Off#:4223, MBox:             (703) 654-8635 [Off]
Alcatel USA                  (703) 654-8272 [Fax]
__________________________________________________________________