The MPLS WG Archive

["Cheng-Yin Lee" <Cheng-Yin.Lee@alcatel.com>]

JP, Dimitri,
My understanding is that ITU-T SG15 architecture/requirements do allow both a
"distributed" and "centralized" approach and that perhaps the PCS  (btw, the Path
Computation Entity is a functional element, not necessarily a device/server, hence
Path Computation Entity/Component or something not denoting device may be more
appropriate) approach may be more appropriate there.

Both approaches may have its place in networks but perhaps SG15 may be a better place
to advance the PCS/PCE approach? Just my 0.02 cents.

regards
cheng-yin

Dimitri.Papadimitriou@alcatel.be wrote:

> hi jean-philippe,
>
> see in-line...
>
> Jean Philippe Vasseur wrote:
> >
> > 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, ....
>
> i referred here to the "signalling" based methods (i should
> have said before, sorry) hence, i think we should scope the
> discussion to these two here for the time being
>
> > 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.
>
> me too
>
> > >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.
>
> it is not "required" but your last sentence clearly
> indicates it will become rapidly a "recommendation"
> this clearly puts limits to the current applicability
> of this method - see also here below - and i think it
> would be wise to start thinking about scoping this
> approach (in case).
>
> > >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 ...
>
> when i say questionable, i don't want to enter into the
> arcane of protocol philosophy but the protocol consistence
> & evolution - imho i think this is part of our common
> responsibility as ietf'ers - this said take this as a
> technical discussion, please (no bad intentions here)
>
> > 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,
>
> this i-d describes in details the new messages, objects and
> their usage but i don't see any detail about how RSVP works
> in this case ? would you please go first by yourself into
> the details of what's the use of the mandatory objects in
> that context and their semantic wrt respect to their current
> use ? this would help me really to understand the rationales
> behind this method - the issue is as follows there is no
> clear explanations on why rsvp re-use is a key in enabling
> a path query between a client and a server, except from the
> fact it is already used but for resource reservation -
>
> you've said "without impacting its scalability", first you
> should clarify from which viewpoint since due to the above
> point it is probably a method that complexifies when the
> #pcs > 1 thus i would only consider that #pcs = 1 (in a
> first approach) now, if you refer to the installed and
> running distributed rsvp-te software on the routers and
> other switches from the client side it seems the case since
> you have to maintain a session (but do i have to call it a
> session in this context ?) with one pcs and even if you have
> several sessions (?) you would at most double or triple their
> number so it is clearly limited, the problem is in the other
> way around, where you have a factor n (at least), n being
> the number of nodes; if each of these nodes maintains m flows
> (with m>>1) well the question becomes that the dimensioning
> of the number of lsp's is dependent of the capabilities of
> the pcs (thus in addition, it seems you have introduced a
> new issue in network dimensioning) imho scalability with
> respect to the pcs (in particular wrt to rsvp usage) imho
> would deserve more words in this i-d in particular when
> running on the same device than the one(s) along the lsp.
>
> >          - re use all the existing objects,
>
> this re-use is clearly what i refer to here, i clearly
> understand the use of the new objects but what about the
> <SESSION>, <sender_descriptor> etc. what do they represent
> in this context ?
>
> you will see that this discussion is exactly the one that
> we would have in defining a new application, but where i
> see another point here one start to use rsvp as p2p tunnel
> to transport the info for such kind of applications
>
> >          - 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.
>
> well you have really point out the two alternatives
> sitting at the both end of the solution spectrum
>
> > I won't go in the philosophical aspects ... Note that IGPs/RSVP have not
> > been designed to carry Optical/SDH/SONET/...
>
> well let me point out here they don't carry sdh, they
> extend the set of bandwidth request encoding (as such
> no change in the orientation of resource reservation
> of this protocol)
>
> > 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.
>
> using your words:
>
> 1) constraint-passing would be then much more pragmatic
> (since you don't have to implement one new message, only
> new objects) and this without impacting existing approaches
>
> 2) if one has to implement a new message with new semantic
> (outside of the scope of resource reservation even in a
> generic sense) then we can legitimatelly "ask" the question
> why not a dedicated protocol for it running over udp;
>
> and this is probably the way to go for this method use
> all the object encoding, errors and s.o. without being
> obliged to maintain backward semantic with rsvp itself
> this is what the ccamp wg did with lmp and i don't think
> this is unfeasible in this case, however i would say
> that this would solve only the easy part of the problem
> (the issue of what happens in case of multiple pcs that
> runs in parallel is still for me an open issue)
>
> > 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 ?
>
> the following paragraph says:
> " Once the path computation server computes the path, if the server is
> not along the path, the server is no longer responsible for  maintaining
> the feasibility of the path (for one thing, the server may not even know
> whether the LSR established the path in the first  place)."
>
> the "if the server is not along the path" is not a
> condition, this applies independently of the condition
> the lsp is along the path, this should be clarified
> otherwise the above paragraph requires that you have
> to maintain the state of the computed path and the
> actual lsp on abr's for instance! but this is this
> may be what you intend to propose ? but in this case
> i don't see this clearly this i-d (is my understanding
> right here ?)
>
> > >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.
>
> of course, the whole ietf community is kindly invited
> to provide comments and input !
>
> thanks,
> - dimitri.
>
> > 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
>
> --
> 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