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

Re: Diverse inter-region path setup



Hi,

Kireeti plans to spend ten minutes discussing the strategy for inter-domain TE work within
CCAMP. This is on the agenda at:
- Inter-Area/AS
   - Strategy (Kireeti) (10 minutes)

We hope that he will answer your questions at that time and outline the way forward.
Of course, we will welcome a brief discussion of the right way to proceed at that time.

Thanks,
Adrian

----- Original Message ----- 
From: "Alessio D'Achille" <alessiored@fastwebnet.it>
To: <ccamp@ops.ietf.org>
Cc: <adrian@olddog.co.uk>; "Kireeti Kompella" <kireeti@juniper.net>; "Vishal Sharma"
<v.sharma@ieee.org>; "Ugo Monaco" <monaco@infocom.uniroma1.it>; "Fabio Ricciato"
<ricciato@coritel.it>; "Marco Listanti" <marco@infocom.uniroma1.it>
Sent: Monday, August 02, 2004 10:11 PM
Subject: Diverse inter-region path setup


> Dear all,
>
> with this mail we would like to focus the attention on the disjoint path
> computation issue, within the context of inter-area/AS TE.
>
> We believe that not addressing the disjoint path computation issue from
> the start (when looking at inter-area/AS TE) would be quite problematic,
> since an approach that works for a single inter-area/AS path may not be
> easily applicable/extendible for diverse path
> computation. This observation has been made earlier on ML discussions
> after the Seoul meeting, but there was no definitive conclusion at that
> time ( <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html>
> http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> and
> follows). In fact, in our view, the right way to approach this issue
> would be to develop an approach that that does not provide a solution to
> setup a single path and then attempts to extend that solution for the
> diverse path setup case.Rather, a solution
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> must provide
> a mechanism to setup disjoint paths, with the single path setup being a
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> particular
> case. This is because disjoint path setup is quite likely one of the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> more
> important aspects of inter-region TE, that is important for a no. of
> applications,
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> as pointed
> out in the requirements drafts.
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> We defined
> such an approach in our draft
> "draft-dachille-inter-area-path-protection-
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> 00.txt",
> discussed in Seoul (59th IETF) and it received many positive comments
> (see the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> minute of
> the meeting): in many comments it has been marked as an important work,
> since it addressed a hot issue within the Inter-area/AS topic.
> Following, the draft has been discussed on the CCAMP ML for about two
> months Recently we have reviewed our draft (namely
> draft-dachille-diverse-inter- region-path-setup-00), incorporating the
> feedbacks received at Seoul and via the CCAMP discussions that followed.
> Since there are significative changes, we recently asked for a slot
> during the 60th IETF, just to discuss the new version
> (http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html).
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> We would
> like to address two main themes:
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> i) clarifing
> why an approach to achieve diverse path setup from the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> start is now
> not considered in the inter-region TE solutions,
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
> notwithstanding it seems to be the right approach to the issue, as
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> observed in
> prior ML discussion and in requirement drafts.
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> ii) Since we
> believe that draft-dachille satisfies all the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> requirements
> for work to be discussed at a WG meeting
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
> (http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html),
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> we would
> appreciate clarification about the reasons that led to the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> exclusion of
> this work from the SD agenda.
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> Thank you
> for your kind attention; we hope that the discussion about
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> this issue
> could continue in a productive manner, just as usual.
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> Best
> Regards,
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> Alessio
> D'Achille
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>
>