[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: LCAS and GMPLS
Hi,
Clearly CCAMP is not supposed to do TU-T's job... I have a feeling we need more clarification of the actual requrirements, and then assess which functionalities are supported by SONET/SDH or GMPLS already to identify the missing bits. It may then turn out that we actually most of the mechanisms in place, but need a BCP to clarify how to use them properly. My suggestion to take this forward is that we briefly discuss the two drafts tomorrow, then refine the requirements and the solution drafts until the next IETF meeting. Again, there is definitive interest by operators to get the SDH and GMPLS interworking as clear as possible.
Regards,
Michael
-----Ursprüngliche Nachricht-----
Von: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] Im Auftrag von Adrian Farrel
Gesendet: Dienstag, 2. August 2005 11:42
An: Huub van Helvoort; ccamp
Betreff: Re: LCAS and GMPLS
Hi Huub,
> > 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
That is a shame because it is hard for CCAMP to work on this without a clear statement of the requirements and we look to the ITU-T to supply the details of LCAS.
If we can identify more precisely what it is we need to know, then we can liaise a request for information.
> > 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.
I can't speak for the authors.
Speaking for myself, I was not aware of the work at the SG15 meeting. I am certain that the majority of CCAMP was not aware.
> > 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.
Yes. it removes a requirement.
It doesn't remove any protocol elements because they already exist. It changes the solutions doc, because there is no need to describe a non-requirement.
> > - 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.
Well, if we establish that this *is* a requirement we have to solve it. That will start a discussion of how simple/practical the solution is. IM(NS)HO this is easy work using existing GMPLS tools.
> > 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.
Thanks, yes.
But in order to understand the requirements here we must understand what we are tyring to support. Do we need to support existing LCAS implementations, or can we assume that the SG15 proposals will come to agreement/standardisation and will be implemented ubiquitously?
See below...
> > 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?
I think CCAMP will understand the need for hitless add/remove. If CCAMP sees/believes that LCAS does not support this function, then CCAMP will attempt to deliver this function. If CCAMP sees/believes that LCAS already delivers the function, this will not be something that CCAMP discusses further.
However, it is not for CCAMP to comment on the function contained within LCAS. LCAS is not our protocol to comment on.
Thanks,
Adrian
>
> 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...
>
>