Re: Multi-Area TE Protocol Extensions
Dimitri.Papadimitriou@alcatel.be Wed, 11 December 2002 17:30 UTC
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Dec 2002 09:28:33 -0800
Message-ID: <3DF77635.B37A4905@alcatel.be>
Date: Wed, 11 Dec 2002 18:30:29 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: Optical Network Architecture (NTA - Antwerpen)
MIME-Version: 1.0
To: Cheng-Yin.Lee@alcatel.com
Cc: Jean Philippe Vasseur <jvasseur@cisco.com>, sachin laddha <sachinl@internettrends.co.in>, mpls@UU.NET, ccamp@ops.ietf.org
Subject: Re: Multi-Area TE Protocol Extensions
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
hi, my suggestion based on the jp's comment was to scope the examples and usage scenarios in this i-d to have at the end some material for the coverage of constraint passing methods in the ma-te context (i interpreted the remark of jp as follows, it is not cristal clear to see how this method applies to ma-te), also discussion from ietf 53 is settled we don't cover inter-as for the time being at the ccamp wg - fyi te wg has just start the discussions on inter-as te thus we first wait for their input... and then we see based on their results - ps: this said there are plenty of ways to avoid to deal with specific application usage within the core of the document specifications thanks, - dimitri. Cheng-Yin.Lee@alcatel.com wrote: > > 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 -- 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
- Re: Multi-Area TE Protocol Extensions Dimitri.Papadimitriou
- Re: Multi-Area TE Protocol Extensions Cheng-Yin Lee
- Re: Multi-Area TE Protocol Extensions Dimitri.Papadimitriou
- Re: Multi-Area TE Protocol Extensions Jean Philippe Vasseur
- Re: Multi-Area TE Protocol Extensions Dimitri.Papadimitriou
- Re: Multi-Area TE Protocol Extensions Jean Philippe Vasseur
- Re: Multi-Area TE Protocol Extensions Cheng-Yin Lee
- Re: Multi-Area TE Protocol Extensions Dimitri.Papadimitriou
- Re: Multi-Area TE Protocol Extensions Cheng-Yin Lee
- Re: Multi-Area TE Protocol Extensions Yakov Rekhter
- Re: Multi-Area TE Protocol Extensions Dimitri.Papadimitriou
- Re: Multi-Area TE Protocol Extensions Yakov Rekhter
- Re: Multi-Area TE Protocol Extensions Dimitri.Papadimitriou
- Re: Multi-Area TE Protocol Extensions Jean Philippe Vasseur