Subject: Multi-Area TE Protocol Extensions

From: "sachin laddha" <[email-masked]>
Date: Tue, 10 Dec 2002 13:53:36 +0530

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

Regards,
---Sachin

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Tue, 10 Dec 2002 09:10:45 -0500

Hi,

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

---

From: [email-masked]
Date: Tue, 10 Dec 2002 17:45:41 +0100

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 

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)

thanks,
- dimitri.

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Tue, 10 Dec 2002 12:36:10 -0500

Hi Dimitri,

cc'ing CCAMP - see in line,

>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

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

---

From: [email-masked]
Date: Tue, 10 Dec 2002 20:43:27 +0100

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.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 10 Dec 2002 12:15:46 -0800

Dimitri,

> achieve a decent first step in this effort; 

On the subject passing constraint, I'd like to mention
draft-kompella-mpls-rsvp-constraints-00.txt (expired, but I could
provide a copy upon request). It contains a fairly general mechanism
for passing constraints in RSVP.

Yakov.

---

From: [email-masked]
Date: Tue, 10 Dec 2002 22:14:24 +0100

yakov, 

i think this i-d provides a fair amount of valuable 
input thus wouldn't be just better to submit an 
updated version (since the registers value should
be updated anyway) also it fits imho in the context 
of the ccamp even more largely than just for ma-te

thanks,
- dimitri.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 10 Dec 2002 14:03:43 -0800

Dimitri,

> of the ccamp even more largely than just for ma-te

I fully agree with you. I hope that the author of this i-d
would be kind enough to resubmit it.

Yakov.

> > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-ro
ute-
> > 01.txt
> > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-0
3.tx
> > t
> > > > > > >*       path-computation-server (PCS) functionality [kompella, lee
,
> > > > > vasseur,
> > > > > > >I want to know whether cisco/juniper routers (standard ones) suppo
rts
> > > > > 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 pre
ferr
> > ed

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 11 Dec 2002 10:43:41 -0500

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

---

From: [email-masked]
Date: Wed, 11 Dec 2002 18:30:29 +0100

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.

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 11 Dec 2002 13:02:19 -0500

Hi Dimitri,

[email-masked] wrote:

> 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

Understood.

> of the document specifications

Sure.

thanks
cheng-yin

---

From: [email-masked]
Date: Thu, 12 Dec 2002 23:25:16 +0100

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,
> This was exactly my impression.
> 
> JP.
> 
> > > > > > >I want to know whether cisco/juniper routers (standard ones)
> > supports
> > > > > all of
> > > > > > >the above extension.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Thu, 12 Dec 2002 15:22:14 -0500

Hi,

JP.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 13 Dec 2002 11:19:36 -0500

Hi Dimitri,

At 23:25 12/12/2002 +0100, [email-masked] wrote:
>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
>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

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 ?

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

> > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclu 
> de-r
> > > oute-01.txt
> > > > > >
> > > > >
> > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea 
> -te-
> > > 03.txt
> > > > > >
> > > > > > > >*       path-computation-server (PCS) functionality 
> [kompella, lee,
> > > > > > vasseur,
> > > > > > > >te-qos-routing],

---

From: [email-masked]
Date: Fri, 13 Dec 2002 21:03:09 +0100

hi jean-philippe,

see in-line...

> 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

> multi-area TE item, we will need to find a consensus and work on a single

me too 

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

> 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

> I personally vote for the pragmatic approach (1), let see other inputs on

well you have really point out the two alternatives
sitting at the both end of the solution spectrum
 
> 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

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

> Service Providers on which method(s) for inter-area TE better address their

of course, the whole ietf community is kindly invited
to provide comments and input !

thanks,
- dimitri.

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 13 Dec 2002 16:22:08 -0500

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

---

From: [email-masked]
Date: Sat, 21 Dec 2002 17:19:14 +0100

hi jean-philippe,

i re-send the below e-mail, in brief i would rather
suggest you provide a clear view on why rsvp as to 
be re-used for path query/response, but if you could
elaborate a bit more wrt to the below discussion
that wouldn't be completely useless for the ccamp
community

thanks,
- dimitri.