RE: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas -- was Re: Polling for new WG I-Ds

["Trevor Wilson" <wilsont@nortel.com>]

Hi Huub,

Thanks for the clarifications, see in-line for responses.

Trevor Wilson
Nortel Networks
Belfast Lab
Tel: +44 2890 363701
       ESN 751 3701
>This is the Way. This is Nortel. 
>
Confidentiality Notice:  This message and any attachments may contain
information that is privileged and confidential. If you have reason to
believe that you are not the intended recipient or a person responsible
for delivering this message to an intended recipient, you are hereby
notified that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have reason to believe that
you are not the intended recipient or a person responsible for
delivering this message to an intended recipient, please contact the
sender immediately by reply email and destroy all copies of the original
message.



-----Original Message-----
From: Huub van Helvoort [mailto:hhelvoort@chello.nl] 
Sent: 16 August 2006 19:02
To: ccamp@ops.ietf.org
Cc: Wilson, Trevor (IRE07:Q840)
Subject: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas -- was Re:
Polling for new WG I-Ds


Hello Trevor,

You wrote:

> I have read the ID-draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt
> I have the following questions and comments:

See my comments in-line [hvh]

> Section 3.2:
> 
> Is Fixed synonymous with no-LCAS ?

[hvh] No, not necessarily, in this case the client signal will
       not change its bandwidth. LCAS can be used for resilience.
[tw]	Accepted that this is possible. However I still think the reader
could be forgiven for assuming that Fixed = non-LCAS-capable and Dynamic
= LCAS-capable; so perhaps this needs to be clarified in the text.

> If so, then in the Fixed co-routed scenario, there can be no graceful 
> degradation in the event of a failure.
[tw] I have a typo here is should say Fixed diversely-routed instead of
Fixed co-routed

[hvh] a mis-connection is also a failure
[tw]	but a mis-connection won't cause a hit, since this will occur at
set-up, but I agree that if LCAS is present then graceful degradation
can be achieved in the event of a signal degrade.

> This is more applicable to the dynamic, diversely-routed scenario (and

> in fact could apply to the dynamic co-routed scenario, although this 
> is far more unlikely).

[hvh] see my previous comment

> Regarding 'graceful degradation in the event of a failure': surely 
> this is a misnomer ? Graceful degradation can only be achieved if the 
> VCG capacity is hitlessly decreased. A full blown failure on any VCG 
> member will cause a hit to the traffic, albeit temporary.

[hvh] agree

> A hitless decrease
> can in certain circumstances, be achieved by using a signal degrade to

> trigger the LCAS remove operation.

[hvh] how do you provision/achieve a signal degrade?
[tw]	G.806 clause 10.1.1.2 shows "P-Xv_AI_TSD = P_AI[1.. XMR]_TSD"
and "P-Xv/P-X-L_A_Sk_MI_TSDEnable" as inputs to the "LCAS-capable
virtual concatenated path adaptation sink function P-Xv/P-X-L_A_Sk", and
the text says "The MI_TSDEnable input controls whether the sink function
uses AI_TSD[i] indications as contributors for signalling defective
members back to the LCAS source function (MI_TSDEnable = true) or
whether it ignores AI_TSD[i] indications altogether (MI_TSDEnable =
false)."

> Suggested text for 3.2 (partial)
> 
> Fixed, diversely routed: A fixed bandwidth VCG, transported over 
>       at least two diversely routed subsets of member signals.  In
this 
>       case, the subsets are link-disjoint over at least one link of
the 
>       route.  The intent here is more efficient use of network 
> resources
> 
>       (no unique route has the required bandwidth), (note 
>       that differential delay may be a limiting factor).

[hvh] I don't agree, LCAS can provide resilience, I agree that the
       degradation is not graceful
[tw]	We are converging here (as usual); see my previous
comment/suggestion

> Dynamic, diversely routed: A dynamic VCAT group, transported over 
>       at least two diversely routed subsets of member signals.  The 
>       intent here is dynamic resizing and resilience (but differential

>       delay may be a limiting factor). Graceful degradation is 
> possible in the event of a TSD (Trail Signal Degrade) on a VCG
member(s)

[hvh] graceful degradation is a feature of LCAS, it is not necessary
       to mention it here explicitly
[tw]	It's equally (if not more) relevant to mention it here than in
the fixed scenario.

> Section 4
> 
> Typo on second line of last paragraph: VC4-7v should be VC-4-7v.

[hvh] OK

> Section 4.1.3
> 
> G.7042 section 6.4 addresses VCG capacity decrease (temporary removal 
> due to member failure) and section 6.5 addresses VCG capacity decrease

> (permanent removal). Each of these has distinct meanings and I think 
> that this ID should make that distinction also, or at least be more 
> pedantic in the use of 'removal'.
> 
> Perhaps (as far as GMPLS is concerned) there is only the need to 
> address the VCG capacity decrease (permanent removal), since the 
> 'temporary removal' is an autonomous action performed by the LCAS 
> protocol and does not require any management intervention.

[hvh] the temporary removal description was in previous versions
       of this draft, because (as you mention) this draft concerns
       GMPLS it was removed to avoid confusion.
[tw]	I'm all for avoiding confusion -- see next comment.

> Suggested text for 4.1.3: -
> 
> 4.1.3. Decreasing VCG capacity
> 
> VCG capacity can be decreased in two ways
> o	Temporary removal of a VCG member(s) due to failure
> o	Planned permanent removal of a VCG member(s) which requires
> management intervention
> 
> 4.1.3.1	Temporary Removal of a VCG member
> 
> This is an autonomous action performed by the LCAS protocol whenever a

> failure occurs on an active VCG member(s). The relevant VCG member 
> will then be in the DNU state.
> 
> There is no management intervention required to perform this 
> operation.
> 
> This member can then be permanently removed from the VCG. (4.1.3.2)
> 
> 4.1.3.2		Planned permanent removal of a VCG member
> 
>    The procedure to remove a component signal is similar to that used 
> to
> 
>    add components as described in Section 4.1.2.  The LCAS in-band 
>    signaling step is taken first to take the component out of the 
> group as the result of a remove command from the LCAS controller; the 
> permanently removed member will then be in the IDLE state.

[hvh] mentioning only one of the LCAS states will create confusion
       and is irrelevant to GMPLS
[tw]	OK so take out the mention of the DNU state (4.1.3.1) and IDLE
(4.1.3.2). In fact perhaps 4.1.3.1 could be combined with 4.1.3.2 as
follows: -

4.1.3		Permanent removal of a VCG member

A VCG member can be permanently removed from the VCG either following a
temporary removal (due to a failure) or as the result of a management
command.
The LCAS in-band signaling step is taken first to take the component out
of the group, either the temporary removal or as the result of a
management command.

>    LCAS signaling is described in [ITU-T-G.7042]
> 
>    In this case, the NVC value is decremented by 1 and the timeslot 
>    identifier for the dropped component is removed from the ordered 
> list
> 
>    in the Generalized Label.
> 
> This permanent removal procedure is only applicable to 
> LCAS-capable-VCAT.

[hvh] the paragraph replaced by the latter sentence contains more
       relevant detail and should be kept intact.
[tw]	The introduction to section 4 states that it (section 4) is "in
support of the LCAS procedure". So I don't quite see how the sentence
that I deleted is relevant to LCAS since it deals with the "VCAT only"
interface. 	

> Best regards,
> 
> Trevor
> 
> Trevor Wilson
> Nortel Networks

Kind regards, Huub van Helvoort.

-- 
================================================================
              http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...