[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Hi Igor.
Please, find my answers in-line.
Regards,
Julien
-----Original Message-----
From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Julien,
Please, see in-line.
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Hi all.
To answer the 1st question, I would say that there is a requirement for
asymmetrical bidirectional *service* (think about IP TV transport for
instance). What is more, as Igor said, being able to handle both
directions as a single service brings advantages (such as fate sharing),
especially in terms of operating a network. Question is: does this
necessarily map to "single LSP"? Not so sure...
Then, I do not see any strong requirement for having a single signalling
exchange.
IB>> Well, if everything goes smoothly, the setup of a single
bi-directional LSP is twice as fast as the setup of two unidirectional
LSPs. If there are some provisioning problems, then the difference may
be much bigger. Think about the situation when there is a resource
allocation failure for the opposite direction on the service node, say,
next after the ingress. If you setup a single bi-directional LSP the
failure is detected almost right away, the path is recomputed and LSP is
re-routed. However, if you setup two reciprocal unidirectional LSPs, the
failure won't be even detected before the Path message for the second
LSP arrives on the failure detecting node. And now you will have to
signal the release of both LSPs and start the whole setup again. So, the
recovery time won't be all that great, don't you agree?
[JM] I agree with you. That is why, for recovery, a node should not rely
on a third party (such as a manager or the other end-node). However, you
are only saying that a single LSP may fit the requirement, but I still
cannot say that the requirement leads only to this exact solution. :-)
Besides, I do not think a scenario with a management system
communicating with both end-nodes should be excluded neither. However,
in this case, it may be detrimental for the control plane to rely on an
external party to correlate both directions.
IB>> My customers say that if one set's up a soft-PVC and one needs to
access both edges of the soft-PVC, one might just touch all other nodes,
that is, setup a PVC instead. They believe that it is a significant
advantage to be able to control service from one node. That's what makes
the service provisioning *dynamic*. Frankly, as I see it the only
situation for the management plane to access nodes other than ingress is
when there is a problem with the CP. For example, one of the controllers
went out of service and there is a need to tear down or reroute the
service.
[JM] I do not think it is an issue of communication sessions. A PVC does
not provide with the same kind of services as a soft-PVC, whether it
rely on a bi-directional or 2 uni-directional LSPs: differences are
deeper than only head-node handling. Of course it is an advantage to
control the service from a single point (node, manager...), but I do not
see how provisioning from 2 nodes makes it less dynamic than
provisioning from one node... Anyway I admit that it may ease automatic
end-to-end provisioning in case of multi-layer or multi-domain services.
Can you give me other examples when such need arises?
[JM] I think if you want use the information in MIBs, you need to
communicate with all nodes... From my point of view, the requirement is
managing from a single *point* and defining this point as a node is only
*a* (valuable) solution.
Thanks,
Igor
Diego, to answer you, I think you are correct: re-using the RRO of the
1st one is an option to consider when routing by the controling plane,
and using management-built ERO for both directions is valid in case of
manual routing. As a result, it looks like tools are there to for
provisioning, nevertheless it may bring an issue to guarantee fate
sharing in case of recovery.
Regards,
Julien
________________________________
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Diego Caviglia (GA/ERI)
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
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