Subject: I-D ACTION:draft-venkatachalam-interarea-mpls-te-00.txt

From: [email-masked]
Date: Wed, 16 Aug 2000 06:49:39 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: A Framework for the LSP Setup Across IGP Areas for 
                          MPLS Traffic Engineering
	Author(s)	: S. Venkatachalam, S. Dharanikota
	Filename	: draft-venkatachalam-interarea-mpls-te-00.txt
	Pages		: 15
	Date		: 15-Aug-00
	
In this draft, we propose architecture for the inter-area LSP setup 
based on criteria (combination of constraints). We derive the
architectural requirements for the routing protocols, signaling
protocols and the MIBs to support such an idea. We also demonstrate
how such a mechanism will reduce the crankback during LSP setup.
A possible outline of the modifications to the CSPF algorithm and
examples are presented. In the companion document [INTER_AREA_EXT]
we elaborate on the extensions required for such architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-venkatachalam-interarea-mpls-te-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-venkatachalam-interarea-mpls-te-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-venkatachalam-interarea-mpls-te-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Darek Skalecki" <[email-masked]>
Date: Thu, 17 Aug 2000 11:10:51 -0400

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.
>
> 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.
>
> 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.
>
> 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.
>
> Cheers,
>
> Darek
>
>
>

---

From: "Darek Skalecki" <[email-masked]>
Date: Wed, 16 Aug 2000 11:19:43 -0400

I have a couple of questions/comments in association with
draft-venkatachalam-interarea-mpls-te-00.txt about LSP setup across IGP areas.

   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.

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.

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.

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.

Cheers,

Darek