Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

[Dimitri.Papadimitriou@alcatel-lucent.be]

"Adrian Farrel" <adrian@olddog.co.uk>
04/03/2007 00:35
Please respond to "Adrian Farrel"
 
        To:     "Igor Bryskin" <i_bryskin@yahoo.com>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <ccamp@ops.ietf.org>, "Don Fedyk" <dwfedyk@nortel.com>
        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt


> 3. if a) is selected there is no other choice than an upstream flowspec 
in
> the Path msg and a upstream tspec in the Resv message

That *does* raise an interesting question. Namely, does the ingress know 
the 
bandwidth to request? If it does then there is no need for a TSpec on the 
Resv as the reservation has already been made commensurate with the 
FlowSpec 
on the Path.

-> if you do that you prevent the ingress-side to never adapt resource
reservation to the traffic parameters of the egress (in fact, it would
boil down to "single-sided" asymmetry forever)

-> hence, initially you must satisfy at least condition where flowspec 
=< tspec, nevertheless, after the tspec may "increase" and therefore 
the flowspec may be adapted 

If the ingress does *not* know and needs to see a TSpec from the egress, 
then we need another Path exchange after the Resv in order to make the 
actual reservations. In that case it really would be a mess and not worth 
trying to shoe-horn into a bidirectional LSP format.

-> this is what i said also to don, the case where initially the ingress 
is completely unaware of what it can reserve is impossible without major
protocol modifications

-> my partial conclusion, is that a workable asym bw lsp doesn't elevate
the need for the general case, and only provides apparent facilitation in
a corner case, whereas a technique making use of association object would
prevent all this protocol massaging, keep full backward compatibility, and
provide full flexibility


A