[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed strategy for Inter-area/AS

hi adrian, some comments in-line:

Adrian Farrel wrote:
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.


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)

 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.

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 -

   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.


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

     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.

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

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.


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

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.

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.

Comments please.

Thanks,
Adrian and Kireeti



--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
E-mail : dpapadimitriou@psg.com
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491