[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : Proposed strategy for Inter-area/AS
Hi Adrian and Kireeti,
I think this is a good strategy.
I have two comments:
1) As already mentionned by Vishal, we cannot, IMHO, decorrelate 6 from 1, 2 3 and 5.
-The support of additional functions may require important modifications, if they are not taken into account during the initial step of specifications.
-Path Reoptimization is a MUST requirement and Path diversity is a SHOULD requirement ( inter-area and inter-as reqt drafts). So we should not address them as advanced functions, but rather as base functions of the inter-area/AS tool-kit.
2) I'm not sure to well understand what do you put in 3.
What do you exaclty mean by routing model, and how do you distinguish it from the path computation model ? Requirement drafts clearly point out that routing (IGP, EGP) extensions should be avoided, except some minor extensions to advertise static parameters such as PCS capabilities for instance (addressed in point 5).
Hope this will help.
Regards,
JL
> -----Message d'origine-----
> De : owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] De la
> part de Adrian Farrel Envoyé : mercredi 14 avril 2004 13:50
> À : ccamp@ops.ietf.org
> Objet : 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.
>
> 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
>
>
>