Re: Proposed strategy for Inter-area/AS

[Greg Bernstein <gregbern@yahoo.com>]

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 <adrian@olddog.co.uk> 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.
> 
>  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
> 
> 




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