[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Hi Julien,
The point is that having a single session has its benefits in some cases
(as pointed out in previous postings) but to leverage this the
applicability is limited (again pointed out previously, e.g., single
sided control) compared to a general RSVP-TE case with separate
sessions. So we are not saying that the single session is *the*
solution, it as an alternative option (maybe "valuable") to the separate
session approach.
Regards,
Attila
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of MEURIC Julien
> RD-CORE-LAN
> Sent: Monday, March 05, 2007 5:50 PM
> To: Igor Bryskin; Diego Caviglia (GA/ERI); Igor Bryskin;
> Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk
> Cc: ccamp@ops.ietf.org; Don Fedyk
> Subject: 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
>
>
>