Subject: Re: LCAS and GMPLS

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Aug 2005 01:04:34 +0100

Hi Huub, Wataru,

I think the original proposal is that SG15 may want to send CCAMP a
liaison about this work. That would certainly be fine.

I don't think that CCAMP can send a liaison back to support the work
without having seen it first.

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.
- If the problem is to be solved within GMPLS, then we have a suitable
mechanism already.

Thus, it turns out that it is important to scope problems not just
functionally, but according to which components are intended to resolve
them.

Very obviously, the industry does not need or want two solutions to the
same problem.

Adrian
----- Original Message ----- 
From: "Huub van Helvoort" <[email-masked]>
To: "ccamp" <[email-masked]>
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...
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Aug 2005 01:04:34 +0100

Hi Huub, Wataru,

Adrian

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 02 Aug 2005 10:49:25 +0200

Hello Adrian,

Thanks for your comments.
I shall try to give some more insight.

> liaison about this work. That would certainly be fine.

[hvh] I tried but did not get enough support

> 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.

> CCAMP. The LSP will simply be torn down when the LCAS synchronization has

[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

[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.

> functionally, but according to which components are intended to resolve

[hvh] I hope I did above.

> Very obviously, the industry does not need or want two solutions to the

[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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Aug 2005 10:42:19 +0100

Hi Huub,

> [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.

>        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.

>        impact on the control plane: it removes the mandatory sequence

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.

>        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.

> [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...

>        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