[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas
Huub,
Sorry for the delay in replying to your e-mail.
I think we're there. See in-line. [tw2]
Trevor
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: 18 August 2006 22:49
To: Wilson, Trevor (IRE07:Q840)
Cc: ccamp@ops.ietf.org
Subject: Re: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas
Hello Trevor,
You replied:
> Thanks for the clarifications, see in-line for responses.
OK, I have added my response [hvh2] and sipped the parts
where we agree.
>> 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.
[hvh2] OK that can be done.
[tw2] Look forward to seeing that.
>> 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.
[hvh2] I don't agree, mis-connections can also occur after set-up,
e.g. when a crossconnect is wrongly provisioned and changed
an existing connection.
[tw2] OK
>> 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)."
[hvh2] this is the enabling of the TSD to be a trigger. What I dis
mean is that it is impossible to force a signal degrade (e.g.
by introducing bit errors on purpose).
Maybe we should only mention that hitless decrease is guaranteed
when a member is removed (and LCAS is enabled).
[tw2] I'm getting a bit lost; this part of the discussion was about
graceful degradation. With that in mind are you suggesting to remove any
mention of graceful degrade. If so I agree. I look forward to seeing the
final text.
>> 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.
[hvh2] see my previous comment
>> 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.
[hvh2] good suggestion
>> 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.
[hvh2] you missed the word "and" in quoting, so section 4 describes
extentions for diversely routed paths and (extentions) in
support of LCAS". So the detail given in the paragraph is
relevant for making the distinction between VCAT with and
without LCAS.
[tw2] OK
Cheers, and have a nice weekend, Huub.
--
================================================================
http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...