Subject: Proposed strategy for Inter-area/AS

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 14 Apr 2004 12:49:56 +0100

All,

JP and Arthi have done a fine job of pulling together all of the threads of inter-area and
inter-AS solutions into a single draft. This gives us a single place to look for
information, but the resulting draft is (of course) quite large. As additional details
need to be filled in, it is clear that this draft would only grow and that would make it
unusably large.

So, we are proposing to use the material in the draft to produce a series of detailed
drafts that would, over time, replace JP and Arthi's document.

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.

 2. Individual signaling extension drafts
    If any one of the signaling approaches described in 1.
    requires additional protocol procedures or extensions
    then a single draft will be written for each.
   The base assumption is that such a draft will only be
   written if there someone planning to implement and
   deploy.
   Authors: Dependent on extension
   Due date: Aim for San Diego

 3. Individual routing extension drafts
    There are two dimensions to this:
     - the different routing protocols (IGPs and EGPs)
     - the different solution models
     The aim should be to have one draft per protocol to provide the
     generic mechanisms, and one draft per model per protocol to
     provide procedures and field values etc.
     Note that path computation functions are described under point
     5, below.
     As with the signaling extensions, this work will only be done once
     we understand that there is a need *and* what is needed.
     Authors: Again dependent on deployment plans
     Due date: Slightly later than signaling work

 4. Applicability
    A draft to explain when it is appropriate to use which model and
    options. The aim is not to rubbish the opposition, but to say when
    a particular model can/should be used.
    Much of this material can already be found in
    draft-vasseur-ccamp-inter-area-as-te, but it may need
    some tidying up.
    For political/expediency reasons this may result in multiple
    applicability drafts in the first instance.
    Authors: A supporter of each model
    Due date: Quite soon - to accompany signaling extensions.

5. Path computation
    Some solution models call for a (or many) path computation
    servers (PCS). This demands several functions:
    - discovery of PCS by network elements
    - communication protocol between PCS and network elements
    - some regulation of computation technique to avoid looping etc.
    At the moment we are discussing precisely where this work should
    be done, but that should not stop us starting the work within CCAMP
    since it is clearly related to the inter-area/AS solution.

6. Advanced functions.
    There are several advanced functions that will be required, but which
    are not part of the immediate work.
    - Path reoptimization
    - Protection path diversity
    - crankback
     We expect that once the initial work has been done on the solutions, it
     will be possible to set out the requirements for these functions and to
     develop solutions based on the many drafts that are already out there.

Comments please.

Thanks,
Adrian and Kireeti

---

From: [email-masked]
Date: Thu, 15 Apr 2004 21:28:58 +0200

hi adrian, some comments in-line:

>     Authors: Adrian, JP, Arthi

is there an intention to take the tewg requirement documents into
account at some in time within the first step of the process ? or
are these documents their to assess solutions at the end of the
process (at step 4, and further, in particular 6)

>    written if there someone planning to implement and

can we make clear that mechanisms are expected to differentiate 
inter-area vs inter-as only as part of point 4 (applicability)
ie it is part of the task to provide generic signaling protocol 
extensions & procedures - as far as i see some of them will be
part of the last step -

>      provide procedures and field values etc.

do you mean one generic document (per solution model) and one
document per protocol or something else ?

>     Due date: Quite soon - to accompany signaling extensions.

if these reasons are verified, imho this should be part of each specific 
solution model/option document (if included into an appropriate 
section(s)), in order to avoid duplicating the number of documents that 
at the end should be put together in a single document that would 
include applicability of signaling (routing if any) procedure/ 
extensions and this due to the interaction aspects

>     since it is clearly related to the inter-area/AS solution.

and communication between PCSs once you have more than one PCS (~ sc.2 &
and sc.4 of draft-kompella)

>      develop solutions based on the many drafts that are already out there.

i see that you didn't include any specific timeframe for this one 
(probably wiser) but would it be possible to have a rough estimation 
when you think these could be considered (as crankback started since 
quite a few months as w-g item)

thanks,
- dimitri.

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: "Vishal Sharma" <[email-masked]>
Date: Fri, 16 Apr 2004 11:40:12 -0700

Hi Adrian and Kireeti,

Thanks for outlining the strategy for this important work
item, which I think is well-laid out.

Since some of the functions (e.g. diverse path computation, crankback,
etc.) are quite closely tied to the signaling and routing extensions needed,
I think they should not be decoupled from discussions of these extensions.
So the ordering below probably needs to be modified a bit to reflect this
coupling.

Some further comments/questions and suggestions in-line.

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Wednesday, April 14, 2004 4:50 AM
> To: [email-masked]
> Subject: Proposed strategy for Inter-area/AS
>
>
> All,
>

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.

>    Due date: Aim for San Diego

Please see initial note, about relation to other functions.

>      Due date: Slightly later than signaling work

Please see initial note, about relation to other functions.

Also, when you say "solution models" above, do you mean things
like a centralized versus a distributed model? What other
models did you have in mind?

