Subject: Polling for new WG I-Ds

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 12 Aug 2006 15:56:02 +0100

Hi,

As discussed in Montreal, we need to poll for a couple of new WG drafts.

http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt 
has been updated by the authors to provide further details and 
clarification.

http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt 
has been updated since the version discussed in Montreal.

http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt 
has been updated as Zafar says in his previous email.

Please send yes or no for these I-Ds.

Reasons and opinions are also welcomed.

Thanks,
Adrian

---

From: Richard Rabbat <[email-masked]>
Date: Mon, 14 Aug 2006 10:02:20 -0700

yes to all
btw, draft-caviglia-ccamp-pc-and-sc-reqs-02.txt is now
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-03.txt
Richard
--

---

From: Dan Li <[email-masked]>
Date: Tue, 15 Aug 2006 09:18:59 +0800

Hi,

Yes to all.

Regards,

Dan

---

From: Wataru Imajuku <[email-masked]>
Date: Tue, 15 Aug 2006 18:17:55 +0900

Hi, All

  Yes to all.

Best Regards
Wataru

 >http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt 
has been updated by the authors to provide further details and clarification.
 >Reasons and opinions are also welcomed.

-------------------------------------
Wataru Imajuku@NTT Network Innovation Labs
TEL: +81-46-859-4315
FAX: +81-468-59-5541

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 15 Aug 2006 14:20:14 +0200

Hello Adrian,

Yes to all.

Cheers, Huub.

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

---

From: "Trevor Wilson" <[email-masked]>
Date: Wed, 16 Aug 2006 16:55:21 +0100

Hi all,

I have read the ID-draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt which I
have duplicated below in a word document and applied comments and
changes (see change bars) for your perusal. I have the following
questions and comments (also in the attached): -

Section 3.2:

Is Fixed synonymous with no-LCAS ?

If so, then in the Fixed co-routed scenario, there can be no graceful
degradation in the event of a failure.

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

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. A hitless decrease
can in certain circumstances, be achieved by using a signal degrade to
trigger the LCAS remove operation.

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

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)  

Section 4

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

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.

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

Best regards,

Trevor

Trevor Wilson
Nortel Networks
Belfast Lab
Tel: +44 2890 363701
       ESN 751 3701

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: 12 August 2006 15:56
To: [email-masked]
Subject: Polling for new WG I-Ds

Hi,

http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lca
s-04.txt 
has been updated by the authors to provide further details and 
clarification.

http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-
02.txt 
has been updated since the version discussed in Montreal.

http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdo
wn-04.txt 
has been updated as Zafar says in his previous email.

Thanks,
Adrian

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 16 Aug 2006 20:01:55 +0200

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]

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

> degradation in the event of a failure.

[hvh] a mis-connection is also a failure

> in fact could apply to the dynamic co-routed scenario, although this is

[hvh] see my previous comment

> will cause a hit to the traffic, albeit temporary. 

[hvh] agree

> A hitless decrease

[hvh] how do you provision/achieve a signal degrade?

>       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

> 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

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

[hvh] OK

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

> 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

> This permanent removal procedure is only applicable to

[hvh] the paragraph replaced by the latter sentence contains more
       relevant detail and should be kept intact.

> Nortel Networks

Kind regards, Huub van Helvoort.

---

From: [email-masked]
Date: Thu, 17 Aug 2006 00:32:35 +0200

adrian - see in-line

> has been updated by the authors to provide further details and 

- ok - 

- guess it is v03.txt ? -
 
> has been updated since the version discussed in Montreal.

i am ok in investigating the MP->CP but i have two concerns that imho 
should deserve more specific attention to maintain consistency wrt to 
CP->MP

section 2.2: if control is lost for an LSP (during CP failure) how can it 
be possible transfer that LSP from the CP -> MP ? 

section 4.4: why the document assumes that both MUST be supported ? in 
part. concerning the CP->MP if one does implement current GMPLS signaling 
restart/recovery why shall this be mandated ? in brief, the document shall 
take into account existing mechanisms and prevent overlaps (with existing 
GMPLS mechanisms)

hence, it is strongly suggested to identify conditions when such CP->MP is 
required (and not an alternative to existing CP mechanisms) b/f 
progressing that part

> has been updated as Zafar says in his previous email.

informational imho - in its current version 

- not sure to understand why the PathErr/Notify can be processed by the 
head-end only (what about segment recovery and stitching case) - why only 
MBB is possible upon reception (pls use E2E recovery/Segment recovery 
capabilities as you address GMPLS networks)

- compared to path-reopt, error description is identical for the TE link 
case which leads to the following point - if errors code/value are the 
same how to distinguish them (assuming that the query procedure described 
in path-reopt is used during the setup of that LSP) ? - comment is more 
for the path-reopt draft than yours but since there is an overlap ... it 
must be addressed in a way or another (note that when fully head-end 
driven operations look similar but there is a major difference role of 
timing and severity of the error code/value) 

- in case shutdown of a protected component link (of a bundle) is 
initiated why can't link protection be used ?

