RE: Proposed strategy for Inter-area/AS (corrected)

["Vishal Sharma" <v.sharma@ieee.org>]

Hi JP,

Thanks much for your comments. Response in-line.

(Please ignore the previous message, as the ASCII figure
got distorted in that one.)

> -----Original Message-----
> From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com]
> Sent: Friday, April 16, 2004 2:58 PM
> To: v.sharma@ieee.org
> Cc: Adrian Farrel; ccamp@ops.ietf.org; Kireeti Kompella; Arthi Ayyangar
> Subject: RE: Proposed strategy for Inter-area/AS
>
>

<snip>

> > >
> > > 1. Framework for Interdomain MPLS and GMPLS
> > >     A short draft that introduces the routing and signaling options
> > >     for multi-domain LSPs, and explains the options for path
> > >     computation.
> > >     This does not describe applicability or any necessary protocol
> > >     procedures or extensions.
> > >     Material will be taken from draft-vasseur-ccamp-inter-area-as-te
> > >     and draft-kompella-mpls-multiarea-te as required.
> > >     Authors: Adrian, JP, Arthi
> > >     Due date: End of April.
> >
> >As I mentioned at Seoul, I will be happy to help here. Particularly,
> >with adding some material on options for diverse path computation.
> >The current draft-vasseur-ccamp lists two options, but a hybrid
> >that involves partial path computation in each domain (along the
> >lines of what I presented at Seoul) is also possible, and can be a
> >useful tradeoff for meeting several of the requirements listed
> >in the corresponding requirements drafts.
> >
> >Also, I am assuming that the TE requirements documents will be
> >the guiding documents in presenting options for routing/signaling
> >and path computation in the above doc. I think it is important
> >that the framework draft be in synch. with the requirements documents,
> >rather than applying them only for 4 and 6.
>
> Sure,
>
> But I guess that the solution that you propose to compute path
> diversity is
> one among others. Indeed, there are two path computation
> solutions proposed
> in draft-vasseur-ccamp-inter-area-as-te that both support path diversity
> computation:
>          (1) Per-area/AS in combination with EXCLUDE-OBJECT
>          (2) Distributed PCE-based approach which compute end to end
> shortest path that can also easily support diversity path computation with
>          a high granularity
>
> Whether a third method can of course be debated.

Actually, the way I see it, there are I believe 4 basic ways to perform
path (and diverse path) computation, which we can break down as follows.


             (Diverse) Path Computation Methods
                           |
                           |
                           |
             +-----------------------------+
             |                             |
             |                             |
       Centralized                     Distributed
        (Global)                           |
            |                              |
      +-----+------+                   +---+--------------+
      |            |                   |                  |
   Parallel      Sequential          Parallel           Sequential

  Joint path    1st path, 2nd path   Per-domain           1st path, 2nd path
 computation    ...                  path selection       ...
       |              |                (semi-global)         |
       |              |                |                     |
       |              |                |                     |   Approaches
       |              |                |                     |   -----------
  -PCE-based    -Head-end based        |                     |           ]
                 or PCS-based        -PCE-based              -Using XRO  ]
                                                                         ]
  -Head-end or                       -draft-dachille based               ]
   server-based


The various current approaches/solutions to perform path computation may
be classified under one of the 4 heads, as I have done above.

I called solution we proposed in draft-dachille (and that I presented in
Seoul)a hybrid for computing diverse paths, because it can compute
end-to-end
diverse paths like in the PCE approach, with the simplicity of the
per-domain
approach,and essentially without any changes to the signaling protocols
(save for an ERO-formatted ARO obj.),
which is a requirement stated in the inter-area/AS TE requirements drafts.

Thus, I believe this solution (not the specific realization presented in
draft-dachille, but rather the basic idea) is worth mentioning in the
interdomain TE framework document.

Best,
-Vishal