[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LCAS and GMPLS
Hello Adrian,
Thanks for your comments.
I shall try to give some more insight.
You wrote:
I think the original proposal is that SG15 may want to send CCAMP a
liaison about this work. That would certainly be fine.
[hvh] I tried but did not get enough support
I don't think that CCAMP can send a liaison back to support the work
without having seen it first.
[hvh] both draft-imajuku-ccamp-gmpls-vcat-lagr-req
and draft-bernstein-LCAS-GMPLS
refer to ITU-T G.7042. Corrigendum 1 (08/2004) to this
recommendation contains the following note:
"NOTE – If a permanent removal of an active member is initiated at the
Sk, this will result in a hit to the reconstructed data. The duration of
this hit will be from the time the member is removed (starts sending MST
= FAIL) until the DNU would have been received from the So."
So I supposed the authors of these drafts were aware
of this note, and consequently the mandatory sequence
for a hitless decrease of bandwidth: remove member at
source node first, wait for confirmation, remove member
at sink node (and network path).
Maybe the authors were not aware of a possible solution
presented at the recent SG 15 meeting.
With regard to the solution space for the problem:
- If the solution lies entirely within LCAS then it is out of scope for
CCAMP. The LSP will simply be torn down when the LCAS synchronization has
been done.
[hvh] indeed the solution is within the LCAS protocol, but has an
impact on the control plane: it removes the mandatory sequence
for hitless decrease.
- If the problem is to be solved within GMPLS, then we have a suitable
mechanism already.
[hvh] if you mean that GMPLS can take care of or guarantee the
above mentioned mandatory sequence, then indeed there is
no problem.
However IMHO it may be a complex solution.
Thus, it turns out that it is important to scope problems not just
functionally, but according to which components are intended to resolve
them.
[hvh] I hope I did above.
Very obviously, the industry does not need or want two solutions to the
same problem.
[hvh] the solution proposed in the last plenary meeting of ITU-T
SG15 delayed document D.286 did not get concensus in the Q11
meeting. When presented in the Q14 meeting it was agreed that
this proposal would simplify the control of LCAS LSPs.
If this solution is not accepted soon, more LCAS implementations
will be cast in silicon (currently the majority is in SW) and
t will be very hard to get it accepted at a later date.
When CCAMP sees the need for adding this enhancement that
removes the mandatory remove sequence, shouldn't a liaison
be sent to SG15/Q11 to express their concern?
Cheers, Huub.
Adrian
----- Original Message -----
From: "Huub van Helvoort" <hhelvoort@chello.nl>
To: "ccamp" <ccamp@ops.ietf.org>
Sent: Sunday, July 31, 2005 3:21 PM
Subject: Re: LCAS and GMPLS
Hello Wataru,
You wrote:
I forward a nice comment from Mr. Huub van Helvoort.
Thank you for forwarding.
(I hope I can send this message the list myself).
His comments indicates we need liason from ITU-T SG-15 regarding to
this issue.
This is a good proposal, it will indicate to ITU-T SG15/Q11
that IETF/CCAMP supports this enhancement.
Kind regards, Huub.
--- from message 27-7-2005 ---
One point for the problem statement could be that in order to
guarantee a hitless removal of one of the members in a VCG
(decrease of bandwidth) there is a mandatory sequence:
First remove member at ingress node, wait for confirm and
only then remove path and member at egress node.
However, a solution was presented at the last ITU-T SG15/q11
meeting that removes this requirement.
Cheers, Huub.
--
================================================================
http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...