Re: Multi-Area TE Protocol Extensions

["Cheng-Yin Lee" <[e-mail]>]

Hi Dimitri,

[e-mail] wrote:

> 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),

Ok, I see. Clarifying the scope of the problem that the ID addresses, is definitely useful.

> 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 -

Understood.

> ps: this said there are plenty of ways to avoid to
> deal with specific application usage within the core
> of the document specifications

Sure.

thanks
cheng-yin


>
>
> thanks,
> - dimitri.
>
> [e-mail] 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
> >
> > [e-mail] 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, [e-mail] 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 : [e-mail]
> > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > > >E-mail : [e-mail]
> > > > >Public : http://psg.com/~dpapadimitriou/
> > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > > >Phone  : Work: [phone] - Home: [phone]
> > >
> > > --
> > > Papadimitriou Dimitri
> > > E-mail : [e-mail]
> > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > E-mail : [e-mail]
> > > Public : http://psg.com/~dpapadimitriou/
> > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > Phone  : Work: [phone] - Home: [phone]
>
> --
> Papadimitriou Dimitri
> E-mail : [e-mail]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [e-mail]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: [phone] - Home: [phone]