RE: Proposed strategy for Inter-area/AS

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

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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Adrian Farrel
> Sent: Wednesday, April 14, 2004 4:50 AM
> To: ccamp@ops.ietf.org
> Subject: Proposed strategy for Inter-area/AS
>
>
> 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.

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.

>  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

Please see initial note, about relation to other functions.

>  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

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?

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

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?


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

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.