[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Limitations overcomed by ARO



John,

Thanks for the note. I am providing some quick answers
to your queries, and have taken the liberty of cc'ing
the CCAMP ML as well, since this discussion is very
relevant to the ongoing discussions on the list.

Actually, there are several options with crankback, and several
ways to ensure that crankback (if it occurs at all; this
should be a rare event in most normal circumstances) is
minimal.

Fabio plans to post a more detailed response on the list,
and we'll cc you on it or point you to it, once that is
posted.

Also, please note that this scheme has the ability to make
possible diverse path setup with crankback (if
it becomes necessary), particularly when there is a trap topology,
whereas some other sequential schemes can fail completely, requiring
the entire primary and secondary to be setup from scratch.

Regards,
-Vishal

> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net]
> Sent: Thursday, April 29, 2004 9:36 AM
> To: v.sharma@ieee.org
> Subject: FW: Limitations overcomed by ARO
>
>
> Vishal,
>
> Isn't it true that the two routes must necessarily follow the same set of
> AS/areas?

No. Actually, the two routes can follow disjoint areas/AS's, and this is
handled via partial ARO/ERO expansion.

Although this is explained in the draft (Sections 4.2 and 4.3.3), it is one
aspect that we plan to explain better in the revision.

Fabio et al, have a more recent paper on the subject presented at
the Int'l Workshop on Inter-domain Perf. and Simulation (IPS2004)
http://w3.tmit.bme.hu/ips2004/, that explains this more clearly.

I think they will be happy to send you a copy, if you (or others)
are interested.

> Also, isn't it true, that you will have to use
> crankback in order
> to back out of traps?  E.g., there are three ingress ABRs and you
> enter the
> area with ABR 1, but ABR 1 determines that the only way to
> transit the area
> is to go through ABR 2 and ABR 3.

If the "trap" is because of a lack of resources and/or failure,
then any set up scheme would have to backtrack.
The former indicates that the problem needs to be handled at
the network planning level, the latter is just an unavoidable
situation.

But, as observed earlier, some schemes will necessicate a setup
from the beginning for both the primary and secondary (or, more
correctly, the two diverse paths), whereas this scheme does not.

Otherwise, depending on the topology (we assume there are at least
two exits out of every AS), one will usually need to backtrack no
more than one hop.
(Also, since ABR1 can still actually compute what the paths across its
AS should be, it can put that in the crankback message that it returns
to the ABR in the previous AS.)

> -----Original Message-----
> From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com]
> Sent: Thursday, April 29, 2004 9:18 AM
> To: dachille@coritel.it; listanti@infocom.uniroma1.it;
> monaco@infocom.uniroma.it; ricciato@coritel.it; v.sharma@ieee.org
> Cc: ccamp
> Subject: Limitations overcomed by ARO
>
> Alessio, Marco, Ugo, Fabio, Vishal,
>
> As I understand this draft overcomes the following
> limitations:
>                   ".... we propose an alternative approach, based on the
> joint
>                   computation of the two paths in a distributed manner,
>                   which overcomes ..."
>                  "... two main limitations:
>                     - Trapping
>                     - Sub-optimal route selection "
>
> Could you please confirm if the following can be overcomed using the
> scheme described (quoted below) in the draft :
>
> * Can the path setup for the first LSP (computed by the head-end) lead
> to trapping in the
> second area or sub-optimal route selection if the head-end node only has
> link state information of the first  areas
> * Can an ABR in Area 1 & 2 compute paths to avoid  trapping in Area 3 if
> the ABR in Area 1 & 2 only has link states of these 2 areas?
>
>
>                  "While the
>                   path of the first LSP - that is, the one being
> installed during the
>                   first phase - is included in the ERO, the route of the
> second LSP -
>                   which will be installed in the second phase û will be
> collected in
>                   the ARO during the first phase itself. At the end of
> the first phase,
>                   the ARO collecting the e2e route of the second LSP is
> returned to the
>                   head-end node, which can then install it as an
> ER-LSP." ?
>
>
> * Can a head-end node in AS1 avoid trapping in the network if the
> head-end node only knows
> about link states in AS1 and the virtual links to other ASes?
>
>                  "... can model a multi-AS network.
>                  ... JSA minimizes the number of areas that
>                   the two LSPs share, and if two area-disjoint paths are
> present in the
>                   network, JSA can compute them;"
>
>                  "Node A computes two disjoint paths between itself and
> B,
>                                within area 1, with a inter-area
> topological view as
>                                shown in Fig. 5b; in this case, node A
> MUST prune all
>                                the border nodes, except one for every
> area connected to
>                                area 1, before the disjoint route
> selection algorithm is
>                                performed; as a result, the two LSPs will
> not cross the
>                                same next area, and will follow the
> computed inter-area
>                                path.
>
>
> Thanks
> Cheng-Yin