RE: Proposed strategy for Inter-area/AS

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

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

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Friday, April 16, 2004 12:57 PM
> To: v.sharma@ieee.org; ccamp@ops.ietf.org
> Cc: Arthi Ayyangar; Jean-Philippe Vasseur; Kireeti Kompella
> Subject: Re: Proposed strategy for Inter-area/AS
>
>
> 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.
>
>
>