From my experience I can quote everything
Igor said. GMPLS tunnel establishment is, AFAIK, always driven by the
NMS/OSS that (quoting Neil Harrison here) is the King.
So I think that in the real world the
Ingress node knows the upstream and downstream bandwidth of the GMPLS Tunnel is
going to set-up.
Moreover if I’ll use two
uni-directional LSPs in order to set-up an LSP with asymmetrical bandwidth
requirement I can force the path of the two LSPs to be the same? Do I
have to use the RRO of the first one as ERO for the second one? Or I
suppose to use a fully defined ERO for both the two LSP? In this case I
do suppose that the ERO has been calculated by the NMS?
Regards
Diego
From:
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin
Sent: domenica 4 marzo 2007 14.56
To:
Dimitri.Papadimitriou@alcatel-lucent.be; Adrian Farrel
Cc: ccamp@ops.ietf.org; Don Fedyk;
Igor Bryskin
Subject: Re: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt
Adrian and Dimitri,
When a GMPLS tunnel is setup, it is setup for a reason. Let's say,
management plane requests a tunnel ingress node to setup a tunnel. The request
may not (and normally does not) contain an explicit path, but it definitely
contains all bandwidth parameters, because the tunnel was requested, as I
siad, for a particular reason (application, SLA,
etc.). Also, how else you can ensure the fate sharing other than computing a
path on the ingress node taking in consideration the bandwidth requirements for
both directions?
So, yes, I'd say that it is safe to assume that ingress node always knows about
bandiwidth in both directions.
I'd say even more. We have a strict requirement from our customers that
actively deploy our GMPLS CP, that a communication between management and
control plane should always hapen at one (ingress) node.
Igor
PS It would be interesting to hear from providers on this topic.
Dimitri.Papadimitriou@alcatel-lucent.be
wrote:
"Adrian Farrel"
04/03/2007 00:35
Please respond to "Adrian Farrel"
To: "Igor Bryskin" , Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: , "Don Fedyk"
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
It's here! Your new message!
Get new
email alerts with the free Yahoo!
Toolbar.