---

From: "Trevor Wilson" <[email-masked]>
Date: Thu, 17 Aug 2006 16:30:09 +0100

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

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]] 
Sent: 16 August 2006 19:02
To: [email-masked]
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,

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

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

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

> 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

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

[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

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

[hvh] OK

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

> failure occurs on an active VCG member(s). The relevant VCG member 
> will then be in the DNU state.
> 
>    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 

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

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

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 18 Aug 2006 23:49:26 +0200

Hello Trevor,

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

OK, I have added my response [hvh2] and sipped the parts
where we agree.

> = LCAS-capable; so perhaps this needs to be clarified in the text.

[hvh2] OK that can be done.

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

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

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

> [tw]	It's equally (if not more) relevant to mention it here than in

[hvh2] see my previous comment

>>   The LCAS in-band 

[hvh2] good suggestion

> that I deleted is relevant to LCAS since it deals with the "VCAT only"

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

Cheers, and have a nice weekend, Huub.

---

From: Dan Li <[email-masked]>
Date: Mon, 21 Aug 2006 10:01:00 +0800

Hi Dimitri,

Please see in line.

Regards,

Dan

----- Original Message ----- 
From: <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, August 17, 2006 6:32 AM
Subject: Re: Polling for new WG I-Ds

> be possible transfer that LSP from the CP -> MP ? 

[dan] Yes, there is a problem if we still want to use the control plane to do the 
CP->MP transfer. Unless the transfer is based on the predetermined policy, MP 
takes the control of the LSP resource directly (no signaling required), but this way
should not be discussed in CCAMP.

> take into account existing mechanisms and prevent overlaps (with existing 
[dan] I think the CP->MP should not be the mandatory requirement.

> required (and not an alternative to existing CP mechanisms) b/f 
[dan] In order to make the carriers' life easy, when we provide the MP->CP
conversion feature, the reverse procedure (CP->MP) may also is needed just
simply in case the carriers want to withdraw their previous decision, and
they also feel more comfortable with this "undo" function; In order to achieve
this, we should have the working control plane.

---

From: Kenji Kumaki <[email-masked]>
Date: Mon, 21 Aug 2006 13:40:10 +0900

Hi,

Yes to all.

Thanks,
Kenji

---

From: Tomohiro Otani <[email-masked]>
Date: Mon, 21 Aug 2006 13:44:15 +0900

Hi Adrian,

I support the third draft to be a WG.

Regards,

tomo

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 21 Aug 2006 06:38:52 -0700 (PDT)

Hi,
   
  Yes to all three.
   
  Igor

  ----- Original Message ----- 
From: 
To: "Adrian Farrel" 
Cc: ; 
Sent: Thursday, August 17, 2006 6:32 AM
Subject: Re: Polling for new WG I-Ds

> > Reasons and opinions are also welcomed.

---------------------------------
Do you Yahoo!?
 Next-gen email? Have it all with the  all-new Yahoo! Mail Beta.

---

From: Eric W Gray <[email-masked]>
Date: Mon, 21 Aug 2006 08:34:20 -0400

Yes to all three...

---

From: Tomohiro Otani <[email-masked]>
Date: Wed, 23 Aug 2006 09:28:58 +0900

Hello,

I also support the others.

Regards,

tomo

---

From: [email-masked]
Date: Wed, 23 Aug 2006 10:33:10 +0200

hi - 

see inline

Dan Li <[email-masked]>
Sent by: [email-masked]
21/08/2006 04:01
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel 
<[email-masked]>
        cc:     [email-masked], [email-masked]
        Subject:        Re: Polling for new WG I-Ds

Hi Dimitri,

Please see in line.

Regards,

Dan

----- Original Message ----- 
From: <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, August 17, 2006 6:32 AM
Subject: Re: Polling for new WG I-Ds

> be possible transfer that LSP from the CP -> MP ? 

[dan] Yes, there is a problem if we still want to use the control plane to 
do the 
CP->MP transfer. Unless the transfer is based on the predetermined policy, 
MP 
takes the control of the LSP resource directly (no signaling required), 
but this way
should not be discussed in CCAMP.

[dp] ok so what's left for this doc ? concerning the MP-driven failover - 
imho nothing

[dp] this is what i thought

they also feel more comfortable with this "undo" function; In order to 
achieve

[dp] concerning CP->MP input you provided would be helpful to have 
carrier's 
speaking for themselves - now there is indeed a side question shall CCAMP 
take
care about operators that want to step back from GMPLS or more generally 
any
control plane technology (usually concern is how to move forward not 
backward)

---

From: "Trevor Wilson" <[email-masked]>
Date: Thu, 24 Aug 2006 10:33:13 +0100

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

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]] 
Sent: 18 August 2006 22:49
To: Wilson, Trevor (IRE07:Q840)
Cc: [email-masked]
Subject: Re: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas

Hello Trevor,

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

> [tw] I have a typo here is should say Fixed diversely-routed instead
> of Fixed co-routed
> 

[tw2]	OK

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

> 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

[tw2]	OK