Re: Proposed strategy for Inter-area/AS

["Adrian Farrel" <adrian@olddog.co.uk>]

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" <v.sharma@ieee.org>
To: "Adrian Farrel" <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>; "Kireeti Kompella"
<kireeti@juniper.net>
Cc: "Arthi Ayyangar" <arthi@juniper.net>; "Jean-Philippe Vasseur" <jvasseur@cisco.com>
Sent: Friday, April 16, 2004 7:40 PM
Subject: RE: Proposed strategy for Inter-area/AS


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