[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multi-Area TE Protocol Extensions
your impression is too affirmative wrt to my next reply
(i've never said that the xro mechanisms are restricted
to ma-te or that this i-d should be entirely dedicated
to it) also the intention of opening a charter item
implies imho structuring the content of proposals that
are on the table and that may further come in, this in
order to achieve common mechanisms in the scope of the
ccamp wg - in whatever i-d btw as long as it reproduces
the consensus of the wg (taking a look back at gmpls
signalling for instance you will see that it is the
concatenation of many individual submissions coming
from various horizons)
as said before, we have currently two methods on the
table 1) constraint passing and 2) path queries, the
first beneficiate from the fact it is the logical
evolution from loose routing (the next step) the other
uses signalling for querying a server, as such there
is one fundamental question underlying the latter:
moving features from distributed entities to the
centralized ones for path computation purposes solves
an intermediate problem (when a unique server is
available) that comes back when several centralized
systems have to interoperate but also one fundamental
protocol aspect (which is due to the methods currently
proposed) using a signalling protocol like rsvp to
explicitly query a server is clearly questionable (*)
- i think this should be clarified in the kompella i-d
since this is independent from the fact that the server
is collocated on an abr or along the lsp path - back
to previous method using constraint passing i would
say constraint-passing keeps the current philosophy
of rsvp-te since based on the implicit assumption
that each hop (in particular abr in ma-te context) are
capable to respond to the incoming request; is the
latter optimal, no of course; but i would say that at
the end the "simplest solution to this complex problem
will remain", well i think that rfc 3439 phrases this
principle much better than i do;
(*) understand this as a general remark people have
the tendency to overload/over-generalize the features
supported by a protocol and its applicability scope
thanks,
- dimitri.
Jean Philippe Vasseur wrote:
>
> Hi,
>
> At 10:43 11/12/2002 -0500, Cheng-Yin Lee 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.
>
> This was exactly my impression.
>
> JP.
>
> >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-r
> > oute-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