Re: Multi-Area TE Protocol Extensions

"Cheng-Yin Lee" <Cheng-Yin.Lee@alcatel.com> Wed, 11 December 2002 15:43 UTC

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Dec 2002 07:46:53 -0800
Date: Wed, 11 Dec 2002 10:43:41 -0500
Message-ID: <3DF75D2D.4BE2F8BF@alcatel.com>
From: Cheng-Yin Lee <Cheng-Yin.Lee@alcatel.com>
Reply-To: Cheng-Yin.Lee@alcatel.com
To: Dimitri.Papadimitriou@alcatel.be
Cc: Jean Philippe Vasseur <jvasseur@cisco.com>, sachin laddha <sachinl@internettrends.co.in>, mpls@UU.NET, ccamp@ops.ietf.org
MIME-Version: 1.0
Subject: Re: Multi-Area TE Protocol Extensions
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dimitri, JP,
While I think an applicability section/statement is fine, I'm not sure if  a mechanism
to compute inter-area TE path belong in this  ID.

We did include applications in the first discussion of this ID and in the slides
http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html  and in addressing
Kireeti's suggestion to include a discussion on the impact of message size, we provided
an inter-area example for illustration purposes. However,  there have also been
suggestions in the past to not discuss applications specifically  in the draft itself.
I am fine with either way.

thanks
cheng-yin

Dimitri.Papadimitriou@alcatel.be wrote:

> jp,
>
> > this ID does not propose a mechanism to compute inter-area TE path
>
> well i would say that either none of them does it, or all of
> them, more accurately route exclusions are applicable to any
> mpls network where full computation of the ero is not performed
> before the LSP is signaled, implying thus a "scope" for computed
> path thus among other applicable to multiple areas - nevertheless
> i agree that a next version of this i-d should probably include
> an applicability section covering this in a bit more details (see
> also section 4.1 for an example -
>
> this said and as for any other input or i-d provided on constraint-
> passing (as well as path query, btw) lot of work is still needed to
> achieve a decent first step in this effort;
>
> thanks,
> - dimitri.
>
> Jean Philippe Vasseur wrote:
> >
> > Hi Dimitri,
> >
> > cc'ing CCAMP - see in line,
> >
> > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote:
> > >jp,
> > >
> > >in fact the below list should simply be as follows for
> > >signalling-based methods: 1) constraint-passing 2) loose
> > >routing and 3) path query;
> > >
> > >and the for constraint-passing we have a several i-d's
> > >such as,
> > >
> > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-01.txt
> > >
> >
> > this ID does not propose a mechanism to compute inter-area TE path
> >
> > >constraint passing may also be extended using the crank-
> > >back as listed below; the usage scenarios of these methods
> > >are described in the following:
> > >
> > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt
> > >
> > >now probably it is worth spending some time in considering
> > >input coming from the tewg wrt to this effort, most of the
> > >input that you see listed above has been produced over the
> > >past year (and more) i can't imagine stepping in the protocol
> > >details without a clear consensus on what do we want to cover
> > >within the ccamp wg & w/o taking into account the tewg rec's
> > >(probably better to discuss this on the ccamp mailing list)
> >
> > Fully agree with you. Hopefully multi-area TE should be soon part of the
> > CCAMP charter.
> >
> > JP.
> >
> > >thanks,
> > >- dimitri.
> > >
> > >Jean Philippe Vasseur wrote:
> > > >
> > > > Hi,
> > > >
> > > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > > >Hi,
> > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > > >"Initial requirements are given here for protocol support of the
> > > multi-area
> > > > >TE methods, which include needs to support
> > > > >
> > > > >*       path-computation-server (PCS) functionality [kompella, lee,
> > > vasseur,
> > > > >te-qos-routing],
> > > > >*       query functionality [query, vasseur],
> > > > >*       crankback functionality [crankback],
> > > > >
> > > > >and, optionally,
> > > > >
> > > > >*       TE feedback functionality [feedback], and
> > > > >*       summary-LSA functionality [summary_lsa]."
> > > > >.
> > > > >I want to know whether cisco/juniper routers (standard ones) supports
> > > all of
> > > > >the above extension.
> > > > >or if not,how many.......or Whether router is supposed to support how many
> > > > >...
> > > >
> > > > I do not think any vendor supports all the method mentioned above, but just
> > > > a subset. If you are running a network, your feed-backs on your preferred
> > > > method is very welcome.
> > > >
> > > > JP.
> > > >
> > > > >Regards,
> > > > >---Sachin
> > >
> > >--
> > >Papadimitriou Dimitri
> > >E-mail : dimitri.papadimitriou@alcatel.be
> > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > >E-mail : dpapadimitriou@psg.com
> > >Public : http://psg.com/~dpapadimitriou/
> > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
>
> --
> Papadimitriou Dimitri
> E-mail : dimitri.papadimitriou@alcatel.be
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : dpapadimitriou@psg.com
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361