The MPLS WG Archive

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Hi Dimitri,

At 23:25 12/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote:
>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

We probably have more ... we can also add some methods consisting on 
leaking part of the topology info into the areas, ....
But I do agree with you that once the CCAMP charter explicitly includes the 
multi-area TE item, we will need to find a consensus and work on a single 
document.

>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

I guess you are referring to the problem of multiple central systems 
sharing the path computation requests that indeed need to be in sync. That 
of course seriously increases the level of complexity but I do not think 
this is required. In the case of multi-area TE, a determined ABR 
(statically configured or dynamically discovered) can the THE PCS serving 
the requests for the LSRs residing within a specific area. In case of 
failure, a backup PCS can be used.

>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 (*)

Well, I would be more than happy to discuss this aspect of course, but not 
from a philosophical point of view ...
We have various options there:
(1) try to extend an existing protocol like RSVP. Note that 
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt 
requires to specify only one new message type and a single additional 
object (REQUEST-ID object). All the other objects are completely optional. 
All the LSRs have already an RSVP stack and this allows to reuse all the 
RSVP objects defined so far to pass the constraints to the PCS. So the idea is:
         - to slightly extend an existing protocol (with one new message 
type, one new object required) without impacting its scalability,
         - re use all the existing objects,
         - not require any additional protocol running on the LSRs
(2) re invent a new protocol from scratch ...
I personally vote for the pragmatic approach (1), let see other inputs on 
the list.

I won't go in the philosophical aspects ... Note that IGPs/RSVP have not 
been designed to carry Optical/SDH/SONET/...  infos either and I think one 
could mention many other examples like this and as a matter of fact they 
perfectly make the job. I personally think that if an exiting protocol can 
be slightly extended (without impacting its scalability, ... ) and can 
solve an actual problem, this option is preferable than trying to reinvent 
a new protocol from scratch.

Again I'll be more than happy to get more feed-backs on the list.

>- i think this should be clarified in the kompella i-d

What would you exactly want us to clarify in the 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

I am also hopping we will move forward on this discussion with the input of 
Service Providers on which method(s) for inter-area TE better address their 
needs.

Thanks.

Cheers,

JP.

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