>     since it is clearly related to the inter-area/AS solution.

Is the discussion referred to above about where the PCS model should
be done, or is it about path computation in general.

Will the other path computation models will be discussed within
CCAMP?

>      develop solutions based on the many drafts that are already

As I said earlier, some of these functions are coupled to the signaling and
routing extensions, so it would be useful to discuss the signaling and
routing extensions keeping some of these functions in mind.
Otherwise, we run the risk of developing signaling and routing extensions
first, and then retro-fitting them to accommodate such functions, which
I think are pretty key to inter-domain TE.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 16 Apr 2004 20:56:48 +0100

Hi Vishal,

Thanks for your useful comments.

Yes, clearly we need to consider all requirements as we move forward, but at the same time
looking for a single solution that does everything is often the kiss of death in the IETF.

So the first thing I want to do (in the framework) is set out the different basic models
for signaling, routing and computation. Then there is a bit of a hiatus while the
proponents of the different models work out what solutions they need and what their
applicability is - at this stage I would expect (since diverse paths are a requirement)
that you will find your self working with one or more of the solution groups. Similarly,
the other drafts that provide extensions that may be useful will also (or not) be called
on.

One thing the framework does not do is list all of the available bits and pieces. Nor does
it make any statements about what should or should not be done to provide a solution.

You may be right that adding a little more text on diverse computation models will help
since this will impact the choice of basic model, but I don't think it introduces any mode
basic models.
We will take you up on your offer of a contribution to the document as soon as we have got
the first version done.

On PCE...
We are open to discussions both about whether PCE should be done, and how it should be
done.

On TEWG requirements...
Obviously we take our base requirements from the TEWG documents.

Hope this clarifies.

Adrian

----- Original Message ----- 
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>; "Kireeti Kompella"
<[email-masked]>
Cc: "Arthi Ayyangar" <[email-masked]>; "Jean-Philippe Vasseur" <[email-masked]>
Sent: Friday, April 16, 2004 7:40 PM
Subject: RE: Proposed strategy for Inter-area/AS

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 16 Apr 2004 17:57:35 -0400

Hi Vishal,

>I think they should not be decoupled from discussions of these extensions.

Sure, path diversity is a requirement listed in the requirement draft

>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.

Cheers

JP.

---

From: "Vishal Sharma" <[email-masked]>
Date: Fri, 16 Apr 2004 15:55:29 -0700

Hi JP,

Thanks much for your comments. Response in-line.

> From: Jean Philippe Vasseur [mailto:[email-masked]]
> Sent: Friday, April 16, 2004 2:58 PM
> To: [email-masked]
> Cc: Adrian Farrel; [email-masked]; Kireeti Kompella; Arthi Ayyangar

<snip>

> 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)

  -PCE-based    -Head-end based                                           ]
                 or PCS-based        -PCE-based              -Using XRO   ]
Approaches
                                                                          ]
  -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

---

From: "Vishal Sharma" <[email-masked]>
Date: Sun, 18 Apr 2004 21:53:34 -0700

Adrian,

Great, thanks for the clarifications.

Since the framework takes its lead from the inter-area/AS requirements
documents, I agree that it needn't say what a solution should provide
(this should already be covered by the requirements docs.).

For the diverse path computation aspect, please see my response
to JP, where I've provided some elucidation.

Personally, I think the PCS/PCE approach is a useful one, and should
certainly be continued.

And, I'll be glad to contribute, once the first version of
the framework is done.

-Vishal

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Friday, April 16, 2004 12:57 PM
> To: [email-masked]; [email-masked]
> Cc: Arthi Ayyangar; Jean-Philippe Vasseur; Kireeti Kompella
> Subject: Re: Proposed strategy for Inter-area/AS
>
>
> Hi Vishal,
>

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 19 Apr 2004 14:44:07 -0700 (PDT)

Nice work breakdown Adrian.  Agree that the
applicability should be tackled early on.  On of the
issues that has been a problem in the past was of
differing applicabilities.
Thanks also for putting the drafts in once nice easy
to access place. The only one I didn't see there was
the kompella-multi-area-te draft that you mention
below.

Also agree in principle with Vishal's path computation
hierarchy.  When dealing with different granularity
signal types, e.g., from 1 or 2Mbps MPLS LSPs all the
way to lambda or waveband switched GMPLS LSPs
different methods are generally called for.  For
example, a distributed PCS approach would initially be
overkill, versus a centralized approach (not that many
LSPs to get set up that often) while if one is dealing
with lower rate  MLPS LSPs a distributed PCS approach
(hopefully) would be more  appropriate.

Just saw Alex's question on where the PCS work is... I
went looking for drafts to see where this is at...

Greg B.

P.S. Yes, consulting has picked up...
--- Adrian Farrel <[email-masked]> wrote:
> All,
> 
> JP and Arthi have done a fine job of pulling
> together all of the threads of inter-area and

		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash