Subject: ☆今日から９月☆秋目前☆

From: [email-masked]
Date: Thu, 31 Aug 2006 21:16:49 -0400 (EDT)

$BJQ$o$j$P$($N$J$$F|>o$K$&$s$6$j$7$F$^$;$s$+!)(B

$B$H$-$K$O<+M3$K0&$r5a$a$F$b$$$$$s$8$c$J$$$+$J!)(B

$B$J$+$K$O%d%j$?$/$F$?$^$i$J$$%(%m%(%m$J=w@-$b$$$k$+$i$M!#(B

$B$=$s$J?M$?$A$,$I$s$I$s=8$^$C$F$/$k$N$,$3$N%5%$%H(B

$B$4MxMQ$,40A4L5NA$J$N$G$9$4$/;H$$$d$9$/$FBg?M5$!#(B

$B%W%m%U$J$s$+$K$b$H$F$b8@$($J$$$h$&$JFbMF$,!D(B

$B<+M3$K0&$r5a$a$k?M$?$A$N%5%$%H$G$9!#(B

$B;H$$J}<!Bh$GD6%b%F%b%F!*!)0&$K52$($?=w@-$r5_$C$F$/$@$5$$!#(B

$B$7$+$b40A4L5NA$N#01_%3%s%F%s%D!*!*(B

$B!!!!!!$9$0$KEPO?(B

$B!!!!!!!!"-"-"-"-(B

$B"!!!(Bhttp://19redgirl.info/lc-t/

$BG[?.ITMW$O$3$A$iKx(B

[email-masked]

[0901][m12]

Delivery-date: Thu, 31 Aug 2006 19:51:09 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-06.txt 
Date: Thu, 31 Aug 2006 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-ccamp-inter-domain-framework-06.txt
	Pages		: 21
	Date		: 2006-8-31
	
This document provides a framework for establishing and controlling
   Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain
   networks.

   For the purposes of this document, a domain is considered to be any
   collection of network elements within a common sphere of address
   management or path computational responsibility. Examples of such
   domains include Interior Gateway Protocol (IGP) areas and Autonomous
   Systems (ASs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-inter-domain-framework-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-framework-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 31 Aug 2006 11:32:49 +0000
To: [email-masked]
From: JP Vasseur <[email-masked]>
Subject: Fwd: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt 
Date: Thu, 31 Aug 2006 07:30:31 -0400

--Apple-Mail-43-475489015
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

simple refresh. No change.

JP.

Begin forwarded message:

> From: [email-masked]
> Date: August 30, 2006 3:50:02 PM EDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Common Control and Measurement  
> Plane Working Group of the IETF.
>
> 	Title		: A Per-domain path computation method for establishing  
> Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)
> 	Author(s)	: J. Vasseur
> 	Filename	: draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
> 	Pages		: 21
> 	Date		: 2006-8-30
> 	
> This document specifies a per-domain path computation technique for
> establishing inter-domain Traffic Engineering (TE) Multiprotocol
> Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched
> Paths (LSPs).  In this document a domain refers to a collection of
> network elements within a common sphere of address management or path
> computational responsibility such as IGP areas and Autonomous
> Systems.  Per-domain computation applies where the full path of an
> inter-domain TE LSP cannot be or is not determined at the ingress
> node of the TE LSP, and is not signaled across domain boundaries.
> This is most likely to arise owing to TE visibility limitations.  The
> signaling message indicates the destination and nodes up to the next
> domain boundary.  It may also indicate further domain boundaries or
> domain identifiers.  The path through each domain, possibly including
> the choice of exit point from the domain, must be determined within
> the domain.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain- 
> pd-path-comp-03.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path- 
> comp-03.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID:	<[email-masked]>

--Apple-Mail-43-475489015
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">simple refresh. No =
change.<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>JP.<BR><DIV><BR><DIV>Begin =
forwarded message:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 16.0px Helvetica; color: #000000"><B>From: =
</B></FONT><FONT face=3D"Helvetica" size=3D"5" style=3D"font: 16.0px =
Helvetica"><A =
href=3D"mailto:[email-masked]">[email-masked]</A></FON=
T></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"5" =
color=3D"#000000" style=3D"font: 16.0px Helvetica; color: =
#000000"><B>Date: </B></FONT><FONT face=3D"Helvetica" size=3D"5" =
style=3D"font: 16.0px Helvetica">August 30, 2006 3:50:02 PM =
EDT</FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 16.0px Helvetica; color: =
#000000"><B>To: </B></FONT><FONT face=3D"Helvetica" size=3D"5" =
style=3D"font: 16.0px Helvetica"><A =
href=3D"mailto:[email-masked]">[email-masked]</A></FONT></DI=
V><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 16.0px Helvetica; color: #000000"><B>Cc: </B></FONT><FONT =
face=3D"Helvetica" size=3D"5" style=3D"font: 16.0px Helvetica"><A =
href=3D"mailto:[email-masked]">[email-masked]</A></FONT></DIV><DIV=
 style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 16.0px Helvetica; color: #000000"><B>Subject: =
</B></FONT><FONT face=3D"Helvetica" size=3D"5" style=3D"font: 16.0px =
Helvetica"><B>I-D =
ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></B></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> <DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">A New =
Internet-Draft is available from the on-line Internet-Drafts<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">directories.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">This draft is a work item of the =
Common Control and Measurement Plane Working Group of the =
IETF.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>Title<SPAN class=3D"Apple-tab-span"=
 style=3D"white-space:pre">	</SPAN><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>: A Per-domain path computation =
method for establishing Inter-domain Traffic Engineering (TE) Label =
Switched Paths (LSPs)</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</SPAN>Author(s)<SPAN class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</SPAN>: J. Vasseur</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</SPAN>Filename<SPAN class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</SPAN>: draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>Pages<SPAN class=3D"Apple-tab-span"=
 style=3D"white-space:pre">	</SPAN><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>: 21</DIV><DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</SPAN>Date<SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</SPAN><SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</SPAN>: =
2006-8-30</DIV><P style=3D"margin: 0.0px 0.0px 0.0px 0.0px; min-height: =
14.0px"><SPAN class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</SPAN><BR class=3D"khtml-block-placeholder"></P><DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">This =
document specifies a per-domain path computation technique for</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">establishing inter-domain Traffic Engineering (TE) =
Multiprotocol</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Label Switching (MPLS) and =
Generalized MPLS (GMPLS) Label Switched</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Paths =
(LSPs).<SPAN class=3D"Apple-converted-space">=A0 </SPAN>In this document =
a domain refers to a collection of</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">network =
elements within a common sphere of address management or path</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">computational responsibility such as IGP areas and =
Autonomous</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Systems.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>Per-domain computation =
applies where the full path of an</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">inter-domain =
TE LSP cannot be or is not determined at the ingress</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">node of the TE LSP, and is not signaled across =
domain boundaries.</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">This is most likely to =
arise owing to TE visibility limitations.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>The</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">signaling message indicates the destination and =
nodes up to the next</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">domain boundary.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>It may also indicate further =
domain boundaries or</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">domain identifiers.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>The path through each domain, =
possibly including</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">the choice of exit point =
from the domain, must be determined within</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">the =
domain.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">A URL for this Internet-Draft is:</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-=
pd-path-comp-03.txt">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-=
inter-domain-pd-path-comp-03.txt</A></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">To remove yourself from the I-D =
Announcement list, send a message to<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked]=
g</A> with the word unsubscribe in the body of<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">the =
message.<SPAN class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">You can also visit <A =
href=3D"https://www1.ietf.org/mailman/listinfo/I-D-announce">https://www1.=
ietf.org/mailman/listinfo/I-D-announce</A><SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">to =
change your subscription settings.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Internet-Drafts are also =
available by anonymous FTP. Login with the<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">username =
"anonymous" and a password of your e-mail address. After<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">logging =
in, type "cd internet-drafts" and then<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">"get =
draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt".</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">A list =
of Internet-Drafts directories can be found in</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</=
A><SPAN class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">or <A =
href=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf=
/1shadow-sites.txt</A></DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Internet-Drafts can also be =
obtained by e-mail.</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Send a message to:</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN><A =
href=3D"mailto:[email-masked]">[email-masked]</A>.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">In the body type:</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</SPAN>"FILE =
/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt".</DIV>=
<P style=3D"margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px"><SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</SPAN><BR =
class=3D"khtml-block-placeholder"></P><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">NOTE:<SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</SPAN>The mail =
server at ietf.org can return the document in</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>MIME-encoded form by using the =
"mpack" utility.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>To use =
this</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>feature, insert the command =
"ENCODING mime" before the "FILE"</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</SPAN>command.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>To =
decode the response(s), you will need "munpack" or</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>a MIME-compliant mail =
reader.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>Different =
MIME-compliant mail readers</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</SPAN>exhibit =
different behavior, especially when dealing with</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>"multipart" MIME messages (i.e. =
documents which have been split</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</SPAN>up into =
multiple messages), so check your local documentation on</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>how to manipulate these =
messages.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Below is the data which will enable a MIME compliant =
mail reader</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">implementation to automatically =
retrieve the ASCII version of the</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Internet-Draft.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Content-Type: =
text/plain</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Content-ID:<SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</SPAN>&lt;<A =
href=3D"mailto:[email-masked]">[email-masked]<=
/A>&gt;</DIV> </BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-43-475489015--

Delivery-date: Wed, 30 Aug 2006 19:52:33 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt 
Date: Wed, 30 Aug 2006 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: A Per-domain path computation method for 
                          establishing Inter-domain Traffic 
                          Engineering (TE) Label Switched Paths (LSPs)
	Author(s)	: J. Vasseur, et al.
	Filename	: draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
	Pages		: 21
	Date		: 2006-8-30
	
This document specifies a per-domain path computation technique for
establishing inter-domain Traffic Engineering (TE) Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched
Paths (LSPs).  In this document a domain refers to a collection of
network elements within a common sphere of address management or path
computational responsibility such as IGP areas and Autonomous
Systems.  Per-domain computation applies where the full path of an
inter-domain TE LSP cannot be or is not determined at the ingress
node of the TE LSP, and is not signaled across domain boundaries.
This is most likely to arise owing to TE visibility limitations.  The
signaling message indicates the destination and nodes up to the next
domain boundary.  It may also indicate further domain boundaries or
domain identifiers.  The path through each domain, possibly including
the choice of exit point from the domain, must be determined within
the domain.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 30 Aug 2006 19:52:25 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt 
Date: Wed, 30 Aug 2006 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)
	Author(s)	: J. Vasseur
	Filename	: draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
	Pages		: 21
	Date		: 2006-8-30
	
This document specifies a per-domain path computation technique for
establishing inter-domain Traffic Engineering (TE) Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched
Paths (LSPs).  In this document a domain refers to a collection of
network elements within a common sphere of address management or path
computational responsibility such as IGP areas and Autonomous
Systems.  Per-domain computation applies where the full path of an
inter-domain TE LSP cannot be or is not determined at the ingress
node of the TE LSP, and is not signaled across domain boundaries.
This is most likely to arise owing to TE visibility limitations.  The
signaling message indicates the destination and nodes up to the next
domain boundary.  It may also indicate further domain boundaries or
domain identifiers.  The path through each domain, possibly including
the choice of exit point from the domain, must be determined within
the domain.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 29 Aug 2006 22:23:20 +0000
Date: Tue, 29 Aug 2006 15:21:20 -0700
From: Richard Rabbat <[email-masked]>
To: ccamp <[email-masked]>, [email-masked]
Subject: call for papers: 1st IEEE International Workshop on Bandwidth on Demand (BoD 2006)

Apologies for possibly receiving multiple copies of this CFP.

Call for Papers

1st IEEE International Workshop on Bandwidth on Demand (BoD 2006)
http://www.csg.unizh.ch/events/bod06/

In conjunction with IEEE GLOBECOM 2006
http://www.ieee-globecom.org/2006/

November 27, 2006
San Francisco, California, USA

Scope

Electronic marketplaces for trading bandwidth have emerged since the
late 1990’s, but were seriously hit by the economic downturn in 2001.
The promise of instant bandwidth availability had led to the development
of market mechanisms that companies used to trade bandwidth just as
other commodities. However, those trading markets all but disappeared
with the bursting of the telecom bubble. Driven by the recent technical
advances in telecommunications and the new potentials of emerging
peer-to-peer (P2P) and next generation networks (NGN), the goal of this
workshop is to take a fresh and innovative look at the concept of
bandwidth on demand (BOD).

Recent advances in the Internet-based communications domain, in which
the support of Quality-of-Service and diverse application services
become possible, require in many cases short-termed bandwidth
assignments for, e.g., large sporting events or cultural open air
activities. In addition, the support of bandwidth trading in a fully
decentralized and secured manner, e.g., based on P2P schemes, shows
further advantages in terms of reliability and scalability for
large-scale systems.

Topics of Interest

The workshop seeks original papers in the following four areas that
serve as basis for bandwidth on demand:

* Economic studies and modeling of market and business models in carrier
and service provider networks
o Game theoretical bandwidth-on-demand models
o Cost and revenue models
o Bandwidth-on-demand business models
o Market liquidity aspects

* Technical design of scalable, reliable, and cost-effective bandwidth
trading infrastructures, including market mechanisms as a way to
increase efficiencies
o Scalable market mechanisms
o Secure and reliable market infrastructures
o Bandwidth trading mechanisms
o IP-based and decentralized trading mechanisms
o P2P trading infrastructures, distributed markets
o P2P auctions

* Legislative and regulatory issues related to the Telecom Act and in
comparison to other commodities markets such as the electric grid
o Telecom legislation
o Telecom regulation
o Commodities markets

* Industrial developments of new technologies that facilitate or create
impediments to bandwidth on demand
o Network management aspects
o Technical improvements in transport and data networks

Paper Submissions

Papers are solicited as full papers (in English), of no more than 8
single-spaced pages, each of which will be subject to a full review 
process.

Submissions must be in PDF and will be handled using the JEMS system.
Please refer to http://www.csg.unizh.ch/events/bod06/ for further
submission instructions or contact [email-masked] for additional
information. Those papers accepted will be published in proceedings with
an ISBN number.

Important Dates

* Paper registration deadline: September 14, 2006
* Extended submission deadline: September 21, 2006
* Notification of acceptance: October 15, 2006
* Final versions of papers due: October 31, 2006
* Workshop date: November 27, 2006

Committees

General Co-chairs
* Takeo Hamada, Fujitsu Laboratories of America, USA
* Burkhard Stiller, University of Zurich and ETH Zurich, Switzerland
* Jean Walrand, UC Berkeley, USA

PC Co-chairs
* Richard Rabbat, Fujitsu Laboratories of America, USA
* David Hausheer, University of Zurich, Switzerland

Technical Program Committee
* Panayotis Antoniadis, LIP6, France
* Greg Bernstein, Grotto Networking, USA
* Georg Carle, University of Tuebingen, Germany
* Costas Courcoubetis, AUEB, Greece
* György Dán, KTH, Sweden
* Vasilios Darlagiannis, EPFL, Switzerland
* Zoran Despotovic, DoCoMo Euro-Labs Muenchen, Germany
* Chris Edwards, Lancaster University, UK
* Adrian Farrel: Old Dog Consulting / IETF CCAMP Working Group Chair
* Oliver Heckmann, TU Darmstadt, Germany
* Rahul Jain, UC Berkeley, USA
* Charis Kaskiris, UC Berkeley, USA
* Dave Marples, Telcordia, USA
* Michael Menth, University of Wuerzburg, Germany
* Huw Oliver, Bristol, Research Consultant, UK
* Lyndon Ong, Ciena, USA
* Aiko Pras, University of Twente, The Netherlands
* Giancarlo Ruffo, University of Torino, Italy
* Vik Saxena, Comcast, USA
* Vishal Sharma, Metanoia, Inc, USA
* Kohei Shiomoto, NTT Labs, Japan

Delivery-date: Tue, 29 Aug 2006 12:25:48 +0000
Date: Mon, 28 Aug 2006 22:48:33 -0400
From: Acee Lindem <[email-masked]>
To: OSPF List <[email-masked]>
CC: [email-masked], David Ward <[email-masked]>
Subject: Re: [OSPF] draft-ietf-ccamp-automesh-01.txt

The OSPF WG last call has ended.
Thanks,
Acee

Acee Lindem wrote:
> The above draft makes use of the OSPF capabilities LSA. It is my
> understanding that it has been last called in the ccamp WG. We are
> now last calling it in the OSPF and ISIS WGs.
>
> The last call will start today (August 11, 2006) and end at 12:00 AM
> on August 26th, 2006. Please copy this list and the document editors
> (JP Vasseur and JL Leroux) with your comments. You can also copy the 
> ccamp list if you are subscribed (I believe the list is closed though
> I'm not sure since I am subscribed).
>
> Here is a link for you convenience:
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-01.txt
>
> Thanks,
> Acee
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ospf
>

Delivery-date: Mon, 28 Aug 2006 07:32:47 +0000
Sensitivity: 
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
To: "Dimitri.Papadimitriou" <[email-masked]>
Cc: [email-masked]
From: "Diego Caviglia" <[email-masked]>
Date: Mon, 28 Aug 2006 09:30:54 +0200

Dimitri,
         from my point of view the possibility to specify link components
and labels in ERO foreseen the existence of a MP that knows that
information so I can say that there are CP opertarion linked to MP.

Regards

Diego

[email-masked] on 25/08/2006 19.01.14

To:    "Bryskin, Igor" <[email-masked]>
cc:    "Farrel, Adrian" <[email-masked]>, "ccamp"
       <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard,
       Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
       <[email-masked]>, "Don Fedyk" <[email-masked]>,
       "Drake, John E" <[email-masked]>, "Lou Berger"
       <[email-masked]>, "Li, Han" <[email-masked]>,
       [email-masked]

Subject:    RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

i totally disagree you constantly referring to the MP while CCAMP has
NEVER linked control operations to MP operations - these MP operations
assumptions are outside scope of CCAMP

in part. we are going to enter into a discussion for which we won't get
the bird out of the bush: addressing space between CP and MP
it took us more or less 4 years to disambiguate the DP address space
relationship with the CP and there is no reason to start an endless debate
now with the MP

-d.

"Bryskin, Igor" <[email-masked]>
Sent by: [email-masked]
25/08/2006 18:39

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp"
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A,
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>,
"Don Fedyk" <[email-masked]>, "Drake, John E"
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han"
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
I-Ds)

Approximate scenarios:

a) MP->CP scenario:

MP provides CP with complete ERO (including labels)
CP signals SETUP with an IN-PLACE attribute, this causes provisioning
operations on each node without re-programming cross-connects
MP releases resource ownership after the operation by some means

b) CP->MP scenario:

MP receives from CP complete RRO (including labels)
MP assumes resource ownership operation by some means
CP signals TEARDOWN with an IN-PLACE attribute, this causes release by CP
resources on each node without re-programming cross-connects

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 12:18 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

you are asking for something outside the scope of ccamp

entity X wants to recuperate a CP state - just let it do - if so allowed

then send a PathTear since there is no resource anymore associate to that
state (but this does not require any specific documentation)

-d.

"Bryskin, Igor" <[email-masked]>
Sent by: [email-masked]
25/08/2006 18:06

        To:     "Lou Berger" <[email-masked]>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp"
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A,
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>,

"Don Fedyk" <[email-masked]>, "Drake, John E"
<[email-masked]>, "Li, Han" <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
I-Ds)

Agree with Lou.

Can I also quote my own email? :=)

"We are
talking here about a capability of CP to acquire network resources and
build CP state for an LSP without actually re-programming crossconnects
(case MP->CP). Likewise, we are talking about capability of CP to release
resources and destroy CP state for an LSP without re-programming
crossconnects (case CP->MP). It is out of scope of those mechanisms how MP
(or any other plane) assumes or yields the ownership of resources of the
LSP whose ownership is transferred from/to CP."

So I think we are talking about two relatively simple and very symmetrical

CP functions.

Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Friday, August 25, 2006 11:57 AM
To: [email-masked]
Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A,
ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

Who said anything about exporting state?

At 11:51 AM 8/25/2006, [email-masked] wrote:

>lou - and why shall CCAMP provide a function to export states outside of
>its domain of competence
>
>thanks,
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 17:49
>
>         To:     "Don Fedyk" <[email-masked]>
>         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel,
>Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard,
>Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
><[email-masked]>, "Drake, John E" <[email-masked]>,
>"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>
>Don,
>
>At 10:40 AM 8/25/2006, Don Fedyk wrote:
> >I think there may be something here but I think even the requirements
as
> >stated assume too much of the solution. What is the real issue?
>
>Per my previous e-mail:
>At 01:01 PM 8/24/2006, Lou Berger wrote:
>
> >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> >>[...]
> >>If we were to ask could you live without the CP->MP feature what
> >>response would we get versus asking if CP->MP is a soft requirement.
> >
> > From the discussions I've had on this with carriers, for some it's
> > a don't care, for others they won't deploy control plane without
> > this capability.
> >
> >Lou
>
>AND
>At 08:15 AM 8/24/2006, Lou Berger wrote:
> >[...]I therefore think the definition of CP->MP *is*
> >required.  There are multiple options for meeting this requirement,
> >but the solution must provide the "fallback" capability for services
> >existing at the time of the initial MP->CP transition and those
> >created after the transition.
>[...]
>
>I think a capability to remove LSP state while leaving forward state
>untouched will meet the requirements of those I've talked with.
>
>Lou
>
> >Regards,
> >Don

Delivery-date: Mon, 28 Aug 2006 06:50:59 +0000
Sensitivity: 
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
To: "Lou Berger <lberger" <[email-masked]>
Cc: [email-masked]
From: "Diego Caviglia" <[email-masked]>
Date: Mon, 28 Aug 2006 08:48:43 +0200

Lou,
     you are right the first version of the ID (that was about the protocol
solution) used a bit in the Administrative Obj in order to inform the TNE
to not remove the data plane state but just the control plane.

As you said is a very little and very simple modification.

Regards

Diego

Lou Berger <[email-masked]> on 25/08/2006 18.32.06

To:    [email-masked]
cc:    Lou Berger <[email-masked]>, "Farrel, Adrian"
       <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
       <[email-masked]>, "Brungard, Deborah A, ALABS"
       <[email-masked]>, "Diego Caviglia" <[email-masked]>,
       "Don Fedyk" <[email-masked]>, "Bryskin, Igor"
       <[email-masked]>, "Drake, John E" <[email-masked]>,
       "Li, Han" <[email-masked]>, [email-masked]

Subject:    RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

Dimitri,
         Removing state should be a simple process of deleting local
control plane state while not impacting the data plane
state.  Exporting, at least to me, implies a more complicated API or
other information transaction processing, which is certainly not needed
here.

I think we're talking about a mechanism that should require a single
"preserve data plane" bit in a PathTear message.  Nothing more.

Lou

At 12:14 PM 8/25/2006, [email-masked] wrote:

>lou - isn't "remove" or "export" having the same meaning in the present
>context ?
>
>
>
>
>Lou Berger <[email-masked]>
>Sent by: [email-masked]
>25/08/2006 17:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Li, Han" <[email-masked]>
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Who said anything about exporting state?
>
>At 11:51 AM 8/25/2006, [email-masked] wrote:
>
> >lou - and why shall CCAMP provide a function to export states outside of
> >its domain of competence
> >
> >thanks,
> >- d.
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >25/08/2006 17:49
> >
> >         To:     "Don Fedyk" <[email-masked]>
> >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel,
> >Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard,
> >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> ><[email-masked]>, "Drake, John E"
<[email-masked]>,
> >"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> >I-Ds)
> >
> >
> >
> >Don,
> >
> >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > >I think there may be something here but I think even the requirements
>as
> > >stated assume too much of the solution. What is the real issue?
> >
> >Per my previous e-mail:
> >At 01:01 PM 8/24/2006, Lou Berger wrote:
> >
> > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > >>[...]
> > >>If we were to ask could you live without the CP->MP feature what
> > >>response would we get versus asking if CP->MP is a soft requirement.
> > >
> > > From the discussions I've had on this with carriers, for some it's
> > > a don't care, for others they won't deploy control plane without
> > > this capability.
> > >
> > >Lou
> >
> >AND
> >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > >[...]I therefore think the definition of CP->MP *is*
> > >required.  There are multiple options for meeting this requirement,
> > >but the solution must provide the "fallback" capability for services
> > >existing at the time of the initial MP->CP transition and those
> > >created after the transition.
> >[...]
> >
> >I think a capability to remove LSP state while leaving forward state
> >untouched will meet the requirements of those I've talked with.
> >
> >Lou
> >
> > >Regards,
> > >Don

Delivery-date: Mon, 28 Aug 2006 06:46:51 +0000
Sensitivity: 
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
To: "Dimitri.Papadimitriou" <[email-masked]>
Cc: [email-masked]
From: "Diego Caviglia" <[email-masked]>
Date: Mon, 28 Aug 2006 08:45:16 +0200

Dimitri,
         removing the control plane state of a crossconnection without
touching the data plane imho is in the scope of CCAMP.

Also because, but this is in the scope of a solution document, can be done
via Control Plane.

Regards

Diego

[email-masked] on 25/08/2006 17.51.38

To:    Lou Berger <[email-masked]>
cc:    "Farrel, Adrian" <[email-masked]>, "ccamp"
       <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard,
       Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
       <[email-masked]>, "Don Fedyk" <[email-masked]>,
       "Bryskin, Igor" <[email-masked]>, "Drake, John E"
       <[email-masked]>, "Lou Berger" <[email-masked]>, "Li,
       Han" <[email-masked]>

Subject:    RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

lou - and why shall CCAMP provide a function to export states outside of
its domain of competence

thanks,
- d.

Lou Berger <[email-masked]>
25/08/2006 17:49

        To:     "Don Fedyk" <[email-masked]>
        cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel,
Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard,
Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
<[email-masked]>, "Drake, John E" <[email-masked]>,
"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
I-Ds)

Don,

At 10:40 AM 8/25/2006, Don Fedyk wrote:
>I think there may be something here but I think even the requirements as
>stated assume too much of the solution. What is the real issue?

Per my previous e-mail:
At 01:01 PM 8/24/2006, Lou Berger wrote:

>At 10:48 AM 8/24/2006, Don Fedyk wrote:
>>[...]
>>If we were to ask could you live without the CP->MP feature what
>>response would we get versus asking if CP->MP is a soft requirement.
>
> From the discussions I've had on this with carriers, for some it's
> a don't care, for others they won't deploy control plane without
> this capability.
>
>Lou

AND
At 08:15 AM 8/24/2006, Lou Berger wrote:
>[...]I therefore think the definition of CP->MP *is*
>required.  There are multiple options for meeting this requirement,
>but the solution must provide the "fallback" capability for services
>existing at the time of the initial MP->CP transition and those
>created after the transition.
[...]

I think a capability to remove LSP state while leaving forward state
untouched will meet the requirements of those I've talked with.

Lou

>Regards,
>Don

Delivery-date: Mon, 28 Aug 2006 06:46:43 +0000
Sensitivity: 
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
To: "Lou Berger <lberger" <[email-masked]>
Cc: [email-masked]
From: "Diego Caviglia" <[email-masked]>
Date: Mon, 28 Aug 2006 08:42:13 +0200

Lou,

Lou Berger <[email-masked]> on 25/08/2006 17.49.26

To:    "Don Fedyk" <[email-masked]>
cc:    "Bryskin, Igor" <[email-masked]>,
       <[email-masked]>, "Dan Li" <[email-masked]>,
       "Farrel, Adrian" <[email-masked]>, "ccamp"
       <[email-masked]>, "Brungard, Deborah A, ALABS"
       <[email-masked]>, "Diego Caviglia" <[email-masked]>,
       "Drake, John E" <[email-masked]>, "Lou Berger"
       <[email-masked]>, "Li, Han" <[email-masked]>

Subject:    RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

Don,

At 10:40 AM 8/25/2006, Don Fedyk wrote:
>I think there may be something here but I think even the requirements as
>stated assume too much of the solution. What is the real issue?

Per my previous e-mail:
At 01:01 PM 8/24/2006, Lou Berger wrote:

>At 10:48 AM 8/24/2006, Don Fedyk wrote:
>>[...]
>>If we were to ask could you live without the CP->MP feature what
>>response would we get versus asking if CP->MP is a soft requirement.
>
> From the discussions I've had on this with carriers, for some it's
> a don't care, for others they won't deploy control plane without
> this capability.
>
>Lou

AND
At 08:15 AM 8/24/2006, Lou Berger wrote:
>[...]I therefore think the definition of CP->MP *is*
>required.  There are multiple options for meeting this requirement,
>but the solution must provide the "fallback" capability for services
>existing at the time of the initial MP->CP transition and those
>created after the transition.
[...]

I think a capability to remove LSP state while leaving forward state
untouched will meet the requirements of those I've talked with.
[dc] This is exactly what we have in mind.
Lou

>Regards,
>Don

Delivery-date: Fri, 25 Aug 2006 20:07:52 +0000
To: "Bryskin, Igor" <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, [email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 22:03:07 +0200

igor - but these bits don't change semantic - you remove the state (you 
send the action anyway) the fact the data plane actually commits this 
action or not does not prevent forwarding passing through PathTear anyway

thanks,
- d.

"Bryskin, Igor" <[email-masked]>
25/08/2006 21:16
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, 
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, 
"Don Fedyk" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" 
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,

We do need an action from CP: we need a way to signal differently normal 
graceful shutdown and "removal CP state only" shutdown,
We cannot overload or change semantics of the "D" bit at this point.

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 3:04 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

igor

you are hanging on "breaking cross-connection" ... what i am telling to 
you is that there is no action required from the CP viewpoint beside 
preventing any error/alarm and removing the control plane state (for a 
data plane state that doesn't exist anymore from the CP perspective) there 

is no difference from the presence or absence of cross-connection ... 
otherwise we would have already a PathTear error of some kind.

you have in mind to involve the CP signaling in this move - which is 
totally beyond scope - 

-d. 

"Bryskin, Igor" <[email-masked]>
25/08/2006 20:52
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, 
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, 

"Don Fedyk" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" 
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,

No, it is not. D-bit was designed for a normal release. In normal release 
CP is responsible for breaking cross-connects (for example to avoid 
mis-connections during subsequent setups).

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:46 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

igor - but it is exactly what happens the resource reservation disappears 
from the control plane viewpoint (after which a pathtear is sent to remove 

the control plane state)

-d.

"Bryskin, Igor" <[email-masked]>
Sent by: [email-masked]
25/08/2006 20:37
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, 
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, 

"Don Fedyk" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" 
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,

We use D-bit for graceful shutdown. D-bit means prepare for delete. We do 
graceful shutdown normally. We need another bit for this exceptional 
release (without breaking cross-connects).

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:29 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

igor 

but you don't need more than what's in RFC 3473 than disabling alarms 
during the move of the resource associated to the CP to another enitity 
and the send a pathtear to remove the control plane state (you don't need 
to involve the CP in moving the data plane resource on each node)

-d.

"Bryskin, Igor" <[email-masked]>
25/08/2006 20:02
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger" 
<[email-masked]>
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, 
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, 

"Don Fedyk" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" 
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,

graceful deletion bit set in admin_status you mentioned about is sent in 
Path and Modify messages and is meant for disabling alarms before you 
starting LSP teardown.

What we are talking about is nothing but a bit in PathTear message 
instructing resource manager on each node not to break cross-connects 
while LSP resources are removed.

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 1:35 PM
To: Lou Berger
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

lou - i mean that in case an LSP for whatever reason needs to be moved 
from the control plane to another place

this is already covered in RFC 3473 - the LSP is signaled with graceful 
deletion bit set in admin_status, then on each node the resource is 
associated to that entity (which is not a CP business) and then the 
control plane state is removed

hope this clarifies,
-d.

Lou Berger <[email-masked]>
25/08/2006 19:25
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <[email-masked]>, "Farrel, Adrian" 
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Diego Caviglia" <[email-masked]>, "Don Fedyk" 
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John 
E" <[email-masked]>, "Li, Han" <[email-masked]>, 
[email-masked]
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,
         I really don't understand your point.  Can you restate/rephrase?

Lou

At 01:03 PM 8/25/2006, [email-masked] wrote:

>lou
>
>resource are present (data plane state remains) the operation we're
>discussing about is local and consist in associating that resource to
>another entity - you GR the path because you don't want to generate 
errors
>- but then that's it you just have to retrieve the CP state
>
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 18:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Li, Han" <[email-masked]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Dimitri,
>
>huh, why would there be no resources, i.e., data plane state,
>associated with the LSP?  If this were the case, I agree the whole
>discussion would be moot.
>
>Lou
>
>At 12:48 PM 8/25/2006, [email-masked] wrote:
>
> >lou,
> >
> >like i replied to igor
> >
> >"entity X wants to recuperate a CP state - just let it do - if so 
allowed
> >
> >then send a PathTear since there is no resource anymore associate to 
that
> >state (but this does not require any specific documentation)"
> >
> >we would deleting a path/resv state for which no resource are allocated 

-
> >we did already that exercise - GR deletion.
> >
> >much thanks,
> >-d.
> >
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >Sent by: [email-masked]
> >25/08/2006 18:32
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, 
John
> >E" <[email-masked]>, "Li, Han" <[email-masked]>,
> >[email-masked]
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> >I-Ds)
> >
> >
> >Dimitri,
> >          Removing state should be a simple process of deleting local
> >control plane state while not impacting the data plane
> >state.  Exporting, at least to me, implies a more complicated API or
> >other information transaction processing, which is certainly not needed
> >here.
> >
> >I think we're talking about a mechanism that should require a single
> >"preserve data plane" bit in a PathTear message.  Nothing more.
> >
> >Lou
> >
> >At 12:14 PM 8/25/2006, [email-masked] wrote:
> >
> > >lou - isn't "remove" or "export" having the same meaning in the 
present
> > >context ?
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >Sent by: [email-masked]
> > >25/08/2006 17:57
> > >
> > >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> > ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> > ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> > >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> > ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,
>John
> > >E" <[email-masked]>, "Li, Han" <[email-masked]>
> > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new 
WG
> > >I-Ds)
> > >
> > >
> > >Who said anything about exporting state?
> > >
> > >At 11:51 AM 8/25/2006, [email-masked] wrote:
> > >
> > > >lou - and why shall CCAMP provide a function to export states 
outside
> >of
> > > >its domain of competence
> > > >
> > > >thanks,
> > > >- d.
> > > >
> > > >
> > > >
> > > >
> > > >Lou Berger <[email-masked]>
> > > >25/08/2006 17:49
> > > >
> > > >         To:     "Don Fedyk" <[email-masked]>
> > > >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>,
>"Farrel,
> > > >Adrian" <[email-masked]>, "ccamp" <[email-masked]>,
>"Brungard,
> > > >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> > > ><[email-masked]>, "Drake, John E"
> ><[email-masked]>,
> > > >"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
> > > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new
>WG
> > > >I-Ds)
> > > >
> > > >
> > > >
> > > >Don,
> > > >
> > > >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > > > >I think there may be something here but I think even the
>requirements
> > >as
> > > > >stated assume too much of the solution. What is the real issue?
> > > >
> > > >Per my previous e-mail:
> > > >At 01:01 PM 8/24/2006, Lou Berger wrote:
> > > >
> > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > > > >>[...]
> > > > >>If we were to ask could you live without the CP->MP feature what
> > > > >>response would we get versus asking if CP->MP is a soft
>requirement.
> > > > >
> > > > > From the discussions I've had on this with carriers, for some 
it's
> > > > > a don't care, for others they won't deploy control plane without
> > > > > this capability.
> > > > >
> > > > >Lou
> > > >
> > > >AND
> > > >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > > > >[...]I therefore think the definition of CP->MP *is*
> > > > >required.  There are multiple options for meeting this 
requirement,
> > > > >but the solution must provide the "fallback" capability for
>services
> > > > >existing at the time of the initial MP->CP transition and those
> > > > >created after the transition.
> > > >[...]
> > > >
> > > >I think a capability to remove LSP state while leaving forward 
state
> > > >untouched will meet the requirements of those I've talked with.
> > > >
> > > >Lou
> > > >
> > > > >Regards,
> > > > >Don

Delivery-date: Fri, 25 Aug 2006 20:02:03 +0000
To: Lou Berger <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, Lou Berger <[email-masked]>, "Li, Han" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, [email-masked]
Subject: RE: CP-->MP Issue - non-issue
From: [email-masked]
Date: Fri, 25 Aug 2006 22:00:14 +0200

lou - 

one justification i was thinking of is the move of a connection outside CP 
control for off-line testing between specific segments (nodes 
interconnected by "passive" equipment for inst.)

thanks,
- dimitri.

Lou Berger <[email-masked]>
25/08/2006 21:14
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <[email-masked]>, "Farrel, Adrian" 
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Diego Caviglia" <[email-masked]>, "Don Fedyk" 
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John 
E" <[email-masked]>, "Li, Han" <[email-masked]>, "Ong, 
Lyndon" <[email-masked]>, [email-masked]
        Subject:        RE: CP-->MP Issue - non-issue

Dimitri,

See below.

At 03:08 PM 8/25/2006, [email-masked] wrote:

>lou
>
> > Given this, what's your objection here?
>
>that the move that we're discussing is not due to issues of CP
>resiliency/reliability/capability/or anything else equivalent

Assuming I understand what you're saying (i.e., that there is no 
motivation to have this feature due to failings/limitations of the 
control plane) then I agree 100%.

>i have pointed this to authors since the initial e-mail that started all
>this thread - hence, i can think of reason to allow for such move - but
>not at all for the reasons expressed since so far

okay, I'll bite.  What are the reasons/justifications for this that 
you belive  in?

Lou
>-d.
>
>
>
>
>
>Lou Berger <[email-masked]>
>Sent by: [email-masked]
>25/08/2006 21:02
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     "Ong, Lyndon" <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han"
><[email-masked]>, [email-masked]
>         Subject:        RE: CP-->MP Issue - non-issue
>
>
>Dimitri,
>          not sure about past discussions, but you're characterization
>of (at least) my position is just plain wrong.  I don't think this
>has anything to do with "unreliable control plane operations".  As I
>said before, the requirement for this comes from the need to have a
>symmetric operation to gain acceptance by some carriers.
>
>  From your previous mail, it sounds like you think this capability
>already exists.  Given this, what's your objection here?
>
>Lou
>
>At 01:47 PM 8/25/2006, [email-masked] wrote:
>
> >i agree on this CCAMP has/is building a self-consistent set of 
mechanisms
> >(from the start CCAMP considered that the MP has not being fallback
> >whatsover of the CP operations and in particular not linking any of its
> >operations to a particular MP)
> >
> >all what i am hearing from igor and co. is just penalizing the work of
> >this group achieved since 6 years without technical justification ***
> >there is no need for MP intervention in order to obtain CP operations
> >resiliency/reliability *** second time we have such discussion (look 
back
> >on the archive around end-october 2005, nov.2005 you will see there 
that
> >the same people already pushed forward the idea of unreliable control
> >plane operations - if someone's implementation is unstable/unreliable 
it
> >is not up to CCAMP to solve such issue and certainly not by interfering
> >with the MP)
> >
> >ps: add also add CP GR restart (from intermediate and source node)
> >
> >-d.
> >
> >
> >
> >
> >"Ong, Lyndon" <[email-masked]>
> >25/08/2006 19:22
> >
> >         To:     "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Farrel,
> >Adrian" <[email-masked]>
> >         cc:     "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Drake, John E" <[email-masked]>, "Lou
> >Berger" <[email-masked]>, "Li, Han" <[email-masked]>,
> ><[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL,
> >"Bryskin, Igor" <[email-masked]>
> >         Subject:        RE: CP-->MP Issue - non-issue
> >
> >
> >Hi Folks,
> >
> >Just a bit worried that this discussion may be causing the impression
> >that
> >control plane is somehow unstable and requires some kind of special
> >backup!
> >
> >Deborah and other carrier representatives can attest that control plane
> >(although not necessarily standard GMPLS) has been deployed and in
> >operation
> >in a number of carrier networks for some years without experiencing any
> >major failures.  There are already methods in use for ensuring the
> >reliability
> >of the control plane such as redundant control processors, non-volatile
> >storage of control plane data, software verification and testing, etc.
> >
> >I don't believe it was the intention of GMPLS work to require some kind
> >of
> >fallback to central management system control, hopefully everyone 
agrees
> >on this!
> >Cheers,
> >Lyndon

Delivery-date: Fri, 25 Aug 2006 19:16:54 +0000
content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Fri, 25 Aug 2006 15:16:48 -0400
From: "Bryskin, Igor" <[email-masked]>
To: <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, <[email-masked]>

Dimitri,

We do need an action from CP: we need a way to signal differently normal =
graceful shutdown and "removal CP state only" shutdown,
We cannot overload or change semantics of the "D" bit at this point.

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 3:04 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

igor

you are hanging on "breaking cross-connection" ... what i am telling to=20
you is that there is no action required from the CP viewpoint beside=20
preventing any error/alarm and removing the control plane state (for a=20
data plane state that doesn't exist anymore from the CP perspective) =
there=20
is no difference from the presence or absence of cross-connection ...=20
otherwise we would have already a PathTear error of some kind.

you have in mind to involve the CP signaling in this move - which is=20
totally beyond scope -=20

-d.=20

"Bryskin, Igor" <[email-masked]>
25/08/2006 20:52
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp"=20
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, =

ALABS" <[email-masked]>, "Diego Caviglia" =
<[email-masked]>,=20
"Don Fedyk" <[email-masked]>, "Drake, John E"=20
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han"=20
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
I-Ds)

Dimitri,

No, it is not. D-bit was designed for a normal release. In normal =
release=20
CP is responsible for breaking cross-connects (for example to avoid=20
mis-connections during subsequent setups).

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:46 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

igor - but it is exactly what happens the resource reservation =
disappears=20
from the control plane viewpoint (after which a pathtear is sent to =
remove=20

the control plane state)

-d.

"Bryskin, Igor" <[email-masked]>
Sent by: [email-masked]
25/08/2006 20:37
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp"=20
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, =

ALABS" <[email-masked]>, "Diego Caviglia" =
<[email-masked]>,=20

"Don Fedyk" <[email-masked]>, "Drake, John E"=20
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han"=20
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
I-Ds)

Dimitri,

We use D-bit for graceful shutdown. D-bit means prepare for delete. We =
do=20
graceful shutdown normally. We need another bit for this exceptional=20
release (without breaking cross-connects).

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:29 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

igor=20

but you don't need more than what's in RFC 3473 than disabling alarms=20
during the move of the resource associated to the CP to another enitity=20
and the send a pathtear to remove the control plane state (you don't =
need=20
to involve the CP in moving the data plane resource on each node)

-d.
=20

"Bryskin, Igor" <[email-masked]>
25/08/2006 20:02
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger"=20
<[email-masked]>
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp"=20
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, =

ALABS" <[email-masked]>, "Diego Caviglia" =
<[email-masked]>,=20

"Don Fedyk" <[email-masked]>, "Drake, John E"=20
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han"=20
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
I-Ds)

Dimitri,

graceful deletion bit set in admin_status you mentioned about is sent in =

Path and Modify messages and is meant for disabling alarms before you=20
starting LSP teardown.

What we are talking about is nothing but a bit in PathTear message=20
instructing resource manager on each node not to break cross-connects=20
while LSP resources are removed.

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 1:35 PM
To: Lou Berger
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

lou - i mean that in case an LSP for whatever reason needs to be moved=20
from the control plane to another place

this is already covered in RFC 3473 - the LSP is signaled with graceful=20
deletion bit set in admin_status, then on each node the resource is=20
associated to that entity (which is not a CP business) and then the=20
control plane state is removed

hope this clarifies,
-d.

Lou Berger <[email-masked]>
25/08/2006 19:25
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"=20
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"=20
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,=20
"Diego Caviglia" <[email-masked]>, "Don Fedyk"=20
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John =

E" <[email-masked]>, "Li, Han" <[email-masked]>,=20
[email-masked]
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
I-Ds)

Dimitri,
         I really don't understand your point.  Can you =
restate/rephrase?

Lou

At 01:03 PM 8/25/2006, [email-masked] wrote:

>lou
>
>resource are present (data plane state remains) the operation we're
>discussing about is local and consist in associating that resource to
>another entity - you GR the path because you don't want to generate=20
errors
>- but then that's it you just have to retrieve the CP state
>
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 18:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, =
John
>E" <[email-masked]>, "Li, Han" <[email-masked]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Dimitri,
>
>huh, why would there be no resources, i.e., data plane state,
>associated with the LSP?  If this were the case, I agree the whole
>discussion would be moot.
>
>Lou
>
>At 12:48 PM 8/25/2006, [email-masked] wrote:
>
> >lou,
> >
> >like i replied to igor
> >
> >"entity X wants to recuperate a CP state - just let it do - if so=20
allowed
> >
> >then send a PathTear since there is no resource anymore associate to=20
that
> >state (but this does not require any specific documentation)"
> >
> >we would deleting a path/resv state for which no resource are =
allocated=20

-
> >we did already that exercise - GR deletion.
> >
> >much thanks,
> >-d.
> >
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >Sent by: [email-masked]
> >25/08/2006 18:32
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,=20
John
> >E" <[email-masked]>, "Li, Han" <[email-masked]>,
> >[email-masked]
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new =
WG
> >I-Ds)
> >
> >
> >Dimitri,
> >          Removing state should be a simple process of deleting local
> >control plane state while not impacting the data plane
> >state.  Exporting, at least to me, implies a more complicated API or
> >other information transaction processing, which is certainly not =
needed
> >here.
> >
> >I think we're talking about a mechanism that should require a single
> >"preserve data plane" bit in a PathTear message.  Nothing more.
> >
> >Lou
> >
> >At 12:14 PM 8/25/2006, [email-masked] wrote:
> >
> > >lou - isn't "remove" or "export" having the same meaning in the=20
present
> > >context ?
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >Sent by: [email-masked]
> > >25/08/2006 17:57
> > >
> > >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> > ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> > ><[email-masked]>, "Brungard, Deborah A, ALABS" =
<[email-masked]>,
> > >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> > ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,
>John
> > >E" <[email-masked]>, "Li, Han" <[email-masked]>
> > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new =

WG
> > >I-Ds)
> > >
> > >
> > >Who said anything about exporting state?
> > >
> > >At 11:51 AM 8/25/2006, [email-masked] wrote:
> > >
> > > >lou - and why shall CCAMP provide a function to export states=20
outside
> >of
> > > >its domain of competence
> > > >
> > > >thanks,
> > > >- d.
> > > >
> > > >
> > > >
> > > >
> > > >Lou Berger <[email-masked]>
> > > >25/08/2006 17:49
> > > >
> > > >         To:     "Don Fedyk" <[email-masked]>
> > > >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>,
>"Farrel,
> > > >Adrian" <[email-masked]>, "ccamp" <[email-masked]>,
>"Brungard,
> > > >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> > > ><[email-masked]>, "Drake, John E"
> ><[email-masked]>,
> > > >"Lou Berger" <[email-masked]>, "Li, Han" =
<[email-masked]>
> > > >         Subject:        RE: CP-->MP Issue (was RE: Polling for =
new
>WG
> > > >I-Ds)
> > > >
> > > >
> > > >
> > > >Don,
> > > >
> > > >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > > > >I think there may be something here but I think even the
>requirements
> > >as
> > > > >stated assume too much of the solution. What is the real issue?
> > > >
> > > >Per my previous e-mail:
> > > >At 01:01 PM 8/24/2006, Lou Berger wrote:
> > > >
> > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > > > >>[...]
> > > > >>If we were to ask could you live without the CP->MP feature =
what
> > > > >>response would we get versus asking if CP->MP is a soft
>requirement.
> > > > >
> > > > > From the discussions I've had on this with carriers, for some=20
it's
> > > > > a don't care, for others they won't deploy control plane =
without
> > > > > this capability.
> > > > >
> > > > >Lou
> > > >
> > > >AND
> > > >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > > > >[...]I therefore think the definition of CP->MP *is*
> > > > >required.  There are multiple options for meeting this=20
requirement,
> > > > >but the solution must provide the "fallback" capability for
>services
> > > > >existing at the time of the initial MP->CP transition and those
> > > > >created after the transition.
> > > >[...]
> > > >
> > > >I think a capability to remove LSP state while leaving forward=20
state
> > > >untouched will meet the requirements of those I've talked with.
> > > >
> > > >Lou
> > > >
> > > > >Regards,
> > > > >Don

Delivery-date: Fri, 25 Aug 2006 19:14:54 +0000
Date: Fri, 25 Aug 2006 15:14:31 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: RE: CP-->MP Issue - non-issue
Cc: Lou Berger <[email-masked]>,"Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>,"Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>,"Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, "Li, Han" <[email-masked]>,"Ong, Lyndon" <[email-masked]>, [email-masked]

Dimitri,

See below.

At 03:08 PM 8/25/2006, [email-masked] wrote:

>lou
>
> > Given this, what's your objection here?
>
>that the move that we're discussing is not due to issues of CP
>resiliency/reliability/capability/or anything else equivalent

Assuming I understand what you're saying (i.e., that there is no 
motivation to have this feature due to failings/limitations of the 
control plane) then I agree 100%.

>i have pointed this to authors since the initial e-mail that started all
>this thread - hence, i can think of reason to allow for such move - but
>not at all for the reasons expressed since so far

okay, I'll bite.  What are the reasons/justifications for this that 
you belive  in?

Lou
>-d.
>
>
>
>
>
>Lou Berger <[email-masked]>
>Sent by: [email-masked]
>25/08/2006 21:02
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     "Ong, Lyndon" <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han"
><[email-masked]>, [email-masked]
>         Subject:        RE: CP-->MP Issue - non-issue
>
>
>Dimitri,
>          not sure about past discussions, but you're characterization
>of (at least) my position is just plain wrong.  I don't think this
>has anything to do with "unreliable control plane operations".  As I
>said before, the requirement for this comes from the need to have a
>symmetric operation to gain acceptance by some carriers.
>
>  From your previous mail, it sounds like you think this capability
>already exists.  Given this, what's your objection here?
>
>Lou
>
>At 01:47 PM 8/25/2006, [email-masked] wrote:
>
> >i agree on this CCAMP has/is building a self-consistent set of mechanisms
> >(from the start CCAMP considered that the MP has not being fallback
> >whatsover of the CP operations and in particular not linking any of its
> >operations to a particular MP)
> >
> >all what i am hearing from igor and co. is just penalizing the work of
> >this group achieved since 6 years without technical justification ***
> >there is no need for MP intervention in order to obtain CP operations
> >resiliency/reliability *** second time we have such discussion (look back
> >on the archive around end-october 2005, nov.2005 you will see there that
> >the same people already pushed forward the idea of unreliable control
> >plane operations - if someone's implementation is unstable/unreliable it
> >is not up to CCAMP to solve such issue and certainly not by interfering
> >with the MP)
> >
> >ps: add also add CP GR restart (from intermediate and source node)
> >
> >-d.
> >
> >
> >
> >
> >"Ong, Lyndon" <[email-masked]>
> >25/08/2006 19:22
> >
> >         To:     "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Farrel,
> >Adrian" <[email-masked]>
> >         cc:     "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Drake, John E" <[email-masked]>, "Lou
> >Berger" <[email-masked]>, "Li, Han" <[email-masked]>,
> ><[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL,
> >"Bryskin, Igor" <[email-masked]>
> >         Subject:        RE: CP-->MP Issue - non-issue
> >
> >
> >Hi Folks,
> >
> >Just a bit worried that this discussion may be causing the impression
> >that
> >control plane is somehow unstable and requires some kind of special
> >backup!
> >
> >Deborah and other carrier representatives can attest that control plane
> >(although not necessarily standard GMPLS) has been deployed and in
> >operation
> >in a number of carrier networks for some years without experiencing any
> >major failures.  There are already methods in use for ensuring the
> >reliability
> >of the control plane such as redundant control processors, non-volatile
> >storage of control plane data, software verification and testing, etc.
> >
> >I don't believe it was the intention of GMPLS work to require some kind
> >of
> >fallback to central management system control, hopefully everyone agrees
> >on this!
> >
> >Cheers,
> >
> >Lyndon

Delivery-date: Fri, 25 Aug 2006 19:09:29 +0000
To: Lou Berger <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, [email-masked]
Subject: RE: CP-->MP Issue - non-issue
From: [email-masked]
Date: Fri, 25 Aug 2006 21:08:23 +0200

lou 

> Given this, what's your objection here?

that the move that we're discussing is not due to issues of CP 
resiliency/reliability/capability/or anything else equivalent

i have pointed this to authors since the initial e-mail that started all 
this thread - hence, i can think of reason to allow for such move - but 
not at all for the reasons expressed since so far

-d. 

Lou Berger <[email-masked]>
Sent by: [email-masked]
25/08/2006 21:02
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Ong, Lyndon" <[email-masked]>, "Farrel, Adrian" 
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Diego Caviglia" <[email-masked]>, "Don Fedyk" 
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John 
E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" 
<[email-masked]>, [email-masked]
        Subject:        RE: CP-->MP Issue - non-issue

Dimitri,
         not sure about past discussions, but you're characterization 
of (at least) my position is just plain wrong.  I don't think this 
has anything to do with "unreliable control plane operations".  As I 
said before, the requirement for this comes from the need to have a 
symmetric operation to gain acceptance by some carriers.

 From your previous mail, it sounds like you think this capability 
already exists.  Given this, what's your objection here?

Lou

At 01:47 PM 8/25/2006, [email-masked] wrote:

>i agree on this CCAMP has/is building a self-consistent set of mechanisms
>(from the start CCAMP considered that the MP has not being fallback
>whatsover of the CP operations and in particular not linking any of its
>operations to a particular MP)
>
>all what i am hearing from igor and co. is just penalizing the work of
>this group achieved since 6 years without technical justification ***
>there is no need for MP intervention in order to obtain CP operations
>resiliency/reliability *** second time we have such discussion (look back
>on the archive around end-october 2005, nov.2005 you will see there that
>the same people already pushed forward the idea of unreliable control
>plane operations - if someone's implementation is unstable/unreliable it
>is not up to CCAMP to solve such issue and certainly not by interfering
>with the MP)
>
>ps: add also add CP GR restart (from intermediate and source node)
>
>-d.
>
>
>
>
>"Ong, Lyndon" <[email-masked]>
>25/08/2006 19:22
>
>         To:     "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Farrel,
>Adrian" <[email-masked]>
>         cc:     "ccamp" <[email-masked]>, "Dan Li" 
<[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Drake, John E" <[email-masked]>, "Lou
>Berger" <[email-masked]>, "Li, Han" <[email-masked]>,
><[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL,
>"Bryskin, Igor" <[email-masked]>
>         Subject:        RE: CP-->MP Issue - non-issue
>
>
>Hi Folks,
>
>Just a bit worried that this discussion may be causing the impression
>that
>control plane is somehow unstable and requires some kind of special
>backup!
>
>Deborah and other carrier representatives can attest that control plane
>(although not necessarily standard GMPLS) has been deployed and in
>operation
>in a number of carrier networks for some years without experiencing any
>major failures.  There are already methods in use for ensuring the
>reliability
>of the control plane such as redundant control processors, non-volatile
>storage of control plane data, software verification and testing, etc.
>
>I don't believe it was the intention of GMPLS work to require some kind
>of
>fallback to central management system control, hopefully everyone agrees
>on this!
>
>Cheers,
>
>Lyndon

Delivery-date: Fri, 25 Aug 2006 19:05:40 +0000
To: "Bryskin, Igor" <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, [email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 21:03:44 +0200

igor

you are hanging on "breaking cross-connection" ... what i am telling to 
you is that there is no action required from the CP viewpoint beside 
preventing any error/alarm and removing the control plane state (for a 
data plane state that doesn't exist anymore from the CP perspective) there 
is no difference from the presence or absence of cross-connection ... 
otherwise we would have already a PathTear error of some kind.

you have in mind to involve the CP signaling in this move - which is 
totally beyond scope - 

-d. 

"Bryskin, Igor" <[email-masked]>
25/08/2006 20:52
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, 
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, 
"Don Fedyk" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" 
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,

No, it is not. D-bit was designed for a normal release. In normal release 
CP is responsible for breaking cross-connects (for example to avoid 
mis-connections during subsequent setups).

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:46 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

igor - but it is exactly what happens the resource reservation disappears 
from the control plane viewpoint (after which a pathtear is sent to remove 

the control plane state)

-d.

"Bryskin, Igor" <[email-masked]>
Sent by: [email-masked]
25/08/2006 20:37
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, 
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, 

"Don Fedyk" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" 
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,

We use D-bit for graceful shutdown. D-bit means prepare for delete. We do 
graceful shutdown normally. We need another bit for this exceptional 
release (without breaking cross-connects).

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:29 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

igor 

but you don't need more than what's in RFC 3473 than disabling alarms 
during the move of the resource associated to the CP to another enitity 
and the send a pathtear to remove the control plane state (you don't need 
to involve the CP in moving the data plane resource on each node)

-d.

"Bryskin, Igor" <[email-masked]>
25/08/2006 20:02
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger" 
<[email-masked]>
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, 
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, 

"Don Fedyk" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" 
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,

graceful deletion bit set in admin_status you mentioned about is sent in 
Path and Modify messages and is meant for disabling alarms before you 
starting LSP teardown.

What we are talking about is nothing but a bit in PathTear message 
instructing resource manager on each node not to break cross-connects 
while LSP resources are removed.

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 1:35 PM
To: Lou Berger
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

lou - i mean that in case an LSP for whatever reason needs to be moved 
from the control plane to another place

this is already covered in RFC 3473 - the LSP is signaled with graceful 
deletion bit set in admin_status, then on each node the resource is 
associated to that entity (which is not a CP business) and then the 
control plane state is removed

hope this clarifies,
-d.

Lou Berger <[email-masked]>
25/08/2006 19:25
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <[email-masked]>, "Farrel, Adrian" 
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Diego Caviglia" <[email-masked]>, "Don Fedyk" 
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John 
E" <[email-masked]>, "Li, Han" <[email-masked]>, 
[email-masked]
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,
         I really don't understand your point.  Can you restate/rephrase?

Lou

At 01:03 PM 8/25/2006, [email-masked] wrote:

>lou
>
>resource are present (data plane state remains) the operation we're
>discussing about is local and consist in associating that resource to
>another entity - you GR the path because you don't want to generate 
errors
>- but then that's it you just have to retrieve the CP state
>
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 18:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Li, Han" <[email-masked]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Dimitri,
>
>huh, why would there be no resources, i.e., data plane state,
>associated with the LSP?  If this were the case, I agree the whole
>discussion would be moot.
>
>Lou
>
>At 12:48 PM 8/25/2006, [email-masked] wrote:
>
> >lou,
> >
> >like i replied to igor
> >
> >"entity X wants to recuperate a CP state - just let it do - if so 
allowed
> >
> >then send a PathTear since there is no resource anymore associate to 
that
> >state (but this does not require any specific documentation)"
> >
> >we would deleting a path/resv state for which no resource are allocated 

-
> >we did already that exercise - GR deletion.
> >
> >much thanks,
> >-d.
> >
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >Sent by: [email-masked]
> >25/08/2006 18:32
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, 
John
> >E" <[email-masked]>, "Li, Han" <[email-masked]>,
> >[email-masked]
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> >I-Ds)
> >
> >
> >Dimitri,
> >          Removing state should be a simple process of deleting local
> >control plane state while not impacting the data plane
> >state.  Exporting, at least to me, implies a more complicated API or
> >other information transaction processing, which is certainly not needed
> >here.
> >
> >I think we're talking about a mechanism that should require a single
> >"preserve data plane" bit in a PathTear message.  Nothing more.
> >
> >Lou
> >
> >At 12:14 PM 8/25/2006, [email-masked] wrote:
> >
> > >lou - isn't "remove" or "export" having the same meaning in the 
present
> > >context ?
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >Sent by: [email-masked]
> > >25/08/2006 17:57
> > >
> > >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> > ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> > ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> > >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> > ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,
>John
> > >E" <[email-masked]>, "Li, Han" <[email-masked]>
> > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new 
WG
> > >I-Ds)
> > >
> > >
> > >Who said anything about exporting state?
> > >
> > >At 11:51 AM 8/25/2006, [email-masked] wrote:
> > >
> > > >lou - and why shall CCAMP provide a function to export states 
outside
> >of
> > > >its domain of competence
> > > >
> > > >thanks,
> > > >- d.
> > > >
> > > >
> > > >
> > > >
> > > >Lou Berger <[email-masked]>
> > > >25/08/2006 17:49
> > > >
> > > >         To:     "Don Fedyk" <[email-masked]>
> > > >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>,
>"Farrel,
> > > >Adrian" <[email-masked]>, "ccamp" <[email-masked]>,
>"Brungard,
> > > >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> > > ><[email-masked]>, "Drake, John E"
> ><[email-masked]>,
> > > >"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
> > > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new
>WG
> > > >I-Ds)
> > > >
> > > >
> > > >
> > > >Don,
> > > >
> > > >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > > > >I think there may be something here but I think even the
>requirements
> > >as
> > > > >stated assume too much of the solution. What is the real issue?
> > > >
> > > >Per my previous e-mail:
> > > >At 01:01 PM 8/24/2006, Lou Berger wrote:
> > > >
> > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > > > >>[...]
> > > > >>If we were to ask could you live without the CP->MP feature what
> > > > >>response would we get versus asking if CP->MP is a soft
>requirement.
> > > > >
> > > > > From the discussions I've had on this with carriers, for some 
it's
> > > > > a don't care, for others they won't deploy control plane without
> > > > > this capability.
> > > > >
> > > > >Lou
> > > >
> > > >AND
> > > >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > > > >[...]I therefore think the definition of CP->MP *is*
> > > > >required.  There are multiple options for meeting this 
requirement,
> > > > >but the solution must provide the "fallback" capability for
>services
> > > > >existing at the time of the initial MP->CP transition and those
> > > > >created after the transition.
> > > >[...]
> > > >
> > > >I think a capability to remove LSP state while leaving forward 
state
> > > >untouched will meet the requirements of those I've talked with.
> > > >
> > > >Lou
> > > >
> > > > >Regards,
> > > > >Don

Delivery-date: Fri, 25 Aug 2006 19:02:52 +0000
Date: Fri, 25 Aug 2006 15:02:30 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: RE: CP-->MP Issue - non-issue
Cc: "Ong, Lyndon" <[email-masked]>,"Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>,"Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>,"Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>,"Li, Han" <[email-masked]>, [email-masked]

Dimitri,
         not sure about past discussions, but you're characterization 
of (at least) my position is just plain wrong.  I don't think this 
has anything to do with "unreliable control plane operations".  As I 
said before, the requirement for this comes from the need to have a 
symmetric operation to gain acceptance by some carriers.

 From your previous mail, it sounds like you think this capability 
already exists.  Given this, what's your objection here?

Lou

At 01:47 PM 8/25/2006, [email-masked] wrote:

>i agree on this CCAMP has/is building a self-consistent set of mechanisms
>(from the start CCAMP considered that the MP has not being fallback
>whatsover of the CP operations and in particular not linking any of its
>operations to a particular MP)
>
>all what i am hearing from igor and co. is just penalizing the work of
>this group achieved since 6 years without technical justification ***
>there is no need for MP intervention in order to obtain CP operations
>resiliency/reliability *** second time we have such discussion (look back
>on the archive around end-october 2005, nov.2005 you will see there that
>the same people already pushed forward the idea of unreliable control
>plane operations - if someone's implementation is unstable/unreliable it
>is not up to CCAMP to solve such issue and certainly not by interfering
>with the MP)
>
>ps: add also add CP GR restart (from intermediate and source node)
>
>-d.
>
>
>
>
>"Ong, Lyndon" <[email-masked]>
>25/08/2006 19:22
>
>         To:     "Brungard, Deborah A, ALABS" <[email-masked]>, "Farrel,
>Adrian" <[email-masked]>
>         cc:     "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Drake, John E" <[email-masked]>, "Lou
>Berger" <[email-masked]>, "Li, Han" <[email-masked]>,
><[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL,
>"Bryskin, Igor" <[email-masked]>
>         Subject:        RE: CP-->MP Issue - non-issue
>
>
>Hi Folks,
>
>Just a bit worried that this discussion may be causing the impression
>that
>control plane is somehow unstable and requires some kind of special
>backup!
>
>Deborah and other carrier representatives can attest that control plane
>(although not necessarily standard GMPLS) has been deployed and in
>operation
>in a number of carrier networks for some years without experiencing any
>major failures.  There are already methods in use for ensuring the
>reliability
>of the control plane such as redundant control processors, non-volatile
>storage of control plane data, software verification and testing, etc.
>
>I don't believe it was the intention of GMPLS work to require some kind
>of
>fallback to central management system control, hopefully everyone agrees
>on this!
>
>Cheers,
>
>Lyndon

Delivery-date: Fri, 25 Aug 2006 18:58:10 +0000
Date: Fri, 25 Aug 2006 14:57:37 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Cc: Lou Berger <[email-masked]>,"Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>,"Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>,"Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, "Li, Han" <[email-masked]>,[email-masked]

Dimitri,
         I agree that all is needed is a single bit.  Unfortunately, 
the bits you mention are used for other purposes.  (i.e., alarm free 
LSP deletion.)

Lou

At 01:34 PM 8/25/2006, [email-masked] wrote:

>lou - i mean that in case an LSP for whatever reason needs to be moved
>from the control plane to another place
>
>this is already covered in RFC 3473 - the LSP is signaled with graceful
>deletion bit set in admin_status, then on each node the resource is
>associated to that entity (which is not a CP business) and then the
>control plane state is removed
>
>hope this clarifies,
>-d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 19:25
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Li, Han" <[email-masked]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Dimitri,
>          I really don't understand your point.  Can you restate/rephrase?
>
>Lou
>
>At 01:03 PM 8/25/2006, [email-masked] wrote:
>
> >lou
> >
> >resource are present (data plane state remains) the operation we're
> >discussing about is local and consist in associating that resource to
> >another entity - you GR the path because you don't want to generate
>errors
> >- but then that's it you just have to retrieve the CP state
> >
> >- d.
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >25/08/2006 18:57
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
> >E" <[email-masked]>, "Li, Han" <[email-masked]>,
> >[email-masked]
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> >I-Ds)
> >
> >
> >Dimitri,
> >
> >huh, why would there be no resources, i.e., data plane state,
> >associated with the LSP?  If this were the case, I agree the whole
> >discussion would be moot.
> >
> >Lou
> >
> >At 12:48 PM 8/25/2006, [email-masked] wrote:
> >
> > >lou,
> > >
> > >like i replied to igor
> > >
> > >"entity X wants to recuperate a CP state - just let it do - if so
>allowed
> > >
> > >then send a PathTear since there is no resource anymore associate to
>that
> > >state (but this does not require any specific documentation)"
> > >
> > >we would deleting a path/resv state for which no resource are allocated
>-
> > >we did already that exercise - GR deletion.
> > >
> > >much thanks,
> > >-d.
> > >
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >Sent by: [email-masked]
> > >25/08/2006 18:32
> > >
> > >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> > ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> > ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> > >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> > ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,
>John
> > >E" <[email-masked]>, "Li, Han" <[email-masked]>,
> > >[email-masked]
> > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> > >I-Ds)
> > >
> > >
> > >Dimitri,
> > >          Removing state should be a simple process of deleting local
> > >control plane state while not impacting the data plane
> > >state.  Exporting, at least to me, implies a more complicated API or
> > >other information transaction processing, which is certainly not needed
> > >here.
> > >
> > >I think we're talking about a mechanism that should require a single
> > >"preserve data plane" bit in a PathTear message.  Nothing more.
> > >
> > >Lou
> > >
> > >At 12:14 PM 8/25/2006, [email-masked] wrote:
> > >
> > > >lou - isn't "remove" or "export" having the same meaning in the
>present
> > > >context ?
> > > >
> > > >
> > > >
> > > >
> > > >Lou Berger <[email-masked]>
> > > >Sent by: [email-masked]
> > > >25/08/2006 17:57
> > > >
> > > >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > > >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> > > ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> > > ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> > > >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> > > ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,
> >John
> > > >E" <[email-masked]>, "Li, Han" <[email-masked]>
> > > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new
>WG
> > > >I-Ds)
> > > >
> > > >
> > > >Who said anything about exporting state?
> > > >
> > > >At 11:51 AM 8/25/2006, [email-masked] wrote:
> > > >
> > > > >lou - and why shall CCAMP provide a function to export states
>outside
> > >of
> > > > >its domain of competence
> > > > >
> > > > >thanks,
> > > > >- d.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >Lou Berger <[email-masked]>
> > > > >25/08/2006 17:49
> > > > >
> > > > >         To:     "Don Fedyk" <[email-masked]>
> > > > >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>,
> >"Farrel,
> > > > >Adrian" <[email-masked]>, "ccamp" <[email-masked]>,
> >"Brungard,
> > > > >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> > > > ><[email-masked]>, "Drake, John E"
> > ><[email-masked]>,
> > > > >"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
> > > > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new
> >WG
> > > > >I-Ds)
> > > > >
> > > > >
> > > > >
> > > > >Don,
> > > > >
> > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > > > > >I think there may be something here but I think even the
> >requirements
> > > >as
> > > > > >stated assume too much of the solution. What is the real issue?
> > > > >
> > > > >Per my previous e-mail:
> > > > >At 01:01 PM 8/24/2006, Lou Berger wrote:
> > > > >
> > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > > > > >>[...]
> > > > > >>If we were to ask could you live without the CP->MP feature what
> > > > > >>response would we get versus asking if CP->MP is a soft
> >requirement.
> > > > > >
> > > > > > From the discussions I've had on this with carriers, for some
>it's
> > > > > > a don't care, for others they won't deploy control plane without
> > > > > > this capability.
> > > > > >
> > > > > >Lou
> > > > >
> > > > >AND
> > > > >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > > > > >[...]I therefore think the definition of CP->MP *is*
> > > > > >required.  There are multiple options for meeting this
>requirement,
> > > > > >but the solution must provide the "fallback" capability for
> >services
> > > > > >existing at the time of the initial MP->CP transition and those
> > > > > >created after the transition.
> > > > >[...]
> > > > >
> > > > >I think a capability to remove LSP state while leaving forward
>state
> > > > >untouched will meet the requirements of those I've talked with.
> > > > >
> > > > >Lou
> > > > >
> > > > > >Regards,
> > > > > >Don

Delivery-date: Fri, 25 Aug 2006 18:52:15 +0000
content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Fri, 25 Aug 2006 14:52:07 -0400
From: "Bryskin, Igor" <[email-masked]>
To: <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, <[email-masked]>

Dimitri,

No, it is not. D-bit was designed for a normal release. In normal =
release CP is responsible for breaking cross-connects (for example to =
avoid mis-connections during subsequent setups).

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:46 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

igor - but it is exactly what happens the resource reservation =
disappears=20
from the control plane viewpoint (after which a pathtear is sent to =
remove=20
the control plane state)

-d.

"Bryskin, Igor" <[email-masked]>
Sent by: [email-masked]
25/08/2006 20:37
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp"=20
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, =

ALABS" <[email-masked]>, "Diego Caviglia" =
<[email-masked]>,=20
"Don Fedyk" <[email-masked]>, "Drake, John E"=20
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han"=20
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
I-Ds)

Dimitri,

We use D-bit for graceful shutdown. D-bit means prepare for delete. We =
do=20
graceful shutdown normally. We need another bit for this exceptional=20
release (without breaking cross-connects).

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:29 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

igor=20

but you don't need more than what's in RFC 3473 than disabling alarms=20
during the move of the resource associated to the CP to another enitity=20
and the send a pathtear to remove the control plane state (you don't =
need=20
to involve the CP in moving the data plane resource on each node)

-d.
=20

"Bryskin, Igor" <[email-masked]>
25/08/2006 20:02
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger"=20
<[email-masked]>
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp"=20
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, =

ALABS" <[email-masked]>, "Diego Caviglia" =
<[email-masked]>,=20

"Don Fedyk" <[email-masked]>, "Drake, John E"=20
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han"=20
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
I-Ds)

Dimitri,

graceful deletion bit set in admin_status you mentioned about is sent in =

Path and Modify messages and is meant for disabling alarms before you=20
starting LSP teardown.

What we are talking about is nothing but a bit in PathTear message=20
instructing resource manager on each node not to break cross-connects=20
while LSP resources are removed.

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 1:35 PM
To: Lou Berger
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

lou - i mean that in case an LSP for whatever reason needs to be moved=20
from the control plane to another place

this is already covered in RFC 3473 - the LSP is signaled with graceful=20
deletion bit set in admin_status, then on each node the resource is=20
associated to that entity (which is not a CP business) and then the=20
control plane state is removed

hope this clarifies,
-d.

Lou Berger <[email-masked]>
25/08/2006 19:25
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"=20
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"=20
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,=20
"Diego Caviglia" <[email-masked]>, "Don Fedyk"=20
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John =

E" <[email-masked]>, "Li, Han" <[email-masked]>,=20
[email-masked]
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
I-Ds)

Dimitri,
         I really don't understand your point.  Can you =
restate/rephrase?

Lou

At 01:03 PM 8/25/2006, [email-masked] wrote:

>lou
>
>resource are present (data plane state remains) the operation we're
>discussing about is local and consist in associating that resource to
>another entity - you GR the path because you don't want to generate=20
errors
>- but then that's it you just have to retrieve the CP state
>
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 18:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, =
John
>E" <[email-masked]>, "Li, Han" <[email-masked]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Dimitri,
>
>huh, why would there be no resources, i.e., data plane state,
>associated with the LSP?  If this were the case, I agree the whole
>discussion would be moot.
>
>Lou
>
>At 12:48 PM 8/25/2006, [email-masked] wrote:
>
> >lou,
> >
> >like i replied to igor
> >
> >"entity X wants to recuperate a CP state - just let it do - if so=20
allowed
> >
> >then send a PathTear since there is no resource anymore associate to=20
that
> >state (but this does not require any specific documentation)"
> >
> >we would deleting a path/resv state for which no resource are =
allocated=20

-
> >we did already that exercise - GR deletion.
> >
> >much thanks,
> >-d.
> >
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >Sent by: [email-masked]
> >25/08/2006 18:32
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,=20
John
> >E" <[email-masked]>, "Li, Han" <[email-masked]>,
> >[email-masked]
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new =
WG
> >I-Ds)
> >
> >
> >Dimitri,
> >          Removing state should be a simple process of deleting local
> >control plane state while not impacting the data plane
> >state.  Exporting, at least to me, implies a more complicated API or
> >other information transaction processing, which is certainly not =
needed
> >here.
> >
> >I think we're talking about a mechanism that should require a single
> >"preserve data plane" bit in a PathTear message.  Nothing more.
> >
> >Lou
> >
> >At 12:14 PM 8/25/2006, [email-masked] wrote:
> >
> > >lou - isn't "remove" or "export" having the same meaning in the=20
present
> > >context ?
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >Sent by: [email-masked]
> > >25/08/2006 17:57
> > >
> > >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> > ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> > ><[email-masked]>, "Brungard, Deborah A, ALABS" =
<[email-masked]>,
> > >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> > ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,
>John
> > >E" <[email-masked]>, "Li, Han" <[email-masked]>
> > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new =

WG
> > >I-Ds)
> > >
> > >
> > >Who said anything about exporting state?
> > >
> > >At 11:51 AM 8/25/2006, [email-masked] wrote:
> > >
> > > >lou - and why shall CCAMP provide a function to export states=20
outside
> >of
> > > >its domain of competence
> > > >
> > > >thanks,
> > > >- d.
> > > >
> > > >
> > > >
> > > >
> > > >Lou Berger <[email-masked]>
> > > >25/08/2006 17:49
> > > >
> > > >         To:     "Don Fedyk" <[email-masked]>
> > > >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>,
>"Farrel,
> > > >Adrian" <[email-masked]>, "ccamp" <[email-masked]>,
>"Brungard,
> > > >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> > > ><[email-masked]>, "Drake, John E"
> ><[email-masked]>,
> > > >"Lou Berger" <[email-masked]>, "Li, Han" =
<[email-masked]>
> > > >         Subject:        RE: CP-->MP Issue (was RE: Polling for =
new
>WG
> > > >I-Ds)
> > > >
> > > >
> > > >
> > > >Don,
> > > >
> > > >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > > > >I think there may be something here but I think even the
>requirements
> > >as
> > > > >stated assume too much of the solution. What is the real issue?
> > > >
> > > >Per my previous e-mail:
> > > >At 01:01 PM 8/24/2006, Lou Berger wrote:
> > > >
> > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > > > >>[...]
> > > > >>If we were to ask could you live without the CP->MP feature =
what
> > > > >>response would we get versus asking if CP->MP is a soft
>requirement.
> > > > >
> > > > > From the discussions I've had on this with carriers, for some=20
it's
> > > > > a don't care, for others they won't deploy control plane =
without
> > > > > this capability.
> > > > >
> > > > >Lou
> > > >
> > > >AND
> > > >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > > > >[...]I therefore think the definition of CP->MP *is*
> > > > >required.  There are multiple options for meeting this=20
requirement,
> > > > >but the solution must provide the "fallback" capability for
>services
> > > > >existing at the time of the initial MP->CP transition and those
> > > > >created after the transition.
> > > >[...]
> > > >
> > > >I think a capability to remove LSP state while leaving forward=20
state
> > > >untouched will meet the requirements of those I've talked with.
> > > >
> > > >Lou
> > > >
> > > > >Regards,
> > > > >Don

Delivery-date: Fri, 25 Aug 2006 18:47:24 +0000
To: "Bryskin, Igor" <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, [email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 20:46:13 +0200

igor - but it is exactly what happens the resource reservation disappears 
from the control plane viewpoint (after which a pathtear is sent to remove 
the control plane state)

-d.

"Bryskin, Igor" <[email-masked]>
Sent by: [email-masked]
25/08/2006 20:37
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, 
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, 
"Don Fedyk" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" 
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,

We use D-bit for graceful shutdown. D-bit means prepare for delete. We do 
graceful shutdown normally. We need another bit for this exceptional 
release (without breaking cross-connects).

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:29 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

igor 

but you don't need more than what's in RFC 3473 than disabling alarms 
during the move of the resource associated to the CP to another enitity 
and the send a pathtear to remove the control plane state (you don't need 
to involve the CP in moving the data plane resource on each node)

-d.

"Bryskin, Igor" <[email-masked]>
25/08/2006 20:02
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger" 
<[email-masked]>
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, 
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, 

"Don Fedyk" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" 
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,

graceful deletion bit set in admin_status you mentioned about is sent in 
Path and Modify messages and is meant for disabling alarms before you 
starting LSP teardown.

What we are talking about is nothing but a bit in PathTear message 
instructing resource manager on each node not to break cross-connects 
while LSP resources are removed.

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 1:35 PM
To: Lou Berger
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

lou - i mean that in case an LSP for whatever reason needs to be moved 
from the control plane to another place

this is already covered in RFC 3473 - the LSP is signaled with graceful 
deletion bit set in admin_status, then on each node the resource is 
associated to that entity (which is not a CP business) and then the 
control plane state is removed

hope this clarifies,
-d.

Lou Berger <[email-masked]>
25/08/2006 19:25
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <[email-masked]>, "Farrel, Adrian" 
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Diego Caviglia" <[email-masked]>, "Don Fedyk" 
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John 
E" <[email-masked]>, "Li, Han" <[email-masked]>, 
[email-masked]
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,
         I really don't understand your point.  Can you restate/rephrase?

Lou

At 01:03 PM 8/25/2006, [email-masked] wrote:

>lou
>
>resource are present (data plane state remains) the operation we're
>discussing about is local and consist in associating that resource to
>another entity - you GR the path because you don't want to generate 
errors
>- but then that's it you just have to retrieve the CP state
>
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 18:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Li, Han" <[email-masked]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Dimitri,
>
>huh, why would there be no resources, i.e., data plane state,
>associated with the LSP?  If this were the case, I agree the whole
>discussion would be moot.
>
>Lou
>
>At 12:48 PM 8/25/2006, [email-masked] wrote:
>
> >lou,
> >
> >like i replied to igor
> >
> >"entity X wants to recuperate a CP state - just let it do - if so 
allowed
> >
> >then send a PathTear since there is no resource anymore associate to 
that
> >state (but this does not require any specific documentation)"
> >
> >we would deleting a path/resv state for which no resource are allocated 

-
> >we did already that exercise - GR deletion.
> >
> >much thanks,
> >-d.
> >
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >Sent by: [email-masked]
> >25/08/2006 18:32
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, 
John
> >E" <[email-masked]>, "Li, Han" <[email-masked]>,
> >[email-masked]
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> >I-Ds)
> >
> >
> >Dimitri,
> >          Removing state should be a simple process of deleting local
> >control plane state while not impacting the data plane
> >state.  Exporting, at least to me, implies a more complicated API or
> >other information transaction processing, which is certainly not needed
> >here.
> >
> >I think we're talking about a mechanism that should require a single
> >"preserve data plane" bit in a PathTear message.  Nothing more.
> >
> >Lou
> >
> >At 12:14 PM 8/25/2006, [email-masked] wrote:
> >
> > >lou - isn't "remove" or "export" having the same meaning in the 
present
> > >context ?
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >Sent by: [email-masked]
> > >25/08/2006 17:57
> > >
> > >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> > ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> > ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> > >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> > ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,
>John
> > >E" <[email-masked]>, "Li, Han" <[email-masked]>
> > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new 
WG
> > >I-Ds)
> > >
> > >
> > >Who said anything about exporting state?
> > >
> > >At 11:51 AM 8/25/2006, [email-masked] wrote:
> > >
> > > >lou - and why shall CCAMP provide a function to export states 
outside
> >of
> > > >its domain of competence
> > > >
> > > >thanks,
> > > >- d.
> > > >
> > > >
> > > >
> > > >
> > > >Lou Berger <[email-masked]>
> > > >25/08/2006 17:49
> > > >
> > > >         To:     "Don Fedyk" <[email-masked]>
> > > >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>,
>"Farrel,
> > > >Adrian" <[email-masked]>, "ccamp" <[email-masked]>,
>"Brungard,
> > > >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> > > ><[email-masked]>, "Drake, John E"
> ><[email-masked]>,
> > > >"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
> > > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new
>WG
> > > >I-Ds)
> > > >
> > > >
> > > >
> > > >Don,
> > > >
> > > >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > > > >I think there may be something here but I think even the
>requirements
> > >as
> > > > >stated assume too much of the solution. What is the real issue?
> > > >
> > > >Per my previous e-mail:
> > > >At 01:01 PM 8/24/2006, Lou Berger wrote:
> > > >
> > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > > > >>[...]
> > > > >>If we were to ask could you live without the CP->MP feature what
> > > > >>response would we get versus asking if CP->MP is a soft
>requirement.
> > > > >
> > > > > From the discussions I've had on this with carriers, for some 
it's
> > > > > a don't care, for others they won't deploy control plane without
> > > > > this capability.
> > > > >
> > > > >Lou
> > > >
> > > >AND
> > > >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > > > >[...]I therefore think the definition of CP->MP *is*
> > > > >required.  There are multiple options for meeting this 
requirement,
> > > > >but the solution must provide the "fallback" capability for
>services
> > > > >existing at the time of the initial MP->CP transition and those
> > > > >created after the transition.
> > > >[...]
> > > >
> > > >I think a capability to remove LSP state while leaving forward 
state
> > > >untouched will meet the requirements of those I've talked with.
> > > >
> > > >Lou
> > > >
> > > > >Regards,
> > > > >Don

Delivery-date: Fri, 25 Aug 2006 18:37:44 +0000
content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Fri, 25 Aug 2006 14:37:34 -0400
From: "Bryskin, Igor" <[email-masked]>
To: <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, <[email-masked]>

Dimitri,

We use D-bit for graceful shutdown. D-bit means prepare for delete. We =
do graceful shutdown normally. We need another bit for this exceptional =
release (without breaking cross-connects).

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:29 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

igor=20

but you don't need more than what's in RFC 3473 than disabling alarms=20
during the move of the resource associated to the CP to another enitity=20
and the send a pathtear to remove the control plane state (you don't =
need=20
to involve the CP in moving the data plane resource on each node)

-d.
=20

"Bryskin, Igor" <[email-masked]>
25/08/2006 20:02
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger"=20
<[email-masked]>
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp"=20
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, =

ALABS" <[email-masked]>, "Diego Caviglia" =
<[email-masked]>,=20
"Don Fedyk" <[email-masked]>, "Drake, John E"=20
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han"=20
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
I-Ds)

Dimitri,

graceful deletion bit set in admin_status you mentioned about is sent in =

Path and Modify messages and is meant for disabling alarms before you=20
starting LSP teardown.

What we are talking about is nothing but a bit in PathTear message=20
instructing resource manager on each node not to break cross-connects=20
while LSP resources are removed.

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 1:35 PM
To: Lou Berger
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

lou - i mean that in case an LSP for whatever reason needs to be moved=20
from the control plane to another place

this is already covered in RFC 3473 - the LSP is signaled with graceful=20
deletion bit set in admin_status, then on each node the resource is=20
associated to that entity (which is not a CP business) and then the=20
control plane state is removed

hope this clarifies,
-d.

Lou Berger <[email-masked]>
25/08/2006 19:25
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"=20
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"=20
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,=20
"Diego Caviglia" <[email-masked]>, "Don Fedyk"=20
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John =

E" <[email-masked]>, "Li, Han" <[email-masked]>,=20
[email-masked]
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
I-Ds)

Dimitri,
         I really don't understand your point.  Can you =
restate/rephrase?

Lou

At 01:03 PM 8/25/2006, [email-masked] wrote:

>lou
>
>resource are present (data plane state remains) the operation we're
>discussing about is local and consist in associating that resource to
>another entity - you GR the path because you don't want to generate=20
errors
>- but then that's it you just have to retrieve the CP state
>
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 18:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, =
John
>E" <[email-masked]>, "Li, Han" <[email-masked]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Dimitri,
>
>huh, why would there be no resources, i.e., data plane state,
>associated with the LSP?  If this were the case, I agree the whole
>discussion would be moot.
>
>Lou
>
>At 12:48 PM 8/25/2006, [email-masked] wrote:
>
> >lou,
> >
> >like i replied to igor
> >
> >"entity X wants to recuperate a CP state - just let it do - if so=20
allowed
> >
> >then send a PathTear since there is no resource anymore associate to=20
that
> >state (but this does not require any specific documentation)"
> >
> >we would deleting a path/resv state for which no resource are =
allocated=20

-
> >we did already that exercise - GR deletion.
> >
> >much thanks,
> >-d.
> >
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >Sent by: [email-masked]
> >25/08/2006 18:32
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,=20
John
> >E" <[email-masked]>, "Li, Han" <[email-masked]>,
> >[email-masked]
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new =
WG
> >I-Ds)
> >
> >
> >Dimitri,
> >          Removing state should be a simple process of deleting local
> >control plane state while not impacting the data plane
> >state.  Exporting, at least to me, implies a more complicated API or
> >other information transaction processing, which is certainly not =
needed
> >here.
> >
> >I think we're talking about a mechanism that should require a single
> >"preserve data plane" bit in a PathTear message.  Nothing more.
> >
> >Lou
> >
> >At 12:14 PM 8/25/2006, [email-masked] wrote:
> >
> > >lou - isn't "remove" or "export" having the same meaning in the=20
present
> > >context ?
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >Sent by: [email-masked]
> > >25/08/2006 17:57
> > >
> > >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> > ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> > ><[email-masked]>, "Brungard, Deborah A, ALABS" =
<[email-masked]>,
> > >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> > ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,
>John
> > >E" <[email-masked]>, "Li, Han" <[email-masked]>
> > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new =

WG
> > >I-Ds)
> > >
> > >
> > >Who said anything about exporting state?
> > >
> > >At 11:51 AM 8/25/2006, [email-masked] wrote:
> > >
> > > >lou - and why shall CCAMP provide a function to export states=20
outside
> >of
> > > >its domain of competence
> > > >
> > > >thanks,
> > > >- d.
> > > >
> > > >
> > > >
> > > >
> > > >Lou Berger <[email-masked]>
> > > >25/08/2006 17:49
> > > >
> > > >         To:     "Don Fedyk" <[email-masked]>
> > > >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>,
>"Farrel,
> > > >Adrian" <[email-masked]>, "ccamp" <[email-masked]>,
>"Brungard,
> > > >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> > > ><[email-masked]>, "Drake, John E"
> ><[email-masked]>,
> > > >"Lou Berger" <[email-masked]>, "Li, Han" =
<[email-masked]>
> > > >         Subject:        RE: CP-->MP Issue (was RE: Polling for =
new
>WG
> > > >I-Ds)
> > > >
> > > >
> > > >
> > > >Don,
> > > >
> > > >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > > > >I think there may be something here but I think even the
>requirements
> > >as
> > > > >stated assume too much of the solution. What is the real issue?
> > > >
> > > >Per my previous e-mail:
> > > >At 01:01 PM 8/24/2006, Lou Berger wrote:
> > > >
> > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > > > >>[...]
> > > > >>If we were to ask could you live without the CP->MP feature =
what
> > > > >>response would we get versus asking if CP->MP is a soft
>requirement.
> > > > >
> > > > > From the discussions I've had on this with carriers, for some=20
it's
> > > > > a don't care, for others they won't deploy control plane =
without
> > > > > this capability.
> > > > >
> > > > >Lou
> > > >
> > > >AND
> > > >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > > > >[...]I therefore think the definition of CP->MP *is*
> > > > >required.  There are multiple options for meeting this=20
requirement,
> > > > >but the solution must provide the "fallback" capability for
>services
> > > > >existing at the time of the initial MP->CP transition and those
> > > > >created after the transition.
> > > >[...]
> > > >
> > > >I think a capability to remove LSP state while leaving forward=20
state
> > > >untouched will meet the requirements of those I've talked with.
> > > >
> > > >Lou
> > > >
> > > > >Regards,
> > > > >Don

Delivery-date: Fri, 25 Aug 2006 18:30:30 +0000
To: "Bryskin, Igor" <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, [email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 20:29:11 +0200

igor 

but you don't need more than what's in RFC 3473 than disabling alarms 
during the move of the resource associated to the CP to another enitity 
and the send a pathtear to remove the control plane state (you don't need 
to involve the CP in moving the data plane resource on each node)

-d.

"Bryskin, Igor" <[email-masked]>
25/08/2006 20:02
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger" 
<[email-masked]>
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, 
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, 
"Don Fedyk" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" 
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,

graceful deletion bit set in admin_status you mentioned about is sent in 
Path and Modify messages and is meant for disabling alarms before you 
starting LSP teardown.

What we are talking about is nothing but a bit in PathTear message 
instructing resource manager on each node not to break cross-connects 
while LSP resources are removed.

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 1:35 PM
To: Lou Berger
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

lou - i mean that in case an LSP for whatever reason needs to be moved 
from the control plane to another place

this is already covered in RFC 3473 - the LSP is signaled with graceful 
deletion bit set in admin_status, then on each node the resource is 
associated to that entity (which is not a CP business) and then the 
control plane state is removed

hope this clarifies,
-d.

Lou Berger <[email-masked]>
25/08/2006 19:25
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <[email-masked]>, "Farrel, Adrian" 
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Diego Caviglia" <[email-masked]>, "Don Fedyk" 
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John 
E" <[email-masked]>, "Li, Han" <[email-masked]>, 
[email-masked]
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,
         I really don't understand your point.  Can you restate/rephrase?

Lou

At 01:03 PM 8/25/2006, [email-masked] wrote:

>lou
>
>resource are present (data plane state remains) the operation we're
>discussing about is local and consist in associating that resource to
>another entity - you GR the path because you don't want to generate 
errors
>- but then that's it you just have to retrieve the CP state
>
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 18:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Li, Han" <[email-masked]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Dimitri,
>
>huh, why would there be no resources, i.e., data plane state,
>associated with the LSP?  If this were the case, I agree the whole
>discussion would be moot.
>
>Lou
>
>At 12:48 PM 8/25/2006, [email-masked] wrote:
>
> >lou,
> >
> >like i replied to igor
> >
> >"entity X wants to recuperate a CP state - just let it do - if so 
allowed
> >
> >then send a PathTear since there is no resource anymore associate to 
that
> >state (but this does not require any specific documentation)"
> >
> >we would deleting a path/resv state for which no resource are allocated 

-
> >we did already that exercise - GR deletion.
> >
> >much thanks,
> >-d.
> >
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >Sent by: [email-masked]
> >25/08/2006 18:32
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, 
John
> >E" <[email-masked]>, "Li, Han" <[email-masked]>,
> >[email-masked]
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> >I-Ds)
> >
> >
> >Dimitri,
> >          Removing state should be a simple process of deleting local
> >control plane state while not impacting the data plane
> >state.  Exporting, at least to me, implies a more complicated API or
> >other information transaction processing, which is certainly not needed
> >here.
> >
> >I think we're talking about a mechanism that should require a single
> >"preserve data plane" bit in a PathTear message.  Nothing more.
> >
> >Lou
> >
> >At 12:14 PM 8/25/2006, [email-masked] wrote:
> >
> > >lou - isn't "remove" or "export" having the same meaning in the 
present
> > >context ?
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >Sent by: [email-masked]
> > >25/08/2006 17:57
> > >
> > >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> > ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> > ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> > >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> > ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,
>John
> > >E" <[email-masked]>, "Li, Han" <[email-masked]>
> > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new 
WG
> > >I-Ds)
> > >
> > >
> > >Who said anything about exporting state?
> > >
> > >At 11:51 AM 8/25/2006, [email-masked] wrote:
> > >
> > > >lou - and why shall CCAMP provide a function to export states 
outside
> >of
> > > >its domain of competence
> > > >
> > > >thanks,
> > > >- d.
> > > >
> > > >
> > > >
> > > >
> > > >Lou Berger <[email-masked]>
> > > >25/08/2006 17:49
> > > >
> > > >         To:     "Don Fedyk" <[email-masked]>
> > > >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>,
>"Farrel,
> > > >Adrian" <[email-masked]>, "ccamp" <[email-masked]>,
>"Brungard,
> > > >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> > > ><[email-masked]>, "Drake, John E"
> ><[email-masked]>,
> > > >"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
> > > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new
>WG
> > > >I-Ds)
> > > >
> > > >
> > > >
> > > >Don,
> > > >
> > > >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > > > >I think there may be something here but I think even the
>requirements
> > >as
> > > > >stated assume too much of the solution. What is the real issue?
> > > >
> > > >Per my previous e-mail:
> > > >At 01:01 PM 8/24/2006, Lou Berger wrote:
> > > >
> > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > > > >>[...]
> > > > >>If we were to ask could you live without the CP->MP feature what
> > > > >>response would we get versus asking if CP->MP is a soft
>requirement.
> > > > >
> > > > > From the discussions I've had on this with carriers, for some 
it's
> > > > > a don't care, for others they won't deploy control plane without
> > > > > this capability.
> > > > >
> > > > >Lou
> > > >
> > > >AND
> > > >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > > > >[...]I therefore think the definition of CP->MP *is*
> > > > >required.  There are multiple options for meeting this 
requirement,
> > > > >but the solution must provide the "fallback" capability for
>services
> > > > >existing at the time of the initial MP->CP transition and those
> > > > >created after the transition.
> > > >[...]
> > > >
> > > >I think a capability to remove LSP state while leaving forward 
state
> > > >untouched will meet the requirements of those I've talked with.
> > > >
> > > >Lou
> > > >
> > > > >Regards,
> > > > >Don

Delivery-date: Fri, 25 Aug 2006 18:03:38 +0000
content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Fri, 25 Aug 2006 14:02:59 -0400
From: "Bryskin, Igor" <[email-masked]>
To: <[email-masked]>, "Lou Berger" <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, <[email-masked]>

Dimitri,

graceful deletion bit set in admin_status you mentioned about is sent in =
Path and Modify messages and is meant for disabling alarms before you =
starting LSP teardown.

What we are talking about is nothing but a bit in PathTear message =
instructing resource manager on each node not to break cross-connects =
while LSP resources are removed.

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 1:35 PM
To: Lou Berger
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

lou - i mean that in case an LSP for whatever reason needs to be moved=20
from the control plane to another place

this is already covered in RFC 3473 - the LSP is signaled with graceful=20
deletion bit set in admin_status, then on each node the resource is=20
associated to that entity (which is not a CP business) and then the=20
control plane state is removed

hope this clarifies,
-d.

Lou Berger <[email-masked]>
25/08/2006 19:25
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"=20
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"=20
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,=20
"Diego Caviglia" <[email-masked]>, "Don Fedyk"=20
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John =

E" <[email-masked]>, "Li, Han" <[email-masked]>,=20
[email-masked]
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
I-Ds)

Dimitri,
         I really don't understand your point.  Can you =
restate/rephrase?

Lou

At 01:03 PM 8/25/2006, [email-masked] wrote:

>lou
>
>resource are present (data plane state remains) the operation we're
>discussing about is local and consist in associating that resource to
>another entity - you GR the path because you don't want to generate=20
errors
>- but then that's it you just have to retrieve the CP state
>
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 18:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, =
John
>E" <[email-masked]>, "Li, Han" <[email-masked]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Dimitri,
>
>huh, why would there be no resources, i.e., data plane state,
>associated with the LSP?  If this were the case, I agree the whole
>discussion would be moot.
>
>Lou
>
>At 12:48 PM 8/25/2006, [email-masked] wrote:
>
> >lou,
> >
> >like i replied to igor
> >
> >"entity X wants to recuperate a CP state - just let it do - if so=20
allowed
> >
> >then send a PathTear since there is no resource anymore associate to=20
that
> >state (but this does not require any specific documentation)"
> >
> >we would deleting a path/resv state for which no resource are =
allocated=20
-
> >we did already that exercise - GR deletion.
> >
> >much thanks,
> >-d.
> >
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >Sent by: [email-masked]
> >25/08/2006 18:32
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,=20
John
> >E" <[email-masked]>, "Li, Han" <[email-masked]>,
> >[email-masked]
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new =
WG
> >I-Ds)
> >
> >
> >Dimitri,
> >          Removing state should be a simple process of deleting local
> >control plane state while not impacting the data plane
> >state.  Exporting, at least to me, implies a more complicated API or
> >other information transaction processing, which is certainly not =
needed
> >here.
> >
> >I think we're talking about a mechanism that should require a single
> >"preserve data plane" bit in a PathTear message.  Nothing more.
> >
> >Lou
> >
> >At 12:14 PM 8/25/2006, [email-masked] wrote:
> >
> > >lou - isn't "remove" or "export" having the same meaning in the=20
present
> > >context ?
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >Sent by: [email-masked]
> > >25/08/2006 17:57
> > >
> > >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> > ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> > ><[email-masked]>, "Brungard, Deborah A, ALABS" =
<[email-masked]>,
> > >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> > ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,
>John
> > >E" <[email-masked]>, "Li, Han" <[email-masked]>
> > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new =

WG
> > >I-Ds)
> > >
> > >
> > >Who said anything about exporting state?
> > >
> > >At 11:51 AM 8/25/2006, [email-masked] wrote:
> > >
> > > >lou - and why shall CCAMP provide a function to export states=20
outside
> >of
> > > >its domain of competence
> > > >
> > > >thanks,
> > > >- d.
> > > >
> > > >
> > > >
> > > >
> > > >Lou Berger <[email-masked]>
> > > >25/08/2006 17:49
> > > >
> > > >         To:     "Don Fedyk" <[email-masked]>
> > > >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>,
>"Farrel,
> > > >Adrian" <[email-masked]>, "ccamp" <[email-masked]>,
>"Brungard,
> > > >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> > > ><[email-masked]>, "Drake, John E"
> ><[email-masked]>,
> > > >"Lou Berger" <[email-masked]>, "Li, Han" =
<[email-masked]>
> > > >         Subject:        RE: CP-->MP Issue (was RE: Polling for =
new
>WG
> > > >I-Ds)
> > > >
> > > >
> > > >
> > > >Don,
> > > >
> > > >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > > > >I think there may be something here but I think even the
>requirements
> > >as
> > > > >stated assume too much of the solution. What is the real issue?
> > > >
> > > >Per my previous e-mail:
> > > >At 01:01 PM 8/24/2006, Lou Berger wrote:
> > > >
> > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > > > >>[...]
> > > > >>If we were to ask could you live without the CP->MP feature =
what
> > > > >>response would we get versus asking if CP->MP is a soft
>requirement.
> > > > >
> > > > > From the discussions I've had on this with carriers, for some=20
it's
> > > > > a don't care, for others they won't deploy control plane =
without
> > > > > this capability.
> > > > >
> > > > >Lou
> > > >
> > > >AND
> > > >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > > > >[...]I therefore think the definition of CP->MP *is*
> > > > >required.  There are multiple options for meeting this=20
requirement,
> > > > >but the solution must provide the "fallback" capability for
>services
> > > > >existing at the time of the initial MP->CP transition and those
> > > > >created after the transition.
> > > >[...]
> > > >
> > > >I think a capability to remove LSP state while leaving forward=20
state
> > > >untouched will meet the requirements of those I've talked with.
> > > >
> > > >Lou
> > > >
> > > > >Regards,
> > > > >Don

Delivery-date: Fri, 25 Aug 2006 17:54:17 +0000
Content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Fri, 25 Aug 2006 13:53:48 -0400
From: "Zafar Ali \(zali\)" <[email-masked]>
To: <[email-masked]>, "Bryskin, Igor" <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Friday, August 25, 2006 1:01 PM
> To: Bryskin, Igor
> Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A,=20
> ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger;=20
> Li, Han; [email-masked]
> Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
>=20
> i totally disagree you constantly referring to the MP while=20
> CCAMP has NEVER linked control operations to MP operations -=20
> these MP operations assumptions are outside scope of CCAMP=20
>=20

I agree with Dimitri. Also Don mentioned a good point that there is no
standard MP. I am not sure why we should pursue this any further.=20

Thanks

Regards.. Zafar=20

> in part. we are going to enter into a discussion for which we=20
> won't get the bird out of the bush: addressing space between=20
> CP and MP it took us more or less 4 years to disambiguate the=20
> DP address space relationship with the CP and there is no=20
> reason to start an endless debate now with the MP
>=20
> -d.
>=20
> =20
>=20
>=20
>=20
>=20
>=20
> "Bryskin, Igor" <[email-masked]>
> Sent by: [email-masked]
> 25/08/2006 18:39
> =20
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     "Farrel, Adrian" <[email-masked]>, "ccamp"=20
> <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard,=20
> Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"=20
> <[email-masked]>, "Don Fedyk"=20
> <[email-masked]>, "Drake, John E"=20
> <[email-masked]>, "Lou Berger" <[email-masked]>,=20
> "Li, Han"=20
> <[email-masked]>, <[email-masked]>
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
> I-Ds)
>=20
>=20
>=20
> Approximate scenarios:
>=20
> a) MP->CP scenario:
>=20
> MP provides CP with complete ERO (including labels) CP=20
> signals SETUP with an IN-PLACE attribute, this causes=20
> provisioning operations on each node without re-programming=20
> cross-connects MP releases resource ownership after the=20
> operation by some means
>=20
> b) CP->MP scenario:
>=20
> MP receives from CP complete RRO (including labels) MP=20
> assumes resource ownership operation by some means CP signals=20
> TEARDOWN with an IN-PLACE attribute, this causes release by=20
> CP resources on each node without re-programming cross-connects
>=20
> Igor
>=20
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, August 25, 2006 12:18 PM
> To: Bryskin, Igor
> Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A,=20
> ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger;=20
> Li, Han; [email-masked]
> Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
>=20
>=20
> you are asking for something outside the scope of ccamp
>=20
> entity X wants to recuperate a CP state - just let it do - if=20
> so allowed
>=20
> then send a PathTear since there is no resource anymore=20
> associate to that state (but this does not require any=20
> specific documentation)
>=20
> -d.
>=20
>=20
>=20
>=20
>=20
> "Bryskin, Igor" <[email-masked]>
> Sent by: [email-masked]
> 25/08/2006 18:06
> =20
>         To:     "Lou Berger" <[email-masked]>, Dimitri=20
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     "Farrel, Adrian" <[email-masked]>, "ccamp"=20
> <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard,=20
> Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"=20
> <[email-masked]>,=20
>=20
> "Don Fedyk" <[email-masked]>, "Drake, John E"=20
> <[email-masked]>, "Li, Han" <[email-masked]>
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
> I-Ds)
>=20
>=20
> Agree with Lou.
>=20
> Can I also quote my own email? :=3D)
>=20
> "We are
> talking here about a capability of CP to acquire network=20
> resources and build CP state for an LSP without actually=20
> re-programming crossconnects (case MP->CP). Likewise, we are=20
> talking about capability of CP to release resources and=20
> destroy CP state for an LSP without re-programming=20
> crossconnects (case CP->MP). It is out of scope of those=20
> mechanisms how MP (or any other plane) assumes or yields the=20
> ownership of resources of the LSP whose ownership is=20
> transferred from/to CP."
>=20
> So I think we are talking about two relatively simple and=20
> very symmetrical=20
>=20
> CP functions.
>=20
> Igor
>=20
> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Friday, August 25, 2006 11:57 AM
> To: [email-masked]
> Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard,=20
> Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor;=20
> Drake, John E; Li, Han
> Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
>=20
>=20
> Who said anything about exporting state?
>=20
> At 11:51 AM 8/25/2006, [email-masked] wrote:
>=20
> >lou - and why shall CCAMP provide a function to export=20
> states outside=20
> >of its domain of competence
> >
> >thanks,
> >- d.
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >25/08/2006 17:49
> >
> >         To:     "Don Fedyk" <[email-masked]>
> >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li"=20
> <[email-masked]>, "Farrel,=20
> >Adrian" <[email-masked]>, "ccamp" <[email-masked]>,=20
> "Brungard,=20
> >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> ><[email-masked]>, "Drake, John E"=20
> ><[email-masked]>, "Lou Berger" <[email-masked]>,=20
> "Li, Han" <[email-masked]>
> >         Subject:        RE: CP-->MP Issue (was RE: Polling=20
> for new WG
> >I-Ds)
> >
> >
> >
> >Don,
> >
> >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > >I think there may be something here but I think even the=20
> requirements
> as
> > >stated assume too much of the solution. What is the real issue?
> >
> >Per my previous e-mail:
> >At 01:01 PM 8/24/2006, Lou Berger wrote:
> >
> > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > >>[...]
> > >>If we were to ask could you live without the CP->MP feature what=20
> > >>response would we get versus asking if CP->MP is a soft=20
> requirement.
> > >
> > > From the discussions I've had on this with carriers, for=20
> some it's a=20
> > > don't care, for others they won't deploy control plane=20
> without this=20
> > > capability.
> > >
> > >Lou
> >
> >AND
> >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > >[...]I therefore think the definition of CP->MP *is*=20
> required.  There=20
> > >are multiple options for meeting this requirement, but the=20
> solution=20
> > >must provide the "fallback" capability for services=20
> existing at the=20
> > >time of the initial MP->CP transition and those created after the=20
> > >transition.
> >[...]
> >
> >I think a capability to remove LSP state while leaving forward state=20
> >untouched will meet the requirements of those I've talked with.
> >
> >Lou
> >
> > >Regards,
> > >Don
>=20
>=20
>=20
>=20
>=20
>=20
>=20

Delivery-date: Fri, 25 Aug 2006 17:48:22 +0000
To: "Ong, Lyndon" <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, [email-masked]
Subject: RE: CP-->MP Issue - non-issue
From: [email-masked]
Date: Fri, 25 Aug 2006 19:47:15 +0200

i agree on this CCAMP has/is building a self-consistent set of mechanisms 
(from the start CCAMP considered that the MP has not being fallback 
whatsover of the CP operations and in particular not linking any of its 
operations to a particular MP) 

all what i am hearing from igor and co. is just penalizing the work of 
this group achieved since 6 years without technical justification *** 
there is no need for MP intervention in order to obtain CP operations 
resiliency/reliability *** second time we have such discussion (look back 
on the archive around end-october 2005, nov.2005 you will see there that 
the same people already pushed forward the idea of unreliable control 
plane operations - if someone's implementation is unstable/unreliable it 
is not up to CCAMP to solve such issue and certainly not by interfering 
with the MP)

ps: add also add CP GR restart (from intermediate and source node) 

-d.

"Ong, Lyndon" <[email-masked]>
25/08/2006 19:22
 
        To:     "Brungard, Deborah A, ALABS" <[email-masked]>, "Farrel, 
Adrian" <[email-masked]>
        cc:     "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, 
"Diego Caviglia" <[email-masked]>, "Don Fedyk" 
<[email-masked]>, "Drake, John E" <[email-masked]>, "Lou 
Berger" <[email-masked]>, "Li, Han" <[email-masked]>, 
<[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, 
"Bryskin, Igor" <[email-masked]>
        Subject:        RE: CP-->MP Issue - non-issue

Hi Folks,

Just a bit worried that this discussion may be causing the impression
that
control plane is somehow unstable and requires some kind of special
backup!

Deborah and other carrier representatives can attest that control plane
(although not necessarily standard GMPLS) has been deployed and in
operation
in a number of carrier networks for some years without experiencing any
major failures.  There are already methods in use for ensuring the
reliability
of the control plane such as redundant control processors, non-volatile 
storage of control plane data, software verification and testing, etc.

I don't believe it was the intention of GMPLS work to require some kind
of
fallback to central management system control, hopefully everyone agrees
on this!

Cheers,

Lyndon

Delivery-date: Fri, 25 Aug 2006 17:40:54 +0000
To: Lou Berger <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, Lou Berger <[email-masked]>, "Li, Han" <[email-masked]>, [email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 19:34:43 +0200

lou - i mean that in case an LSP for whatever reason needs to be moved 
from the control plane to another place

this is already covered in RFC 3473 - the LSP is signaled with graceful 
deletion bit set in admin_status, then on each node the resource is 
associated to that entity (which is not a CP business) and then the 
control plane state is removed

hope this clarifies,
-d.

Lou Berger <[email-masked]>
25/08/2006 19:25
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <[email-masked]>, "Farrel, Adrian" 
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Diego Caviglia" <[email-masked]>, "Don Fedyk" 
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John 
E" <[email-masked]>, "Li, Han" <[email-masked]>, 
[email-masked]
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,
         I really don't understand your point.  Can you restate/rephrase?

Lou

At 01:03 PM 8/25/2006, [email-masked] wrote:

>lou
>
>resource are present (data plane state remains) the operation we're
>discussing about is local and consist in associating that resource to
>another entity - you GR the path because you don't want to generate 
errors
>- but then that's it you just have to retrieve the CP state
>
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 18:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Li, Han" <[email-masked]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Dimitri,
>
>huh, why would there be no resources, i.e., data plane state,
>associated with the LSP?  If this were the case, I agree the whole
>discussion would be moot.
>
>Lou
>
>At 12:48 PM 8/25/2006, [email-masked] wrote:
>
> >lou,
> >
> >like i replied to igor
> >
> >"entity X wants to recuperate a CP state - just let it do - if so 
allowed
> >
> >then send a PathTear since there is no resource anymore associate to 
that
> >state (but this does not require any specific documentation)"
> >
> >we would deleting a path/resv state for which no resource are allocated 
-
> >we did already that exercise - GR deletion.
> >
> >much thanks,
> >-d.
> >
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >Sent by: [email-masked]
> >25/08/2006 18:32
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, 
John
> >E" <[email-masked]>, "Li, Han" <[email-masked]>,
> >[email-masked]
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> >I-Ds)
> >
> >
> >Dimitri,
> >          Removing state should be a simple process of deleting local
> >control plane state while not impacting the data plane
> >state.  Exporting, at least to me, implies a more complicated API or
> >other information transaction processing, which is certainly not needed
> >here.
> >
> >I think we're talking about a mechanism that should require a single
> >"preserve data plane" bit in a PathTear message.  Nothing more.
> >
> >Lou
> >
> >At 12:14 PM 8/25/2006, [email-masked] wrote:
> >
> > >lou - isn't "remove" or "export" having the same meaning in the 
present
> > >context ?
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >Sent by: [email-masked]
> > >25/08/2006 17:57
> > >
> > >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> > ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> > ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> > >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> > ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,
>John
> > >E" <[email-masked]>, "Li, Han" <[email-masked]>
> > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new 
WG
> > >I-Ds)
> > >
> > >
> > >Who said anything about exporting state?
> > >
> > >At 11:51 AM 8/25/2006, [email-masked] wrote:
> > >
> > > >lou - and why shall CCAMP provide a function to export states 
outside
> >of
> > > >its domain of competence
> > > >
> > > >thanks,
> > > >- d.
> > > >
> > > >
> > > >
> > > >
> > > >Lou Berger <[email-masked]>
> > > >25/08/2006 17:49
> > > >
> > > >         To:     "Don Fedyk" <[email-masked]>
> > > >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>,
>"Farrel,
> > > >Adrian" <[email-masked]>, "ccamp" <[email-masked]>,
>"Brungard,
> > > >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> > > ><[email-masked]>, "Drake, John E"
> ><[email-masked]>,
> > > >"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
> > > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new
>WG
> > > >I-Ds)
> > > >
> > > >
> > > >
> > > >Don,
> > > >
> > > >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > > > >I think there may be something here but I think even the
>requirements
> > >as
> > > > >stated assume too much of the solution. What is the real issue?
> > > >
> > > >Per my previous e-mail:
> > > >At 01:01 PM 8/24/2006, Lou Berger wrote:
> > > >
> > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > > > >>[...]
> > > > >>If we were to ask could you live without the CP->MP feature what
> > > > >>response would we get versus asking if CP->MP is a soft
>requirement.
> > > > >
> > > > > From the discussions I've had on this with carriers, for some 
it's
> > > > > a don't care, for others they won't deploy control plane without
> > > > > this capability.
> > > > >
> > > > >Lou
> > > >
> > > >AND
> > > >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > > > >[...]I therefore think the definition of CP->MP *is*
> > > > >required.  There are multiple options for meeting this 
requirement,
> > > > >but the solution must provide the "fallback" capability for
>services
> > > > >existing at the time of the initial MP->CP transition and those
> > > > >created after the transition.
> > > >[...]
> > > >
> > > >I think a capability to remove LSP state while leaving forward 
state
> > > >untouched will meet the requirements of those I've talked with.
> > > >
> > > >Lou
> > > >
> > > > >Regards,
> > > > >Don

Delivery-date: Fri, 25 Aug 2006 17:26:24 +0000
Date: Fri, 25 Aug 2006 13:25:41 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Cc: Lou Berger <[email-masked]>,"Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>,"Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>,"Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, "Li, Han" <[email-masked]>,[email-masked]

Dimitri,
         I really don't understand your point.  Can you restate/rephrase?

Lou

At 01:03 PM 8/25/2006, [email-masked] wrote:

>lou
>
>resource are present (data plane state remains) the operation we're
>discussing about is local and consist in associating that resource to
>another entity - you GR the path because you don't want to generate errors
>- but then that's it you just have to retrieve the CP state
>
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 18:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Li, Han" <[email-masked]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Dimitri,
>
>huh, why would there be no resources, i.e., data plane state,
>associated with the LSP?  If this were the case, I agree the whole
>discussion would be moot.
>
>Lou
>
>At 12:48 PM 8/25/2006, [email-masked] wrote:
>
> >lou,
> >
> >like i replied to igor
> >
> >"entity X wants to recuperate a CP state - just let it do - if so allowed
> >
> >then send a PathTear since there is no resource anymore associate to that
> >state (but this does not require any specific documentation)"
> >
> >we would deleting a path/resv state for which no resource are allocated -
> >we did already that exercise - GR deletion.
> >
> >much thanks,
> >-d.
> >
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >Sent by: [email-masked]
> >25/08/2006 18:32
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
> >E" <[email-masked]>, "Li, Han" <[email-masked]>,
> >[email-masked]
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> >I-Ds)
> >
> >
> >Dimitri,
> >          Removing state should be a simple process of deleting local
> >control plane state while not impacting the data plane
> >state.  Exporting, at least to me, implies a more complicated API or
> >other information transaction processing, which is certainly not needed
> >here.
> >
> >I think we're talking about a mechanism that should require a single
> >"preserve data plane" bit in a PathTear message.  Nothing more.
> >
> >Lou
> >
> >At 12:14 PM 8/25/2006, [email-masked] wrote:
> >
> > >lou - isn't "remove" or "export" having the same meaning in the present
> > >context ?
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >Sent by: [email-masked]
> > >25/08/2006 17:57
> > >
> > >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> > ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> > ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> > >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> > ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake,
>John
> > >E" <[email-masked]>, "Li, Han" <[email-masked]>
> > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> > >I-Ds)
> > >
> > >
> > >Who said anything about exporting state?
> > >
> > >At 11:51 AM 8/25/2006, [email-masked] wrote:
> > >
> > > >lou - and why shall CCAMP provide a function to export states outside
> >of
> > > >its domain of competence
> > > >
> > > >thanks,
> > > >- d.
> > > >
> > > >
> > > >
> > > >
> > > >Lou Berger <[email-masked]>
> > > >25/08/2006 17:49
> > > >
> > > >         To:     "Don Fedyk" <[email-masked]>
> > > >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>,
>"Farrel,
> > > >Adrian" <[email-masked]>, "ccamp" <[email-masked]>,
>"Brungard,
> > > >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> > > ><[email-masked]>, "Drake, John E"
> ><[email-masked]>,
> > > >"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
> > > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new
>WG
> > > >I-Ds)
> > > >
> > > >
> > > >
> > > >Don,
> > > >
> > > >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > > > >I think there may be something here but I think even the
>requirements
> > >as
> > > > >stated assume too much of the solution. What is the real issue?
> > > >
> > > >Per my previous e-mail:
> > > >At 01:01 PM 8/24/2006, Lou Berger wrote:
> > > >
> > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > > > >>[...]
> > > > >>If we were to ask could you live without the CP->MP feature what
> > > > >>response would we get versus asking if CP->MP is a soft
>requirement.
> > > > >
> > > > > From the discussions I've had on this with carriers, for some it's
> > > > > a don't care, for others they won't deploy control plane without
> > > > > this capability.
> > > > >
> > > > >Lou
> > > >
> > > >AND
> > > >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > > > >[...]I therefore think the definition of CP->MP *is*
> > > > >required.  There are multiple options for meeting this requirement,
> > > > >but the solution must provide the "fallback" capability for
>services
> > > > >existing at the time of the initial MP->CP transition and those
> > > > >created after the transition.
> > > >[...]
> > > >
> > > >I think a capability to remove LSP state while leaving forward state
> > > >untouched will meet the requirements of those I've talked with.
> > > >
> > > >Lou
> > > >
> > > > >Regards,
> > > > >Don

Delivery-date: Fri, 25 Aug 2006 17:04:27 +0000
To: Lou Berger <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, Lou Berger <[email-masked]>, "Li, Han" <[email-masked]>, [email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 19:03:32 +0200

lou 

resource are present (data plane state remains) the operation we're 
discussing about is local and consist in associating that resource to 
another entity - you GR the path because you don't want to generate errors 
- but then that's it you just have to retrieve the CP state

- d.

Lou Berger <[email-masked]>
25/08/2006 18:57
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <[email-masked]>, "Farrel, Adrian" 
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Diego Caviglia" <[email-masked]>, "Don Fedyk" 
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John 
E" <[email-masked]>, "Li, Han" <[email-masked]>, 
[email-masked]
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,

huh, why would there be no resources, i.e., data plane state, 
associated with the LSP?  If this were the case, I agree the whole 
discussion would be moot.

Lou

At 12:48 PM 8/25/2006, [email-masked] wrote:

>lou,
>
>like i replied to igor
>
>"entity X wants to recuperate a CP state - just let it do - if so allowed
>
>then send a PathTear since there is no resource anymore associate to that
>state (but this does not require any specific documentation)"
>
>we would deleting a path/resv state for which no resource are allocated -
>we did already that exercise - GR deletion.
>
>much thanks,
>-d.
>
>
>
>
>
>Lou Berger <[email-masked]>
>Sent by: [email-masked]
>25/08/2006 18:32
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Li, Han" <[email-masked]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Dimitri,
>          Removing state should be a simple process of deleting local
>control plane state while not impacting the data plane
>state.  Exporting, at least to me, implies a more complicated API or
>other information transaction processing, which is certainly not needed
>here.
>
>I think we're talking about a mechanism that should require a single
>"preserve data plane" bit in a PathTear message.  Nothing more.
>
>Lou
>
>At 12:14 PM 8/25/2006, [email-masked] wrote:
>
> >lou - isn't "remove" or "export" having the same meaning in the present
> >context ?
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >Sent by: [email-masked]
> >25/08/2006 17:57
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, 
John
> >E" <[email-masked]>, "Li, Han" <[email-masked]>
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> >I-Ds)
> >
> >
> >Who said anything about exporting state?
> >
> >At 11:51 AM 8/25/2006, [email-masked] wrote:
> >
> > >lou - and why shall CCAMP provide a function to export states outside
>of
> > >its domain of competence
> > >
> > >thanks,
> > >- d.
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >25/08/2006 17:49
> > >
> > >         To:     "Don Fedyk" <[email-masked]>
> > >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, 
"Farrel,
> > >Adrian" <[email-masked]>, "ccamp" <[email-masked]>, 
"Brungard,
> > >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> > ><[email-masked]>, "Drake, John E"
><[email-masked]>,
> > >"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
> > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new 
WG
> > >I-Ds)
> > >
> > >
> > >
> > >Don,
> > >
> > >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > > >I think there may be something here but I think even the 
requirements
> >as
> > > >stated assume too much of the solution. What is the real issue?
> > >
> > >Per my previous e-mail:
> > >At 01:01 PM 8/24/2006, Lou Berger wrote:
> > >
> > > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > > >>[...]
> > > >>If we were to ask could you live without the CP->MP feature what
> > > >>response would we get versus asking if CP->MP is a soft 
requirement.
> > > >
> > > > From the discussions I've had on this with carriers, for some it's
> > > > a don't care, for others they won't deploy control plane without
> > > > this capability.
> > > >
> > > >Lou
> > >
> > >AND
> > >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > > >[...]I therefore think the definition of CP->MP *is*
> > > >required.  There are multiple options for meeting this requirement,
> > > >but the solution must provide the "fallback" capability for 
services
> > > >existing at the time of the initial MP->CP transition and those
> > > >created after the transition.
> > >[...]
> > >
> > >I think a capability to remove LSP state while leaving forward state
> > >untouched will meet the requirements of those I've talked with.
> > >
> > >Lou
> > >
> > > >Regards,
> > > >Don

Delivery-date: Fri, 25 Aug 2006 17:02:07 +0000
To: "Bryskin, Igor" <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, [email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 19:01:14 +0200

i totally disagree you constantly referring to the MP while CCAMP has 
NEVER linked control operations to MP operations - these MP operations 
assumptions are outside scope of CCAMP 

in part. we are going to enter into a discussion for which we won't get 
the bird out of the bush: addressing space between CP and MP
it took us more or less 4 years to disambiguate the DP address space 
relationship with the CP and there is no reason to start an endless debate 
now with the MP

-d.

"Bryskin, Igor" <[email-masked]>
Sent by: [email-masked]
25/08/2006 18:39
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, 
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, 
"Don Fedyk" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" 
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Approximate scenarios:

a) MP->CP scenario:

MP provides CP with complete ERO (including labels)
CP signals SETUP with an IN-PLACE attribute, this causes provisioning 
operations on each node without re-programming cross-connects
MP releases resource ownership after the operation by some means

b) CP->MP scenario:

MP receives from CP complete RRO (including labels)
MP assumes resource ownership operation by some means
CP signals TEARDOWN with an IN-PLACE attribute, this causes release by CP 
resources on each node without re-programming cross-connects

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 12:18 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

you are asking for something outside the scope of ccamp

entity X wants to recuperate a CP state - just let it do - if so allowed

then send a PathTear since there is no resource anymore associate to that 
state (but this does not require any specific documentation)

-d.

"Bryskin, Igor" <[email-masked]>
Sent by: [email-masked]
25/08/2006 18:06
 
        To:     "Lou Berger" <[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, 
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, 

"Don Fedyk" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Li, Han" <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Agree with Lou.

Can I also quote my own email? :=)

"We are
talking here about a capability of CP to acquire network resources and
build CP state for an LSP without actually re-programming crossconnects
(case MP->CP). Likewise, we are talking about capability of CP to release
resources and destroy CP state for an LSP without re-programming
crossconnects (case CP->MP). It is out of scope of those mechanisms how MP
(or any other plane) assumes or yields the ownership of resources of the
LSP whose ownership is transferred from/to CP."

So I think we are talking about two relatively simple and very symmetrical 

CP functions.

Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Friday, August 25, 2006 11:57 AM
To: [email-masked]
Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A,
ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

Who said anything about exporting state?

At 11:51 AM 8/25/2006, [email-masked] wrote:

>lou - and why shall CCAMP provide a function to export states outside of
>its domain of competence
>
>thanks,
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 17:49
>
>         To:     "Don Fedyk" <[email-masked]>
>         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel,
>Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard,
>Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
><[email-masked]>, "Drake, John E" <[email-masked]>,
>"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>
>Don,
>
>At 10:40 AM 8/25/2006, Don Fedyk wrote:
> >I think there may be something here but I think even the requirements 
as
> >stated assume too much of the solution. What is the real issue?
>
>Per my previous e-mail:
>At 01:01 PM 8/24/2006, Lou Berger wrote:
>
> >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> >>[...]
> >>If we were to ask could you live without the CP->MP feature what
> >>response would we get versus asking if CP->MP is a soft requirement.
> >
> > From the discussions I've had on this with carriers, for some it's
> > a don't care, for others they won't deploy control plane without
> > this capability.
> >
> >Lou
>
>AND
>At 08:15 AM 8/24/2006, Lou Berger wrote:
> >[...]I therefore think the definition of CP->MP *is*
> >required.  There are multiple options for meeting this requirement,
> >but the solution must provide the "fallback" capability for services
> >existing at the time of the initial MP->CP transition and those
> >created after the transition.
>[...]
>
>I think a capability to remove LSP state while leaving forward state
>untouched will meet the requirements of those I've talked with.
>
>Lou
>
> >Regards,
> >Don

Delivery-date: Fri, 25 Aug 2006 16:58:02 +0000
Date: Fri, 25 Aug 2006 12:57:23 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Cc: Lou Berger <[email-masked]>,"Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>,"Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>,"Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, "Li, Han" <[email-masked]>,[email-masked]

Dimitri,

huh, why would there be no resources, i.e., data plane state, 
associated with the LSP?  If this were the case, I agree the whole 
discussion would be moot.

Lou

At 12:48 PM 8/25/2006, [email-masked] wrote:

>lou,
>
>like i replied to igor
>
>"entity X wants to recuperate a CP state - just let it do - if so allowed
>
>then send a PathTear since there is no resource anymore associate to that
>state (but this does not require any specific documentation)"
>
>we would deleting a path/resv state for which no resource are allocated -
>we did already that exercise - GR deletion.
>
>much thanks,
>-d.
>
>
>
>
>
>Lou Berger <[email-masked]>
>Sent by: [email-masked]
>25/08/2006 18:32
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Li, Han" <[email-masked]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Dimitri,
>          Removing state should be a simple process of deleting local
>control plane state while not impacting the data plane
>state.  Exporting, at least to me, implies a more complicated API or
>other information transaction processing, which is certainly not needed
>here.
>
>I think we're talking about a mechanism that should require a single
>"preserve data plane" bit in a PathTear message.  Nothing more.
>
>Lou
>
>At 12:14 PM 8/25/2006, [email-masked] wrote:
>
> >lou - isn't "remove" or "export" having the same meaning in the present
> >context ?
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >Sent by: [email-masked]
> >25/08/2006 17:57
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
> ><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
> ><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
> >"Diego Caviglia" <[email-masked]>, "Don Fedyk"
> ><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
> >E" <[email-masked]>, "Li, Han" <[email-masked]>
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> >I-Ds)
> >
> >
> >Who said anything about exporting state?
> >
> >At 11:51 AM 8/25/2006, [email-masked] wrote:
> >
> > >lou - and why shall CCAMP provide a function to export states outside
>of
> > >its domain of competence
> > >
> > >thanks,
> > >- d.
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >25/08/2006 17:49
> > >
> > >         To:     "Don Fedyk" <[email-masked]>
> > >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel,
> > >Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard,
> > >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> > ><[email-masked]>, "Drake, John E"
><[email-masked]>,
> > >"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
> > >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> > >I-Ds)
> > >
> > >
> > >
> > >Don,
> > >
> > >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > > >I think there may be something here but I think even the requirements
> >as
> > > >stated assume too much of the solution. What is the real issue?
> > >
> > >Per my previous e-mail:
> > >At 01:01 PM 8/24/2006, Lou Berger wrote:
> > >
> > > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > > >>[...]
> > > >>If we were to ask could you live without the CP->MP feature what
> > > >>response would we get versus asking if CP->MP is a soft requirement.
> > > >
> > > > From the discussions I've had on this with carriers, for some it's
> > > > a don't care, for others they won't deploy control plane without
> > > > this capability.
> > > >
> > > >Lou
> > >
> > >AND
> > >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > > >[...]I therefore think the definition of CP->MP *is*
> > > >required.  There are multiple options for meeting this requirement,
> > > >but the solution must provide the "fallback" capability for services
> > > >existing at the time of the initial MP->CP transition and those
> > > >created after the transition.
> > >[...]
> > >
> > >I think a capability to remove LSP state while leaving forward state
> > >untouched will meet the requirements of those I've talked with.
> > >
> > >Lou
> > >
> > > >Regards,
> > > >Don

Delivery-date: Fri, 25 Aug 2006 16:49:57 +0000
To: Lou Berger <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, Lou Berger <[email-masked]>, "Li, Han" <[email-masked]>, [email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 18:48:47 +0200

lou,

like i replied to igor

"entity X wants to recuperate a CP state - just let it do - if so allowed

then send a PathTear since there is no resource anymore associate to that 
state (but this does not require any specific documentation)"

we would deleting a path/resv state for which no resource are allocated - 
we did already that exercise - GR deletion.

much thanks,
-d.

Lou Berger <[email-masked]>
Sent by: [email-masked]
25/08/2006 18:32
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <[email-masked]>, "Farrel, Adrian" 
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Diego Caviglia" <[email-masked]>, "Don Fedyk" 
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John 
E" <[email-masked]>, "Li, Han" <[email-masked]>, 
[email-masked]
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,
         Removing state should be a simple process of deleting local 
control plane state while not impacting the data plane 
state.  Exporting, at least to me, implies a more complicated API or 
other information transaction processing, which is certainly not needed 
here.

I think we're talking about a mechanism that should require a single 
"preserve data plane" bit in a PathTear message.  Nothing more.

Lou

At 12:14 PM 8/25/2006, [email-masked] wrote:

>lou - isn't "remove" or "export" having the same meaning in the present
>context ?
>
>
>
>
>Lou Berger <[email-masked]>
>Sent by: [email-masked]
>25/08/2006 17:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Li, Han" <[email-masked]>
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Who said anything about exporting state?
>
>At 11:51 AM 8/25/2006, [email-masked] wrote:
>
> >lou - and why shall CCAMP provide a function to export states outside 
of
> >its domain of competence
> >
> >thanks,
> >- d.
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >25/08/2006 17:49
> >
> >         To:     "Don Fedyk" <[email-masked]>
> >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel,
> >Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard,
> >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> ><[email-masked]>, "Drake, John E" 
<[email-masked]>,
> >"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> >I-Ds)
> >
> >
> >
> >Don,
> >
> >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > >I think there may be something here but I think even the requirements
>as
> > >stated assume too much of the solution. What is the real issue?
> >
> >Per my previous e-mail:
> >At 01:01 PM 8/24/2006, Lou Berger wrote:
> >
> > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > >>[...]
> > >>If we were to ask could you live without the CP->MP feature what
> > >>response would we get versus asking if CP->MP is a soft requirement.
> > >
> > > From the discussions I've had on this with carriers, for some it's
> > > a don't care, for others they won't deploy control plane without
> > > this capability.
> > >
> > >Lou
> >
> >AND
> >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > >[...]I therefore think the definition of CP->MP *is*
> > >required.  There are multiple options for meeting this requirement,
> > >but the solution must provide the "fallback" capability for services
> > >existing at the time of the initial MP->CP transition and those
> > >created after the transition.
> >[...]
> >
> >I think a capability to remove LSP state while leaving forward state
> >untouched will meet the requirements of those I've talked with.
> >
> >Lou
> >
> > >Regards,
> > >Don

Delivery-date: Fri, 25 Aug 2006 16:40:00 +0000
content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Fri, 25 Aug 2006 12:39:44 -0400
From: "Bryskin, Igor" <[email-masked]>
To: <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, <[email-masked]>

Approximate scenarios:

a) MP->CP scenario:

MP provides CP with complete ERO (including labels)
CP signals SETUP with an IN-PLACE attribute, this causes provisioning =
operations on each node without re-programming cross-connects
MP releases resource ownership after the operation by some means

b) CP->MP scenario:

MP receives from CP complete RRO (including labels)
MP assumes resource ownership operation by some means
CP signals TEARDOWN with an IN-PLACE attribute, this causes release by =
CP resources on each node without re-programming cross-connects

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 12:18 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

you are asking for something outside the scope of ccamp

entity X wants to recuperate a CP state - just let it do - if so allowed

then send a PathTear since there is no resource anymore associate to =
that=20
state (but this does not require any specific documentation)

-d.

"Bryskin, Igor" <[email-masked]>
Sent by: [email-masked]
25/08/2006 18:06
=20
        To:     "Lou Berger" <[email-masked]>, Dimitri=20
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp"=20
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, =

ALABS" <[email-masked]>, "Diego Caviglia" =
<[email-masked]>,=20
"Don Fedyk" <[email-masked]>, "Drake, John E"=20
<[email-masked]>, "Li, Han" <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
I-Ds)

Agree with Lou.

Can I also quote my own email? :=3D)

"We are
talking here about a capability of CP to acquire network resources and
build CP state for an LSP without actually re-programming crossconnects
(case MP->CP). Likewise, we are talking about capability of CP to =
release
resources and destroy CP state for an LSP without re-programming
crossconnects (case CP->MP). It is out of scope of those mechanisms how =
MP
(or any other plane) assumes or yields the ownership of resources of the
LSP whose ownership is transferred from/to CP."

So I think we are talking about two relatively simple and very =
symmetrical=20
CP functions.

Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Friday, August 25, 2006 11:57 AM
To: [email-masked]
Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A,
ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

Who said anything about exporting state?

At 11:51 AM 8/25/2006, [email-masked] wrote:

>lou - and why shall CCAMP provide a function to export states outside =
of
>its domain of competence
>
>thanks,
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 17:49
>
>         To:     "Don Fedyk" <[email-masked]>
>         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel,
>Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard,
>Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
><[email-masked]>, "Drake, John E" =
<[email-masked]>,
>"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>
>Don,
>
>At 10:40 AM 8/25/2006, Don Fedyk wrote:
> >I think there may be something here but I think even the requirements =

as
> >stated assume too much of the solution. What is the real issue?
>
>Per my previous e-mail:
>At 01:01 PM 8/24/2006, Lou Berger wrote:
>
> >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> >>[...]
> >>If we were to ask could you live without the CP->MP feature what
> >>response would we get versus asking if CP->MP is a soft requirement.
> >
> > From the discussions I've had on this with carriers, for some it's
> > a don't care, for others they won't deploy control plane without
> > this capability.
> >
> >Lou
>
>AND
>At 08:15 AM 8/24/2006, Lou Berger wrote:
> >[...]I therefore think the definition of CP->MP *is*
> >required.  There are multiple options for meeting this requirement,
> >but the solution must provide the "fallback" capability for services
> >existing at the time of the initial MP->CP transition and those
> >created after the transition.
>[...]
>
>I think a capability to remove LSP state while leaving forward state
>untouched will meet the requirements of those I've talked with.
>
>Lou
>
> >Regards,
> >Don

Delivery-date: Fri, 25 Aug 2006 16:32:32 +0000
Date: Fri, 25 Aug 2006 12:32:06 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Cc: Lou Berger <[email-masked]>,"Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>,"Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>,"Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, "Li, Han" <[email-masked]>,[email-masked]

Dimitri,
         Removing state should be a simple process of deleting local 
control plane state while not impacting the data plane 
state.  Exporting, at least to me, implies a more complicated API or 
other information transaction processing, which is certainly not needed here.

I think we're talking about a mechanism that should require a single 
"preserve data plane" bit in a PathTear message.  Nothing more.

Lou

At 12:14 PM 8/25/2006, [email-masked] wrote:

>lou - isn't "remove" or "export" having the same meaning in the present
>context ?
>
>
>
>
>Lou Berger <[email-masked]>
>Sent by: [email-masked]
>25/08/2006 17:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Li, Han" <[email-masked]>
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>Who said anything about exporting state?
>
>At 11:51 AM 8/25/2006, [email-masked] wrote:
>
> >lou - and why shall CCAMP provide a function to export states outside of
> >its domain of competence
> >
> >thanks,
> >- d.
> >
> >
> >
> >
> >Lou Berger <[email-masked]>
> >25/08/2006 17:49
> >
> >         To:     "Don Fedyk" <[email-masked]>
> >         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
> >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel,
> >Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard,
> >Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
> ><[email-masked]>, "Drake, John E" <[email-masked]>,
> >"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
> >         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
> >I-Ds)
> >
> >
> >
> >Don,
> >
> >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > >I think there may be something here but I think even the requirements
>as
> > >stated assume too much of the solution. What is the real issue?
> >
> >Per my previous e-mail:
> >At 01:01 PM 8/24/2006, Lou Berger wrote:
> >
> > >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> > >>[...]
> > >>If we were to ask could you live without the CP->MP feature what
> > >>response would we get versus asking if CP->MP is a soft requirement.
> > >
> > > From the discussions I've had on this with carriers, for some it's
> > > a don't care, for others they won't deploy control plane without
> > > this capability.
> > >
> > >Lou
> >
> >AND
> >At 08:15 AM 8/24/2006, Lou Berger wrote:
> > >[...]I therefore think the definition of CP->MP *is*
> > >required.  There are multiple options for meeting this requirement,
> > >but the solution must provide the "fallback" capability for services
> > >existing at the time of the initial MP->CP transition and those
> > >created after the transition.
> >[...]
> >
> >I think a capability to remove LSP state while leaving forward state
> >untouched will meet the requirements of those I've talked with.
> >
> >Lou
> >
> > >Regards,
> > >Don

Delivery-date: Fri, 25 Aug 2006 16:22:03 +0000
To: "Bryskin, Igor" <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>, [email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 18:18:13 +0200

you are asking for something outside the scope of ccamp

entity X wants to recuperate a CP state - just let it do - if so allowed

then send a PathTear since there is no resource anymore associate to that 
state (but this does not require any specific documentation)

-d.

"Bryskin, Igor" <[email-masked]>
Sent by: [email-masked]
25/08/2006 18:06
 
        To:     "Lou Berger" <[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, 
ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, 
"Don Fedyk" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Li, Han" <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Agree with Lou.

Can I also quote my own email? :=)

"We are
talking here about a capability of CP to acquire network resources and
build CP state for an LSP without actually re-programming crossconnects
(case MP->CP). Likewise, we are talking about capability of CP to release
resources and destroy CP state for an LSP without re-programming
crossconnects (case CP->MP). It is out of scope of those mechanisms how MP
(or any other plane) assumes or yields the ownership of resources of the
LSP whose ownership is transferred from/to CP."

So I think we are talking about two relatively simple and very symmetrical 
CP functions.

Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Friday, August 25, 2006 11:57 AM
To: [email-masked]
Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A,
ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

Who said anything about exporting state?

At 11:51 AM 8/25/2006, [email-masked] wrote:

>lou - and why shall CCAMP provide a function to export states outside of
>its domain of competence
>
>thanks,
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 17:49
>
>         To:     "Don Fedyk" <[email-masked]>
>         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel,
>Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard,
>Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
><[email-masked]>, "Drake, John E" <[email-masked]>,
>"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>
>Don,
>
>At 10:40 AM 8/25/2006, Don Fedyk wrote:
> >I think there may be something here but I think even the requirements 
as
> >stated assume too much of the solution. What is the real issue?
>
>Per my previous e-mail:
>At 01:01 PM 8/24/2006, Lou Berger wrote:
>
> >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> >>[...]
> >>If we were to ask could you live without the CP->MP feature what
> >>response would we get versus asking if CP->MP is a soft requirement.
> >
> > From the discussions I've had on this with carriers, for some it's
> > a don't care, for others they won't deploy control plane without
> > this capability.
> >
> >Lou
>
>AND
>At 08:15 AM 8/24/2006, Lou Berger wrote:
> >[...]I therefore think the definition of CP->MP *is*
> >required.  There are multiple options for meeting this requirement,
> >but the solution must provide the "fallback" capability for services
> >existing at the time of the initial MP->CP transition and those
> >created after the transition.
>[...]
>
>I think a capability to remove LSP state while leaving forward state
>untouched will meet the requirements of those I've talked with.
>
>Lou
>
> >Regards,
> >Don

Delivery-date: Fri, 25 Aug 2006 16:16:10 +0000
To: Lou Berger <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, Lou Berger <[email-masked]>, "Li, Han" <[email-masked]>, [email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 18:14:04 +0200

lou - isn't "remove" or "export" having the same meaning in the present 
context ?

Lou Berger <[email-masked]>
Sent by: [email-masked]
25/08/2006 17:57
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <[email-masked]>, "Farrel, Adrian" 
<[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Diego Caviglia" <[email-masked]>, "Don Fedyk" 
<[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John 
E" <[email-masked]>, "Li, Han" <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Who said anything about exporting state?

At 11:51 AM 8/25/2006, [email-masked] wrote:

>lou - and why shall CCAMP provide a function to export states outside of
>its domain of competence
>
>thanks,
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 17:49
>
>         To:     "Don Fedyk" <[email-masked]>
>         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel,
>Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard,
>Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
><[email-masked]>, "Drake, John E" <[email-masked]>,
>"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>
>Don,
>
>At 10:40 AM 8/25/2006, Don Fedyk wrote:
> >I think there may be something here but I think even the requirements 
as
> >stated assume too much of the solution. What is the real issue?
>
>Per my previous e-mail:
>At 01:01 PM 8/24/2006, Lou Berger wrote:
>
> >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> >>[...]
> >>If we were to ask could you live without the CP->MP feature what
> >>response would we get versus asking if CP->MP is a soft requirement.
> >
> > From the discussions I've had on this with carriers, for some it's
> > a don't care, for others they won't deploy control plane without
> > this capability.
> >
> >Lou
>
>AND
>At 08:15 AM 8/24/2006, Lou Berger wrote:
> >[...]I therefore think the definition of CP->MP *is*
> >required.  There are multiple options for meeting this requirement,
> >but the solution must provide the "fallback" capability for services
> >existing at the time of the initial MP->CP transition and those
> >created after the transition.
>[...]
>
>I think a capability to remove LSP state while leaving forward state
>untouched will meet the requirements of those I've talked with.
>
>Lou
>
> >Regards,
> >Don

Delivery-date: Fri, 25 Aug 2006 16:06:58 +0000
content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Fri, 25 Aug 2006 12:06:41 -0400
From: "Bryskin, Igor" <[email-masked]>
To: "Lou Berger" <[email-masked]>, <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Drake, John E" <[email-masked]>, "Li, Han" <[email-masked]>

Agree with Lou.

Can I also quote my own email? :=3D)

"We are
talking here about a capability of CP to acquire network resources and
build CP state for an LSP without actually re-programming crossconnects
(case MP->CP). Likewise, we are talking about capability of CP to =
release
resources and destroy CP state for an LSP without re-programming
crossconnects (case CP->MP). It is out of scope of those mechanisms how =
MP
(or any other plane) assumes or yields the ownership of resources of the
LSP whose ownership is transferred from/to CP."

So I think we are talking about two relatively simple and very =
symmetrical CP functions.

Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Friday, August 25, 2006 11:57 AM
To: [email-masked]
Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A,
ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

Who said anything about exporting state?

At 11:51 AM 8/25/2006, [email-masked] wrote:

>lou - and why shall CCAMP provide a function to export states outside =
of
>its domain of competence
>
>thanks,
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 17:49
>
>         To:     "Don Fedyk" <[email-masked]>
>         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel,
>Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard,
>Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
><[email-masked]>, "Drake, John E" =
<[email-masked]>,
>"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>
>Don,
>
>At 10:40 AM 8/25/2006, Don Fedyk wrote:
> >I think there may be something here but I think even the requirements =
as
> >stated assume too much of the solution. What is the real issue?
>
>Per my previous e-mail:
>At 01:01 PM 8/24/2006, Lou Berger wrote:
>
> >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> >>[...]
> >>If we were to ask could you live without the CP->MP feature what
> >>response would we get versus asking if CP->MP is a soft requirement.
> >
> > From the discussions I've had on this with carriers, for some it's
> > a don't care, for others they won't deploy control plane without
> > this capability.
> >
> >Lou
>
>AND
>At 08:15 AM 8/24/2006, Lou Berger wrote:
> >[...]I therefore think the definition of CP->MP *is*
> >required.  There are multiple options for meeting this requirement,
> >but the solution must provide the "fallback" capability for services
> >existing at the time of the initial MP->CP transition and those
> >created after the transition.
>[...]
>
>I think a capability to remove LSP state while leaving forward state
>untouched will meet the requirements of those I've talked with.
>
>Lou
>
> >Regards,
> >Don

Delivery-date: Fri, 25 Aug 2006 15:57:32 +0000
Date: Fri, 25 Aug 2006 11:57:08 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Cc: Lou Berger <[email-masked]>,"Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>,"Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>,"Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, "Li, Han" <[email-masked]>

Who said anything about exporting state?

At 11:51 AM 8/25/2006, [email-masked] wrote:

>lou - and why shall CCAMP provide a function to export states outside of
>its domain of competence
>
>thanks,
>- d.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 17:49
>
>         To:     "Don Fedyk" <[email-masked]>
>         cc:     "Bryskin, Igor" <[email-masked]>, Dimitri
>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel,
>Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard,
>Deborah A, ALABS" <[email-masked]>, "Diego Caviglia"
><[email-masked]>, "Drake, John E" <[email-masked]>,
>"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>
>Don,
>
>At 10:40 AM 8/25/2006, Don Fedyk wrote:
> >I think there may be something here but I think even the requirements as
> >stated assume too much of the solution. What is the real issue?
>
>Per my previous e-mail:
>At 01:01 PM 8/24/2006, Lou Berger wrote:
>
> >At 10:48 AM 8/24/2006, Don Fedyk wrote:
> >>[...]
> >>If we were to ask could you live without the CP->MP feature what
> >>response would we get versus asking if CP->MP is a soft requirement.
> >
> > From the discussions I've had on this with carriers, for some it's
> > a don't care, for others they won't deploy control plane without
> > this capability.
> >
> >Lou
>
>AND
>At 08:15 AM 8/24/2006, Lou Berger wrote:
> >[...]I therefore think the definition of CP->MP *is*
> >required.  There are multiple options for meeting this requirement,
> >but the solution must provide the "fallback" capability for services
> >existing at the time of the initial MP->CP transition and those
> >created after the transition.
>[...]
>
>I think a capability to remove LSP state while leaving forward state
>untouched will meet the requirements of those I've talked with.
>
>Lou
>
> >Regards,
> >Don

Delivery-date: Fri, 25 Aug 2006 15:53:01 +0000
To: Lou Berger <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 17:51:38 +0200

lou - and why shall CCAMP provide a function to export states outside of 
its domain of competence

thanks,
- d.

Lou Berger <[email-masked]>
25/08/2006 17:49
 
        To:     "Don Fedyk" <[email-masked]>
        cc:     "Bryskin, Igor" <[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel, 
Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard, 
Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" 
<[email-masked]>, "Drake, John E" <[email-masked]>, 
"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Don,

At 10:40 AM 8/25/2006, Don Fedyk wrote:
>I think there may be something here but I think even the requirements as
>stated assume too much of the solution. What is the real issue?

Per my previous e-mail:
At 01:01 PM 8/24/2006, Lou Berger wrote:

>At 10:48 AM 8/24/2006, Don Fedyk wrote:
>>[...]
>>If we were to ask could you live without the CP->MP feature what
>>response would we get versus asking if CP->MP is a soft requirement.
>
> From the discussions I've had on this with carriers, for some it's 
> a don't care, for others they won't deploy control plane without 
> this capability.
>
>Lou

AND
At 08:15 AM 8/24/2006, Lou Berger wrote:
>[...]I therefore think the definition of CP->MP *is* 
>required.  There are multiple options for meeting this requirement, 
>but the solution must provide the "fallback" capability for services 
>existing at the time of the initial MP->CP transition and those 
>created after the transition.
[...]

I think a capability to remove LSP state while leaving forward state 
untouched will meet the requirements of those I've talked with.

Lou

>Regards,
>Don

Delivery-date: Fri, 25 Aug 2006 15:51:15 +0000
To: "Bryskin, Igor" <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Fedyk, Don" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 17:49:17 +0200

igor

point a) i don't say that the CP import requires MP intervention - i just 
say this is the only case that requires specification from CCAMP 
perspective

point b) then operators askes to his new fashioned MP to implement an 
import function - why shall CCAMP care about exporting CP states ? 

-d.

"Bryskin, Igor" <[email-masked]>
25/08/2006 15:47
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" 
<[email-masked]>
        cc:     "Farrel, Adrian" <[email-masked]>, "ccamp" 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Diego Caviglia" <[email-masked]>, "Fedyk, Don" 
<[email-masked]>, "Drake, John E" <[email-masked]>, "Lou 
Berger" <[email-masked]>, "Li, Han" <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Dimitri,

My understanding of the MP->CP migration process failure and it's 
"back-out" requirement is as follows:

a) immediate failure of creating CP state for the services provisioned by 
MP. This failure does not require CP->MP feature
b) initial migration MP->CP succeeded, however, after some time (say, 1 
month) of provisioning via CP (and possibly creating many services solely 
via CP), provider decides that CP is not good or mature enough and wants 
go back to old-fashioned MP provisioning. I don't see how the operator 
will not loose these new services without the CP->MP function.

With all due respect the call on CP->MP function is provider's - not 
yours/Alcatel, mine/Movaz or John's/ Boeing.

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:51 AM
To: Dan Li
Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego Caviglia;
Fedyk, Don; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

hi - here below a couple of comments

o) the first point and i think i mention this already is that at the end 
speaking about MP in the present context restricts applicability of the 
"migration", the purpose of this draft is to create a control plane state 
when the same resources are already in use by an entity external to the 
control plane - call this an "import" function

o) the second when you write "Our main requirement for CP->MP migration is 

to handle "back-out" of the MP->CP migration process." is on itself 
confusing; what are you dealing with ? that the transition fails during 
its instantiation or that once LSP has a control plane state you want to 
move back where it used to belong - the former is a real issue that has 
never been discussed - the second is a non-issue (the other entity takes 
care to rapatriate the state in case, i don't think there is any need for 
an "export" function simple because we are not going to tell to which 
entity the LSP shall be brought back as we can have many of those)

o) the third point is when you mention "Modifying and tearing down LSPs 
after control plane failure" i pointed already that a migration from CP to 

somewhere else is impossible if you don't get access to the CP iself in 
particular if it is under failure - doesn't seem to be understood by 
authors (yet)

thanks,
- d.

Dan Li <[email-masked]>
25/08/2006 03:59
 
        To:     ccamp <[email-masked]>
        cc:     "Li, Han" <[email-masked]>, "Fedyk, Don" 
<[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Diego 
Caviglia <[email-masked]>, Igor Bryskin <[email-masked]>, 
"Farrel, Adrian" <[email-masked]>, Lou Berger <[email-masked]>, 
"Brungard, Deborah A, ALABS" <[email-masked]>, "Drake, John E" 
<[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Hi all,

The main motivation for this work is MP->CP migration. Our objective is to 

be able to introduce a control plane into an existing network without 
disrupting user traffic.

We understand that there are operators who would not want to perform this 
function. They might prefer to set up parallel LSPs using the CP and swap 
trafic to them before tearing down the MP LSPs, but we believe that this 
will not be possible in many busy networks. Other operators may prefer to 
have a network outage, but this will not be acceptable for all other 
operators. 
Therefore, in order to ensure interoperability between different vendors' 
equipment, we believe that a GMPLS process is required for this function. 
We 
fully expect it to be quite a simple process.

Our main requirement for CP->MP migration is to handle "back-out" of the 
MP->CP migration process. If there is some problem, the operator would 
like 
to be able to return to how things were before hand (i.e. MP control), 
without disrupting user traffic. We regard this as highly desirable, but 
probably not a mandatory requirement.

Modifying and tearing down LSPs after control plane failure is also a 
possible motivation, but the detailed requirements will need further 
examination. As has been pointed out, tear-down may be achieved relatively 

simply. But modification (for example, re-routing, increase in capacity, 
etc.) may be more complicated.

Other uses of CP->MP migration are interesting, but are not our main 
motivation, but we would like to observe that if the features that meet 
our 
requirements can also be used for other purposes then that is OK.

Obviously, from the discussions on the mailing list, our I-D does not 
currently present a sufficiently focused description of the motivation for 

this work. We welcome further discussion of the requirements to help us 
improve the draft.

It would be helpful in your discussions if you could understand that we 
are 
describing the requirements. If it turns out that the requirements can be 
met without changing the protocols, then we are very happy. But if you 
believe that no changes to the protocols are needed, we still need to 
state 
the requirements. So perhaps our conversation should be about the 
functional 
requirements not about the solutions.

Best regards,

Dan Li

Delivery-date: Fri, 25 Aug 2006 15:51:07 +0000
Date: Fri, 25 Aug 2006 11:49:26 -0400
To: "Don Fedyk" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Cc: "Bryskin, Igor" <[email-masked]>,<[email-masked]>, "Dan Li" <[email-masked]>,"Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>,"Li, Han" <[email-masked]>

Don,

At 10:40 AM 8/25/2006, Don Fedyk wrote:
>I think there may be something here but I think even the requirements as
>stated assume too much of the solution. What is the real issue?

Per my previous e-mail:
At 01:01 PM 8/24/2006, Lou Berger wrote:

>At 10:48 AM 8/24/2006, Don Fedyk wrote:
>>[...]
>>If we were to ask could you live without the CP->MP feature what
>>response would we get versus asking if CP->MP is a soft requirement.
>
> From the discussions I've had on this with carriers, for some it's 
> a don't care, for others they won't deploy control plane without 
> this capability.
>
>Lou

AND
At 08:15 AM 8/24/2006, Lou Berger wrote:
>[...]I therefore think the definition of CP->MP *is* 
>required.  There are multiple options for meeting this requirement, 
>but the solution must provide the "fallback" capability for services 
>existing at the time of the initial MP->CP transition and those 
>created after the transition.
[...]

I think a capability to remove LSP state while leaving forward state 
untouched will meet the requirements of those I've talked with.

Lou

>Regards,
>Don

Delivery-date: Fri, 25 Aug 2006 15:21:45 +0000
content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Fri, 25 Aug 2006 11:21:26 -0400
From: "Bryskin, Igor" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, <[email-masked]>, "Dan Li" <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>

Hi Don,

> My understanding of the MP->CP migration process failure and=20
> it's "back-out" requirement is as follows:
>=20
> a) immediate failure of creating CP state for the services=20
> provisioned by MP. This failure does not require CP->MP feature
> b) initial migration MP->CP succeeded, however, after some=20
> time (say, 1 month) of provisioning via CP (and possibly=20
> creating many services solely via CP), provider decides that=20
> CP is not good or mature enough and wants go back to=20
> old-fashioned MP provisioning. I don't see how the operator=20
> will not loose these new services without the CP->MP function.

I get the feeling we are grasping here.  The providers usually have a
staging and evaluation phase in a test bed before deploying a new
feature like a control plane.  If they decide they don't want it never
goes live.=20

IB>> One could argue that problems (and very serious ones) could be well =
hidden and could be discovered at any time. Also running production =
network is not the same as running test bed. Besides, to a large extent =
it could be purely psychological issue: as Diego put it "I always need a =
parachute when I try a new plane no matter how good is this plane: no =
parachute - no deal"

What is the difference between a MP based connection and CP based
connection with a static ERO and no backup?=20

IB>> The difference is which plane owns the connection, meaning, what =
tools operator uses to, say, modify or release the connection. It is not =
about path computation, so whether ERO is static or not is irrelevant.

I would think a better goal
would be to make such a static version as good as a management plane
version.=20

>=20
> With all due respect the call on CP->MP function is=20
> provider's - not yours/Alcatel, mine/Movaz or John's/ Boeing.

So the providers should be writing the requirement document rather than
us trying to reverse engineer the root of the problem. =20

I think there may be something here but I think even the requirements as
stated assume too much of the solution. What is the real issue?

IB>> The real issue (and I'd say the biggest GMPLS problem at the moment =
and for some time already) is operator's nervousness deploying the GMPLS =
and we need to do everything that could improve their comfort level and =
confidence.

Cheers,
Igor

Regards,
Don=20

>=20
> Igor
>=20
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, August 25, 2006 2:51 AM
> To: Dan Li
> Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego=20
> Caviglia; Fedyk, Don; Bryskin, Igor; Drake, John E; Lou=20
> Berger; Li, Han
> Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
>=20
>=20
> hi - here below a couple of comments
>=20
> o) the first point and i think i mention this already is that=20
> at the end speaking about MP in the present context restricts=20
> applicability of the "migration", the purpose of this draft=20
> is to create a control plane state when the same resources=20
> are already in use by an entity external to the control plane=20
> - call this an "import" function
>=20
> o) the second when you write "Our main requirement for CP->MP=20
> migration is to handle "back-out" of the MP->CP migration=20
> process." is on itself confusing; what are you dealing with ?=20
> that the transition fails during its instantiation or that=20
> once LSP has a control plane state you want to move back=20
> where it used to belong - the former is a real issue that has=20
> never been discussed - the second is a non-issue (the other=20
> entity takes care to rapatriate the state in case, i don't=20
> think there is any need for an "export" function simple=20
> because we are not going to tell to which entity the LSP=20
> shall be brought back as we can have many of those)
>=20
> o) the third point is when you mention "Modifying and tearing=20
> down LSPs after control plane failure" i pointed already that=20
> a migration from CP to somewhere else is impossible if you=20
> don't get access to the CP iself in particular if it is under=20
> failure - doesn't seem to be understood by authors (yet)
>=20
> thanks,
> - d.
>=20
>=20
<snip>

Envelope-to: [email-masked]
Delivery-date: Fri, 25 Aug 2006 15:02:46 +0000
To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'Exclude Routes - Extension to RSVP-TE' to Proposed  Standard (draft-ietf-ccamp-rsvp-te-exclude-route) 
Reply-To: [email-masked]
Cc: <[email-masked]>
Message-Id: <[email-masked]>
Date: Fri, 25 Aug 2006 11:02:23 -0400

The IESG has received a request from the Common Control and Measurement 
Plane WG to consider the following document:

- 'Exclude Routes - Extension to RSVP-TE '
   <draft-ietf-ccamp-rsvp-te-exclude-route-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-09-08.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.txt

Envelope-to: [email-masked]
Delivery-date: Fri, 25 Aug 2006 14:50:34 +0000
To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'Extensions to GMPLS RSVP Graceful Restart' to  Proposed Standard (draft-ietf-ccamp-rsvp-restart-ext) 
Reply-To: [email-masked]
Cc: <[email-masked]>
Message-Id: <[email-masked]>
Date: Fri, 25 Aug 2006 10:50:02 -0400

The IESG has received a request from the Common Control and Measurement 
Plane WG to consider the following document:

- 'Extensions to GMPLS RSVP Graceful Restart '
   <draft-ietf-ccamp-rsvp-restart-ext-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-09-08.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-05.txt

Delivery-date: Fri, 25 Aug 2006 14:40:46 +0000
Content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Fri, 25 Aug 2006 10:40:01 -0400
From: "Don Fedyk" <[email-masked]>
To: "Bryskin, Igor" <[email-masked]>, <[email-masked]>, "Dan Li" <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>

Hi Igor

> -----Original Message-----
>=20
> Dimitri,
>=20
> My understanding of the MP->CP migration process failure and=20
> it's "back-out" requirement is as follows:
>=20
> a) immediate failure of creating CP state for the services=20
> provisioned by MP. This failure does not require CP->MP feature
> b) initial migration MP->CP succeeded, however, after some=20
> time (say, 1 month) of provisioning via CP (and possibly=20
> creating many services solely via CP), provider decides that=20
> CP is not good or mature enough and wants go back to=20
> old-fashioned MP provisioning. I don't see how the operator=20
> will not loose these new services without the CP->MP function.

I get the feeling we are grasping here.  The providers usually have a
staging and evaluation phase in a test bed before deploying a new
feature like a control plane.  If they decide they don't want it never
goes live.=20

What is the difference between a MP based connection and CP based
connection with a static ERO and no backup? I would think a better goal
would be to make such a static version as good as a management plane
version.=20

>=20
> With all due respect the call on CP->MP function is=20
> provider's - not yours/Alcatel, mine/Movaz or John's/ Boeing.

So the providers should be writing the requirement document rather than
us trying to reverse engineer the root of the problem. =20

I think there may be something here but I think even the requirements as
stated assume too much of the solution. What is the real issue?

Regards,
Don=20

>=20
> Igor
>=20
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, August 25, 2006 2:51 AM
> To: Dan Li
> Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego=20
> Caviglia; Fedyk, Don; Bryskin, Igor; Drake, John E; Lou=20
> Berger; Li, Han
> Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
>=20
>=20
> hi - here below a couple of comments
>=20
> o) the first point and i think i mention this already is that=20
> at the end speaking about MP in the present context restricts=20
> applicability of the "migration", the purpose of this draft=20
> is to create a control plane state when the same resources=20
> are already in use by an entity external to the control plane=20
> - call this an "import" function
>=20
> o) the second when you write "Our main requirement for CP->MP=20
> migration is to handle "back-out" of the MP->CP migration=20
> process." is on itself confusing; what are you dealing with ?=20
> that the transition fails during its instantiation or that=20
> once LSP has a control plane state you want to move back=20
> where it used to belong - the former is a real issue that has=20
> never been discussed - the second is a non-issue (the other=20
> entity takes care to rapatriate the state in case, i don't=20
> think there is any need for an "export" function simple=20
> because we are not going to tell to which entity the LSP=20
> shall be brought back as we can have many of those)
>=20
> o) the third point is when you mention "Modifying and tearing=20
> down LSPs after control plane failure" i pointed already that=20
> a migration from CP to somewhere else is impossible if you=20
> don't get access to the CP iself in particular if it is under=20
> failure - doesn't seem to be understood by authors (yet)
>=20
> thanks,
> - d.
>=20
>=20
<snip>

Delivery-date: Fri, 25 Aug 2006 13:48:13 +0000
content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Fri, 25 Aug 2006 09:47:06 -0400
From: "Bryskin, Igor" <[email-masked]>
To: <[email-masked]>, "Dan Li" <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Fedyk, Don" <[email-masked]>, "Drake, John E" <[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>

Dimitri,

My understanding of the MP->CP migration process failure and it's =
"back-out" requirement is as follows:

a) immediate failure of creating CP state for the services provisioned =
by MP. This failure does not require CP->MP feature
b) initial migration MP->CP succeeded, however, after some time (say, 1 =
month) of provisioning via CP (and possibly creating many services =
solely via CP), provider decides that CP is not good or mature enough =
and wants go back to old-fashioned MP provisioning. I don't see how the =
operator will not loose these new services without the CP->MP function.

With all due respect the call on CP->MP function is provider's - not =
yours/Alcatel, mine/Movaz or John's/ Boeing.

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:51 AM
To: Dan Li
Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego Caviglia;
Fedyk, Don; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

hi - here below a couple of comments

o) the first point and i think i mention this already is that at the end =

speaking about MP in the present context restricts applicability of the=20
"migration", the purpose of this draft is to create a control plane =
state=20
when the same resources are already in use by an entity external to the=20
control plane - call this an "import" function

o) the second when you write "Our main requirement for CP->MP migration =
is=20
to handle "back-out" of the MP->CP migration process." is on itself=20
confusing; what are you dealing with ? that the transition fails during=20
its instantiation or that once LSP has a control plane state you want to =

move back where it used to belong - the former is a real issue that has=20
never been discussed - the second is a non-issue (the other entity takes =

care to rapatriate the state in case, i don't think there is any need =
for=20
an "export" function simple because we are not going to tell to which=20
entity the LSP shall be brought back as we can have many of those)

o) the third point is when you mention "Modifying and tearing down LSPs=20
after control plane failure" i pointed already that a migration from CP =
to=20
somewhere else is impossible if you don't get access to the CP iself in=20
particular if it is under failure - doesn't seem to be understood by=20
authors (yet)

thanks,
- d.

Dan Li <[email-masked]>
25/08/2006 03:59
=20
        To:     ccamp <[email-masked]>
        cc:     "Li, Han" <[email-masked]>, "Fedyk, Don"=20
<[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Diego=20
Caviglia <[email-masked]>, Igor Bryskin =
<[email-masked]>,=20
"Farrel, Adrian" <[email-masked]>, Lou Berger <[email-masked]>,=20
"Brungard, Deborah A, ALABS" <[email-masked]>, "Drake, John E"=20
<[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG=20
I-Ds)

Hi all,

The main motivation for this work is MP->CP migration. Our objective is =
to=20

be able to introduce a control plane into an existing network without=20
disrupting user traffic.

We understand that there are operators who would not want to perform =
this=20
function. They might prefer to set up parallel LSPs using the CP and =
swap=20
trafic to them before tearing down the MP LSPs, but we believe that this =

will not be possible in many busy networks. Other operators may prefer =
to=20
have a network outage, but this will not be acceptable for all other=20
operators.=20
Therefore, in order to ensure interoperability between different =
vendors'=20
equipment, we believe that a GMPLS process is required for this =
function.=20
We=20
fully expect it to be quite a simple process.

Our main requirement for CP->MP migration is to handle "back-out" of the =

MP->CP migration process. If there is some problem, the operator would=20
like=20
to be able to return to how things were before hand (i.e. MP control),=20
without disrupting user traffic. We regard this as highly desirable, but =

probably not a mandatory requirement.

Modifying and tearing down LSPs after control plane failure is also a=20
possible motivation, but the detailed requirements will need further=20
examination. As has been pointed out, tear-down may be achieved =
relatively=20

simply. But modification (for example, re-routing, increase in capacity, =

etc.) may be more complicated.

Other uses of CP->MP migration are interesting, but are not our main=20
motivation, but we would like to observe that if the features that meet=20
our=20
requirements can also be used for other purposes then that is OK.

Obviously, from the discussions on the mailing list, our I-D does not=20
currently present a sufficiently focused description of the motivation =
for=20

this work. We welcome further discussion of the requirements to help us=20
improve the draft.

It would be helpful in your discussions if you could understand that we=20
are=20
describing the requirements. If it turns out that the requirements can =
be=20
met without changing the protocols, then we are very happy. But if you=20
believe that no changes to the protocols are needed, we still need to=20
state=20
the requirements. So perhaps our conversation should be about the=20
functional=20
requirements not about the solutions.

Best regards,

Dan Li

Delivery-date: Fri, 25 Aug 2006 09:26:29 +0000
To: "Diego Caviglia" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 11:25:46 +0200

diego - 

i think this has been mentioned a couple of times - there is no need to 
make any assumption about MP whatsover in the context of CP capability 
we're discussing here - discussion deviated due to the context where the 
present i-d has been discussed

this i-d shall just focus on an import functionality of an already 
allocated resource (without making assumption on its current owner) this 
turns out that there is no possibility to have a revertive behaviour as 
from CP -> X, as the former won't keep track of this origin

the only thing this i-d could mention is that the previous owner Y may 
wish to provide from its own import functionality such as to allow CP -> Y 
transition

thanks,
- d.

"Diego Caviglia" <[email-masked]>
Sent by: [email-masked]
25/08/2006 10:56
 
        To:     [email-masked]
        cc:      "Don Fedyk" <[email-masked]>, "Lou Berger" 
<[email-masked]>, "Diego Caviglia" <[email-masked]>, 
<[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Igor,
      what you say is exactly what we had in mind thinking about the ID.

Regards

Diego

"Bryskin, Igor" <[email-masked]> on 24/08/2006 18.09.36

To:    "Don Fedyk" <[email-masked]>, "Lou Berger" <[email-masked]>,
       "Diego Caviglia" <[email-masked]>
cc:    <[email-masked]>

Subject:    RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

Don,

> The other point that baffles me is there is not one "standard" MP that
> I'm aware of so really we are talking many variations of MP to a
> standard CP. So how do you define a CP to variations of MPs? The
> document currently oversimplifies this aspect IMHO.

I don't think we need to assume that MP is standard in the context of
CP->MP and MP->CP discussion. IMO it does not even have to be MP. We are
talking here about a capability of CP to acquire network resources and
build CP state for an LSP without actually re-programming crossconnects
(case MP->CP). Likewise, we are talking about capability of CP to release
resources and destroy CP state for an LSP without re-programming
crossconnects (case CP->MP). It is out of scope of those mechanisms how MP
(or any other plane) assumes or yields the ownership of resources of the
LSP whose ownership is transferred from/to CP..

Igor

> -----Original Message-----
>
> Diego,
>          In my experience in talking about this feature with
> carriers is that some (but not all) will require such
> symmetric behavior.  I think the other rational for this
> feature are irrelevant.  Again, the sole reason I've seen for
> this requirement is that to deploy MP->CP some will require
> that there be support for CP->MP.
>
> I therefore think the definition of CP->MP *is* required.
> There are multiple options for meeting this requirement, but
> the solution must provide the "fallback" capability for
> services existing at the time of the initial MP->CP
> transition and those created after the transition.
>
> I think a SHOULD level requirement is sufficient for this
> capability, but I'd be interested if those representing
> carries on the list differ.
>
> Lou
>
> At 03:09 AM 8/24/2006, Diego Caviglia wrote:
>
>
> >In my mind the CP->MP feature can be useful for mainly two purposes:
> >1)    symmetricity with the companion feature (MP->CP)
> >[...]
> >
> >We (the authors of the ID) agreed with Dimitri that CP->MP is not a
> >must and I have no problem to move it to should/shall/may state.
> >
> >[...]
> >However the focus of the ID is on MP->CP handover and if the
> community
> >is strongly against of CP->MP even in the form of a should/shall/may
> >requirement we can strip this out.
> >
> >Regards
> >
> >Diego
>
>
>

Delivery-date: Fri, 25 Aug 2006 08:58:49 +0000
Sensitivity: 
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
To: [email-masked]
Cc: ""Don Fedyk" <dwfedyk" <[email-masked]>, ""Lou Berger" <lberger" <[email-masked]>, ""Diego Caviglia" <Diego.Caviglia" <[email-masked]>, "<ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Fri, 25 Aug 2006 10:56:35 +0200

Igor,
      what you say is exactly what we had in mind thinking about the ID.

Regards

Diego

"Bryskin, Igor" <[email-masked]> on 24/08/2006 18.09.36

To:    "Don Fedyk" <[email-masked]>, "Lou Berger" <[email-masked]>,
       "Diego Caviglia" <[email-masked]>
cc:    <[email-masked]>

Subject:    RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

Don,

> The other point that baffles me is there is not one "standard" MP that
> I'm aware of so really we are talking many variations of MP to a
> standard CP. So how do you define a CP to variations of MPs? The
> document currently oversimplifies this aspect IMHO.

I don't think we need to assume that MP is standard in the context of
CP->MP and MP->CP discussion. IMO it does not even have to be MP. We are
talking here about a capability of CP to acquire network resources and
build CP state for an LSP without actually re-programming crossconnects
(case MP->CP). Likewise, we are talking about capability of CP to release
resources and destroy CP state for an LSP without re-programming
crossconnects (case CP->MP). It is out of scope of those mechanisms how MP
(or any other plane) assumes or yields the ownership of resources of the
LSP whose ownership is transferred from/to CP..

Igor

> -----Original Message-----
>
> Diego,
>          In my experience in talking about this feature with
> carriers is that some (but not all) will require such
> symmetric behavior.  I think the other rational for this
> feature are irrelevant.  Again, the sole reason I've seen for
> this requirement is that to deploy MP->CP some will require
> that there be support for CP->MP.
>
> I therefore think the definition of CP->MP *is* required.
> There are multiple options for meeting this requirement, but
> the solution must provide the "fallback" capability for
> services existing at the time of the initial MP->CP
> transition and those created after the transition.
>
> I think a SHOULD level requirement is sufficient for this
> capability, but I'd be interested if those representing
> carries on the list differ.
>
> Lou
>
> At 03:09 AM 8/24/2006, Diego Caviglia wrote:
>
>
> >In my mind the CP->MP feature can be useful for mainly two purposes:
> >1)    symmetricity with the companion feature (MP->CP)
> >[...]
> >
> >We (the authors of the ID) agreed with Dimitri that CP->MP is not a
> >must and I have no problem to move it to should/shall/may state.
> >
> >[...]
> >However the focus of the ID is on MP->CP handover and if the
> community
> >is strongly against of CP->MP even in the form of a should/shall/may
> >requirement we can strip this out.
> >
> >Regards
> >
> >Diego
>
>
>

Delivery-date: Fri, 25 Aug 2006 08:49:10 +0000
To: =?gb2312?B?wO7qzw==?= <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, [email-masked], "'Dan Li'" <[email-masked]>, [email-masked]
Subject: Re:  =?gb2312?B?tPC4tDogUG9sbGluZyBmb3IgbmV3IFdHIEktRHM=?=
From: [email-masked]
Date: Fri, 25 Aug 2006 10:48:03 +0200

Delivery-date: Fri, 25 Aug 2006 06:53:22 +0000
To: Dan Li <[email-masked]>
Cc: "Farrel, Adrian" <[email-masked]>, ccamp <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, Diego Caviglia <[email-masked]>, "Fedyk, Don" <[email-masked]>, Igor Bryskin <[email-masked]>, "Drake, John E" <[email-masked]>, Lou Berger <[email-masked]>, "Li, Han" <[email-masked]>
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Fri, 25 Aug 2006 08:51:12 +0200

hi - here below a couple of comments

o) the first point and i think i mention this already is that at the end 
speaking about MP in the present context restricts applicability of the 
"migration", the purpose of this draft is to create a control plane state 
when the same resources are already in use by an entity external to the 
control plane - call this an "import" function

o) the second when you write "Our main requirement for CP->MP migration is 
to handle "back-out" of the MP->CP migration process." is on itself 
confusing; what are you dealing with ? that the transition fails during 
its instantiation or that once LSP has a control plane state you want to 
move back where it used to belong - the former is a real issue that has 
never been discussed - the second is a non-issue (the other entity takes 
care to rapatriate the state in case, i don't think there is any need for 
an "export" function simple because we are not going to tell to which 
entity the LSP shall be brought back as we can have many of those)

o) the third point is when you mention "Modifying and tearing down LSPs 
after control plane failure" i pointed already that a migration from CP to 
somewhere else is impossible if you don't get access to the CP iself in 
particular if it is under failure - doesn't seem to be understood by 
authors (yet)

thanks,
- d.

Dan Li <[email-masked]>
25/08/2006 03:59
 
        To:     ccamp <[email-masked]>
        cc:     "Li, Han" <[email-masked]>, "Fedyk, Don" 
<[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Diego 
Caviglia <[email-masked]>, Igor Bryskin <[email-masked]>, 
"Farrel, Adrian" <[email-masked]>, Lou Berger <[email-masked]>, 
"Brungard, Deborah A, ALABS" <[email-masked]>, "Drake, John E" 
<[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Hi all,

The main motivation for this work is MP->CP migration. Our objective is to 

be able to introduce a control plane into an existing network without 
disrupting user traffic.

We understand that there are operators who would not want to perform this 
function. They might prefer to set up parallel LSPs using the CP and swap 
trafic to them before tearing down the MP LSPs, but we believe that this 
will not be possible in many busy networks. Other operators may prefer to 
have a network outage, but this will not be acceptable for all other 
operators. 
Therefore, in order to ensure interoperability between different vendors' 
equipment, we believe that a GMPLS process is required for this function. 
We 
fully expect it to be quite a simple process.

Our main requirement for CP->MP migration is to handle "back-out" of the 
MP->CP migration process. If there is some problem, the operator would 
like 
to be able to return to how things were before hand (i.e. MP control), 
without disrupting user traffic. We regard this as highly desirable, but 
probably not a mandatory requirement.

Modifying and tearing down LSPs after control plane failure is also a 
possible motivation, but the detailed requirements will need further 
examination. As has been pointed out, tear-down may be achieved relatively 

simply. But modification (for example, re-routing, increase in capacity, 
etc.) may be more complicated.

Other uses of CP->MP migration are interesting, but are not our main 
motivation, but we would like to observe that if the features that meet 
our 
requirements can also be used for other purposes then that is OK.

Obviously, from the discussions on the mailing list, our I-D does not 
currently present a sufficiently focused description of the motivation for 

this work. We welcome further discussion of the requirements to help us 
improve the draft.

It would be helpful in your discussions if you could understand that we 
are 
describing the requirements. If it turns out that the requirements can be 
met without changing the protocols, then we are very happy. But if you 
believe that no changes to the protocols are needed, we still need to 
state 
the requirements. So perhaps our conversation should be about the 
functional 
requirements not about the solutions.

Best regards,

Dan Li

Delivery-date: Fri, 25 Aug 2006 02:07:02 +0000
Date: Fri, 25 Aug 2006 09:59:23 +0800
From: Dan Li <[email-masked]>
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
To: ccamp <[email-masked]>
Cc: "Li, Han" <[email-masked]>, "Fedyk, Don" <[email-masked]>, Papadimitriou Dimitri <[email-masked]>, Diego Caviglia <[email-masked]>, Igor Bryskin <[email-masked]>, "Farrel, Adrian" <[email-masked]>, Lou Berger <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Drake, John E" <[email-masked]>

Hi all,

The main motivation for this work is MP->CP migration. Our objective is to 
be able to introduce a control plane into an existing network without 
disrupting user traffic.

We understand that there are operators who would not want to perform this 
function. They might prefer to set up parallel LSPs using the CP and swap 
trafic to them before tearing down the MP LSPs, but we believe that this 
will not be possible in many busy networks. Other operators may prefer to 
have a network outage, but this will not be acceptable for all other operators. 
Therefore, in order to ensure interoperability between different vendors' 
equipment, we believe that a GMPLS process is required for this function. We 
fully expect it to be quite a simple process.

Our main requirement for CP->MP migration is to handle "back-out" of the 
MP->CP migration process. If there is some problem, the operator would like 
to be able to return to how things were before hand (i.e. MP control), 
without disrupting user traffic. We regard this as highly desirable, but 
probably not a mandatory requirement.

Modifying and tearing down LSPs after control plane failure is also a 
possible motivation, but the detailed requirements will need further 
examination. As has been pointed out, tear-down may be achieved relatively 
simply. But modification (for example, re-routing, increase in capacity, 
etc.) may be more complicated.

Other uses of CP->MP migration are interesting, but are not our main 
motivation, but we would like to observe that if the features that meet our 
requirements can also be used for other purposes then that is OK.

Obviously, from the discussions on the mailing list, our I-D does not 
currently present a sufficiently focused description of the motivation for 
this work. We welcome further discussion of the requirements to help us 
improve the draft.

It would be helpful in your discussions if you could understand that we are 
describing the requirements. If it turns out that the requirements can be 
met without changing the protocols, then we are very happy. But if you 
believe that no changes to the protocols are needed, we still need to state 
the requirements. So perhaps our conversation should be about the functional 
requirements not about the solutions.

Best regards,

Dan Li

Delivery-date: Thu, 24 Aug 2006 17:02:04 +0000
Date: Thu, 24 Aug 2006 13:01:13 -0400
To: "Don Fedyk" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Cc: "Lou Berger" <[email-masked]>, "Diego Caviglia" <[email-masked]>,<[email-masked]>

>
>If we were to ask could you live without the CP->MP feature what
>response would we get versus asking if CP->MP is a soft requirement.

 From the discussions I've had on this with carriers, for some it's a 
don't care, for others they won't deploy control plane without this capability.

Lou

At 10:48 AM 8/24/2006, Don Fedyk wrote:

>Lou and Diego, all
>
>Two points.
>
>If we were to ask could you live without the CP->MP feature what
>response would we get versus asking if CP->MP is a soft requirement.
>
>The other point that baffles me is there is not one "standard" MP that
>I'm aware of so really we are talking many variations of MP to a
>standard CP. So how do you define a CP to variations of MPs? The
>document currently oversimplifies this aspect IMHO.
>
>Thanks,
>Don
>
> > -----Original Message-----
> >
> > Diego,
> >          In my experience in talking about this feature with
> > carriers is that some (but not all) will require such
> > symmetric behavior.  I think the other rational for this
> > feature are irrelevant.  Again, the sole reason I've seen for
> > this requirement is that to deploy MP->CP some will require
> > that there be support for CP->MP.
> >
> > I therefore think the definition of CP->MP *is* required.
> > There are multiple options for meeting this requirement, but
> > the solution must provide the "fallback" capability for
> > services existing at the time of the initial MP->CP
> > transition and those created after the transition.
> >
> > I think a SHOULD level requirement is sufficient for this
> > capability, but I'd be interested if those representing
> > carries on the list differ.
> >
> > Lou
> >
> > At 03:09 AM 8/24/2006, Diego Caviglia wrote:
> >
> >
> > >In my mind the CP->MP feature can be useful for mainly two purposes:
> > >1)    symmetricity with the companion feature (MP->CP)
> > >[...]
> > >
> > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a
> > >must and I have no problem to move it to should/shall/may state.
> > >
> > >[...]
> > >However the focus of the ID is on MP->CP handover and if the
> > community
> > >is strongly against of CP->MP even in the form of a should/shall/may
> > >requirement we can strip this out.
> > >
> > >Regards
> > >
> > >Diego
> >
> >
> >

Delivery-date: Thu, 24 Aug 2006 16:10:36 +0000
content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Thu, 24 Aug 2006 12:09:36 -0400
From: "Bryskin, Igor" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, "Lou Berger" <[email-masked]>, "Diego Caviglia" <[email-masked]>
Cc: <[email-masked]>

Don,

> The other point that baffles me is there is not one "standard" MP that
> I'm aware of so really we are talking many variations of MP to a
> standard CP. So how do you define a CP to variations of MPs? The
> document currently oversimplifies this aspect IMHO.

I don't think we need to assume that MP is standard in the context of =
CP->MP and MP->CP discussion. IMO it does not even have to be MP. We are =
talking here about a capability of CP to acquire network resources and =
build CP state for an LSP without actually re-programming crossconnects =
(case MP->CP). Likewise, we are talking about capability of CP to =
release resources and destroy CP state for an LSP without re-programming =
crossconnects (case CP->MP). It is out of scope of those mechanisms how =
MP (or any other plane) assumes or yields the ownership of resources of =
the LSP whose ownership is transferred from/to CP..

Igor

> -----Original Message-----
>=20
> Diego,
>          In my experience in talking about this feature with=20
> carriers is that some (but not all) will require such=20
> symmetric behavior.  I think the other rational for this=20
> feature are irrelevant.  Again, the sole reason I've seen for=20
> this requirement is that to deploy MP->CP some will require=20
> that there be support for CP->MP.
>=20
> I therefore think the definition of CP->MP *is* required. =20
> There are multiple options for meeting this requirement, but=20
> the solution must provide the "fallback" capability for=20
> services existing at the time of the initial MP->CP=20
> transition and those created after the transition.
>=20
> I think a SHOULD level requirement is sufficient for this=20
> capability, but I'd be interested if those representing=20
> carries on the list differ.
>=20
> Lou
>=20
> At 03:09 AM 8/24/2006, Diego Caviglia wrote:
>=20
>=20
> >In my mind the CP->MP feature can be useful for mainly two purposes:
> >1)    symmetricity with the companion feature (MP->CP)
> >[...]
> >
> >We (the authors of the ID) agreed with Dimitri that CP->MP is not a=20
> >must and I have no problem to move it to should/shall/may state.
> >
> >[...]
> >However the focus of the ID is on MP->CP handover and if the=20
> community=20
> >is strongly against of CP->MP even in the form of a should/shall/may=20
> >requirement we can strip this out.
> >
> >Regards
> >
> >Diego
>=20
>=20
>=20

Delivery-date: Thu, 24 Aug 2006 15:44:56 +0000
Content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Thu, 24 Aug 2006 11:44:21 -0400
From: "Don Fedyk" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>
Cc: "\"Lou Berger\" <lberger" <[email-masked]>, "<ccamp" <[email-masked]>

Hi Diego=20

In Line as well

> -----Original Message-----
> Hi Don,
>         in line.
>=20
> Regards
>=20
>=20
>=20
> "Don Fedyk" <[email-masked]>@ops.ietf.org on 24/08/2006 16.48.48
>=20
> Sent by:    [email-masked]
>=20
>=20
> To:    "Lou Berger" <[email-masked]>, "Diego Caviglia"
>        <[email-masked]>
> cc:    <[email-masked]>
>=20
> Subject:    RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
>=20
> Lou and Diego, all
>=20
> Two points.
>=20
> If we were to ask could you live without the CP->MP feature=20
> what response would we get versus asking if CP->MP is a soft=20
> requirement.
> [dc] I think that the poll request from Adrian was trying to=20
> solve this point.
>=20
> The other point that baffles me is there is not one=20
> "standard" MP that I'm aware of so really we are talking many=20
> variations of MP to a standard CP. So how do you define a CP=20
> to variations of MPs? The document currently oversimplifies=20
> this aspect IMHO.
> [dc] This is not clear to me.  Could you please clarify?

[DF] Where do we find the standard MP representation of a Path? What
MIBS etc. Many legacy systems have differnet MP representations of this
and may use extra attributes or objects. It varies by which Optical or
packet based system GMPLS is to control. When moving to GMPLS we can
rationalize these objects to GMPLS objects but without
generation/storage and possibily signaling of these MP objects the
CP->MP mapping is incomplete. =20

Regards,

Don =20

>=20
> Thanks,
> Don
>=20
> > -----Original Message-----
> >
> > Diego,
> >          In my experience in talking about this feature=20
> with carriers=20
> > is that some (but not all) will require such symmetric behavior.  I=20
> > think the other rational for this feature are irrelevant. =20
> Again, the=20
> > sole reason I've seen for this requirement is that to deploy MP->CP=20
> > some will require that there be support for CP->MP.
> >
> > I therefore think the definition of CP->MP *is* required.
> > There are multiple options for meeting this requirement, but the=20
> > solution must provide the "fallback" capability for=20
> services existing=20
> > at the time of the initial MP->CP transition and those=20
> created after=20
> > the transition.
> >
> > I think a SHOULD level requirement is sufficient for this=20
> capability,=20
> > but I'd be interested if those representing carries on the list=20
> > differ.
> >
> > Lou
> >
> > At 03:09 AM 8/24/2006, Diego Caviglia wrote:
> >
> >
> > >In my mind the CP->MP feature can be useful for mainly two=20
> purposes:
> > >1)    symmetricity with the companion feature (MP->CP)
> > >[...]
> > >
> > >We (the authors of the ID) agreed with Dimitri that CP->MP=20
> is not a=20
> > >must and I have no problem to move it to should/shall/may state.
> > >
> > >[...]
> > >However the focus of the ID is on MP->CP handover and if the
> > community
> > >is strongly against of CP->MP even in the form of a=20
> should/shall/may=20
> > >requirement we can strip this out.
> > >
> > >Regards
> > >
> > >Diego
> >
> >
> >
>=20
>=20
>=20
>=20
>=20
>=20
>=20

Delivery-date: Thu, 24 Aug 2006 15:30:48 +0000
Content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Thu, 24 Aug 2006 08:30:30 -0700
From: "Drake, John E" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, "Lou Berger" <[email-masked]>, "Diego Caviglia" <[email-masked]>
Cc: <[email-masked]>

>=20
> The other point that baffles me is there is not one=20
> "standard" MP that I'm aware of so really we are talking many=20
> variations of MP to a standard CP. So how do you define a CP=20
> to variations of MPs? The document currently oversimplifies=20
> this aspect IMHO.

JD:  If you go back to the original MPL(ambda)S proposal, this was one
of the reasons given for building a standards based control plane.

>=20
> Thanks,
> Don
>=20
> > -----Original Message-----
> >=20
> > Diego,
> >          In my experience in talking about this feature with
> > carriers is that some (but not all) will require such=20
> > symmetric behavior.  I think the other rational for this=20
> > feature are irrelevant.  Again, the sole reason I've seen for=20
> > this requirement is that to deploy MP->CP some will require=20
> > that there be support for CP->MP.
> >=20
> > I therefore think the definition of CP->MP *is* required.
> > There are multiple options for meeting this requirement, but=20
> > the solution must provide the "fallback" capability for=20
> > services existing at the time of the initial MP->CP=20
> > transition and those created after the transition.
> >=20
> > I think a SHOULD level requirement is sufficient for this
> > capability, but I'd be interested if those representing=20
> > carries on the list differ.
> >=20
> > Lou
> >=20
> > At 03:09 AM 8/24/2006, Diego Caviglia wrote:
> >=20
> >=20
> > >In my mind the CP->MP feature can be useful for mainly two=20
> purposes:
> > >1)    symmetricity with the companion feature (MP->CP)
> > >[...]
> > >
> > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a
> > >must and I have no problem to move it to should/shall/may state.
> > >
> > >[...]
> > >However the focus of the ID is on MP->CP handover and if the
> > community
> > >is strongly against of CP->MP even in the form of a=20
> should/shall/may
> > >requirement we can strip this out.
> > >
> > >Regards
> > >
> > >Diego
> >=20
> >=20
> >=20
>=20
>=20

Delivery-date: Thu, 24 Aug 2006 15:26:13 +0000
Sensitivity: 
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
To: [email-masked]
Cc: ""Lou Berger" <lberger" <[email-masked]>, "<ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Thu, 24 Aug 2006 17:24:00 +0200

Hi Don,
        in line.

Regards

"Don Fedyk" <[email-masked]>@ops.ietf.org on 24/08/2006 16.48.48

Sent by:    [email-masked]

To:    "Lou Berger" <[email-masked]>, "Diego Caviglia"
       <[email-masked]>
cc:    <[email-masked]>

Subject:    RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

Lou and Diego, all

Two points.

If we were to ask could you live without the CP->MP feature what
response would we get versus asking if CP->MP is a soft requirement.
[dc] I think that the poll request from Adrian was trying to solve this
point.

The other point that baffles me is there is not one "standard" MP that
I'm aware of so really we are talking many variations of MP to a
standard CP. So how do you define a CP to variations of MPs? The
document currently oversimplifies this aspect IMHO.
[dc] This is not clear to me.  Could you please clarify?

Thanks,
Don

> -----Original Message-----
>
> Diego,
>          In my experience in talking about this feature with
> carriers is that some (but not all) will require such
> symmetric behavior.  I think the other rational for this
> feature are irrelevant.  Again, the sole reason I've seen for
> this requirement is that to deploy MP->CP some will require
> that there be support for CP->MP.
>
> I therefore think the definition of CP->MP *is* required.
> There are multiple options for meeting this requirement, but
> the solution must provide the "fallback" capability for
> services existing at the time of the initial MP->CP
> transition and those created after the transition.
>
> I think a SHOULD level requirement is sufficient for this
> capability, but I'd be interested if those representing
> carries on the list differ.
>
> Lou
>
> At 03:09 AM 8/24/2006, Diego Caviglia wrote:
>
>
> >In my mind the CP->MP feature can be useful for mainly two purposes:
> >1)    symmetricity with the companion feature (MP->CP)
> >[...]
> >
> >We (the authors of the ID) agreed with Dimitri that CP->MP is not a
> >must and I have no problem to move it to should/shall/may state.
> >
> >[...]
> >However the focus of the ID is on MP->CP handover and if the
> community
> >is strongly against of CP->MP even in the form of a should/shall/may
> >requirement we can strip this out.
> >
> >Regards
> >
> >Diego
>
>
>

Delivery-date: Thu, 24 Aug 2006 14:50:33 +0000
Content-class: urn:content-classes:message
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Date: Thu, 24 Aug 2006 10:48:48 -0400
From: "Don Fedyk" <[email-masked]>
To: "Lou Berger" <[email-masked]>, "Diego Caviglia" <[email-masked]>
Cc: <[email-masked]>

Lou and Diego, all

Two points.=20

If we were to ask could you live without the CP->MP feature what
response would we get versus asking if CP->MP is a soft requirement.

The other point that baffles me is there is not one "standard" MP that
I'm aware of so really we are talking many variations of MP to a
standard CP. So how do you define a CP to variations of MPs? The
document currently oversimplifies this aspect IMHO.

Thanks,
Don

> -----Original Message-----
>=20
> Diego,
>          In my experience in talking about this feature with=20
> carriers is that some (but not all) will require such=20
> symmetric behavior.  I think the other rational for this=20
> feature are irrelevant.  Again, the sole reason I've seen for=20
> this requirement is that to deploy MP->CP some will require=20
> that there be support for CP->MP.
>=20
> I therefore think the definition of CP->MP *is* required. =20
> There are multiple options for meeting this requirement, but=20
> the solution must provide the "fallback" capability for=20
> services existing at the time of the initial MP->CP=20
> transition and those created after the transition.
>=20
> I think a SHOULD level requirement is sufficient for this=20
> capability, but I'd be interested if those representing=20
> carries on the list differ.
>=20
> Lou
>=20
> At 03:09 AM 8/24/2006, Diego Caviglia wrote:
>=20
>=20
> >In my mind the CP->MP feature can be useful for mainly two purposes:
> >1)    symmetricity with the companion feature (MP->CP)
> >[...]
> >
> >We (the authors of the ID) agreed with Dimitri that CP->MP is not a=20
> >must and I have no problem to move it to should/shall/may state.
> >
> >[...]
> >However the focus of the ID is on MP->CP handover and if the=20
> community=20
> >is strongly against of CP->MP even in the form of a should/shall/may=20
> >requirement we can strip this out.
> >
> >Regards
> >
> >Diego
>=20
>=20
>=20

Delivery-date: Thu, 24 Aug 2006 13:30:09 +0000
Date: Thu, 24 Aug 2006 09:29:01 -0400
From: Dan Li <[email-masked]>
Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,
To: [email-masked]
Cc: ccamp <[email-masked]>, MEURIC Julien RD-CORE-LAN <[email-masked]>, [email-masked], [email-masked], "Zafar Ali (zali)" <[email-masked]>

Hi Dimitri,

see in line.

-Dan

----- Original Message ----- 
From: <[email-masked]>
To: "Dan Li" <[email-masked]>
Cc: "ccamp" <[email-masked]>; "MEURIC Julien RD-CORE-LAN" 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>; "Zafar Ali (zali)" <[email-masked]>
Sent: Thursday, August 24, 2006 3:57 AM
Subject: Re: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,

> hi -
>
> [dan] In optical transport networks, the control plane failure should not
> affect the traffic carried by the transport plane. So usually the
> cross-connect
> in the transport plane will not be removed when there is a failure in the
> control
> plane, that's why I stated the problem described in this I-D is real.
>
> [dimitri] I think this has been worked out (see RFC 3473, and related)
> such as to prevent drawbacks of releasing resources while there is known
> period during which states can be re-build (using neighbors as helpers)
>

[dan] Sorry, maybe I didn't make it clear. What I mean was during the LSP
deletion procedure, if one node just happen to be restarted when it receives 
the
message to release the transport resource. This situation results in the 
inconsistent
data channel status because of the large timer setting. Before the large 
timer
to be expired, we can not use the inconsistent data channel.

[dan] In order to ensure that the traffic carried by the transport plane is 
not
affected due to the control plane failure, we have to set a large timer. But
on the other hand, when we really want to release the transport resource,
we hope the timer is small enough to ensure the resource can be released
as soon as possible when there is a problem on the control plane.

> [dimitri] The concern is if parameters are set such as to make behavior
> being equivalent to a hard state protocol the proposal you made is solving
> a corner case from a mis-use of the protocol mechanisms we have at hand
>
> [dimitri] I understand from Adrian's reply that the case we're dealing
> with is due restart/recovery timers that are set such as to support large
> period of CP outage - where one can not rely on cleanup
>
> [dimitri] I can accept this is a consequence of setting existing
> parameters - but my answer to this is "ok but why shall we have LMP
> intervening in this process if the operator wants to wait for very large
> periods" ... this leads to the (partial) conclusion that i can assume
> their can be cases where the data plane itself may introduce an
> inconsistency (would be interesting to have the viewpoint of "optical
> hardware expert" here) but i don't see how we can have cases where the
> control plane if correctly used and configured can be the instigator of
> such cases
>
> [dimitri] concerning the detection, the issue resulting from this is that
> the "available" side should - per 4204 - start an LMP verification ...
> pointing to 4204 "Therefore, to ensure proper verification of data link
> connectivity, it is required that, until the data links are allocated for
> user traffic, they must be opaque (i.e., lose their transparency).  To
> support various degrees of opaqueness (e.g., examining overhead bytes,
> terminating the IP payload, etc.) and, hence, different mechanisms to
> transport the Test messages, a Verify Transport Mechanism field is
> included in the BeginVerify and BeginVerifyAck messages." which result in
> "when data links are de-allocated" they should re-enter that state ... the
> issue is that the BeginVerify does not exchange DATA LINK but LINK objects
> (there is no flags in the former) hence the only reply you would receive
> is "unwilling to verify" while ideally you should receive "unwilling to
> verify (allocated)" such as the other side can map it with local knowledge
> and detect the mismatch
>

[dan] This solution you have suggested sounds very interesting, I will look 
at it.

>
> -d.
>
>
>
>
>
>
> Dan Li <[email-masked]>
> 24/08/2006 08:29
>
>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>        cc:     ccamp <[email-masked]>, MEURIC Julien RD-CORE-LAN
> <[email-masked]>, [email-masked],
> [email-masked], "Zafar Ali (zali)" <[email-masked]>
>        Subject:        Re: High level comment on
> draft-li-ccamp-confirm-data-channel-status-00.txt,
>
>
> Hi Dimitri,
>
> Please see in-line.
>
> Regards,
>
> Dan
>
> ----- Original Message ----- 
> From: <[email-masked]>
> To: "Dan Li" <[email-masked]>
> Cc: "ccamp" <[email-masked]>; "MEURIC Julien RD-CORE-LAN"
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>; "Zafar Ali (zali)" <[email-masked]>
> Sent: Wednesday, August 23, 2006 8:45 PM
> Subject: Re: High level comment on
> draft-li-ccamp-confirm-data-channel-status-00.txt,
>
>
>> just a brief remark
>>
>> i don't see why channel status verification can not be achieved with
>> current mechanism described in section 12.7 of 4204 (and there is a
>> need to come with a complete set of messages for this purpose)
>>
>
> [dan] I agree that the LMP messages (17, 18, 19) can do the channel status
> verification with some extensions. My concern is that these messages are
> used for the fault management, but the inconsistent data channel status
> may
> be is not a failure, for example it may be configured on purpose.
>
>
>> now i am even unclear how the problem you stated can occur
>>
>> "The channel status of a data link may become mismatched during the
>>    LSP deletion process. If the LSP deletion process is aborted in the
>>    middle of the process (perhaps because of a temporary control plane
>>    failure), the cross-connection at the upstream node may be removed
>>    while the downstream node still keeps its cross-connection."
>>
>> why do you think the notion of soft-state has been introduced ? once
>> the cleanup timeout (set to K times the refresh timeout) interval is
>> reached that then triggers a tear-down
>>
>
> [dan] In optical transport networks, the control plane failure should not
> affect the traffic carried by the transport plane. So usually the
> cross-connect
> in the transport plane will not be removed when there is a failure in the
> control
> plane, that's why I stated the problem described in this I-D is real.
>
>
>> thanks,
>> - d.
>>
>>
>>
>>
>>
>>
>> Dan Li <[email-masked]>
>> Sent by: [email-masked]
>> 23/08/2006 09:55
>>
>>         To:     [email-masked], "Zafar Ali (zali)"
> <[email-masked]>,
>> MEURIC Julien RD-CORE-LAN <[email-masked]>
>>         cc:     ccamp <[email-masked]>
>>         Subject:        Re: High level comment on
>> draft-li-ccamp-confirm-data-channel-status-00.txt,
>>
>>
>> Hi,
>>
>> Thanks Julien and Zafar for your comments. I agree with Julien. This I-D
>
>> just wants to provide a control plane tool to detect the inconsistent
> data
>> channel status in the tranport plane.
>>
>> Actually I have received several private emails think this I-D addresses
> a
>> real problem, but regarding the new LMP messages which are introduced in
>
>> this I-D, some people pointed out that the already deployed
> channelstatus
>> messages (id = 17, 18, 19 and 20) may be extended to carry also the
>> timeslot information instead only data link. But I have a concern that
> the
>> Fault Management Messages usually are triggered by fault detection,
> these
>> messages should not be sent if no fault is detected. The confirmation of
>
>> data channel status may need to be performed periodically or triggerd by
>
>> user.
>>
>> I would like to hear from you guys, what's your comments? Not only the
>> concerns raised above, but also other issues in this I-D.
>>
>> Regards,
>>
>> Dan
>>
>> ----- Original Message ----- 
>> From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
>> To: "Zafar Ali (zali)" <[email-masked]>; <[email-masked]>;
>> <[email-masked]>
>> Cc: "ccamp" <[email-masked]>
>> Sent: Tuesday, July 11, 2006 2:31 AM
>> Subject: RE: High level comment on
>> draft-li-ccamp-confirm-data-channel-status-00.txt,
>>
>>
>> Hi Zafar.
>>
>> I don't really get you on this. I figure out you're referring to
>> removing the connection states when RSVP refreshes are not received any
>> more, aren't you? If so, I'm afraid this is not enough for transmission
>> devices, where resources can be physically cross-connected even though
>> there is no (or no longer) corresponding RSVP state. Therefore having a
>> mechanism to avoid such discrepancies would be welcome.
>>
>> Regards,
>>
>> Julien
>>
>>
>> P.S.: If you totally rely on a management plane, I agree this should be
>> useless (e.g. the NMS should already know if a cross-connection deletion
>> failed, cf. Diego's 2nd slides seen this morning).
>>
>> ________________________________
>>
>>
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Zafar Ali (zali)
>>
>> Dear Authors,
>>
>> RSVP refreshes do this job, so I am not sure motivation for this draft/
>> LMP extensions.
>>
>> n.b. The draft state, "Although such a situation can be resolved through
>> the use of the Acceptable Label Set object in GMPLS signaling [RFC3473],
>> such a procedure is inefficient since it may require an additional
>> signaling exchange for each LSP that is set up", so I assume that RSVP
>> signaling is present (Although I did not understand the quoted statement
>> from the ID). Even if RSVP is not present, e.g., optical core is
>> completely controlled by a management entity, I would argue introduce
>> presence of LMP.
>>
>> Thanks
>>
>> Regards... Zafar
>>
>>
>>
>>
>
>
> 

Delivery-date: Thu, 24 Aug 2006 12:17:03 +0000
Date: Thu, 24 Aug 2006 08:15:50 -0400
To: "Diego Caviglia" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: CP-->MP Issue (was RE: Polling for new WG I-Ds)
Cc: [email-masked]

Diego,
         In my experience in talking about this feature with carriers 
is that some (but not all) will require such symmetric behavior.  I 
think the other rational for this feature are irrelevant.  Again, the 
sole reason I've seen for this requirement is that to deploy MP->CP 
some will require that there be support for CP->MP.

I therefore think the definition of CP->MP *is* required.  There are 
multiple options for meeting this requirement, but the solution must 
provide the "fallback" capability for services existing at the time 
of the initial MP->CP transition and those created after the transition.

I think a SHOULD level requirement is sufficient for this capability, 
but I'd be interested if those representing carries on the list differ.

Lou

At 03:09 AM 8/24/2006, Diego Caviglia wrote:

>In my mind the CP->MP feature can be useful for mainly two purposes:
>1)    symmetricity with the companion feature (MP->CP)
>[...]
>
>We (the authors of the ID) agreed with Dimitri that CP->MP is not a must
>and I have no problem to move it to should/shall/may state.
>
>[...]
>However the focus of the ID is on MP->CP handover and if the community is
>strongly against of CP->MP even in the form of a should/shall/may
>requirement we can strip this out.
>
>Regards
>
>Diego

Delivery-date: Thu, 24 Aug 2006 09:55:24 +0000
Sensitivity: 
Subject: Re: CP-->MP Issue (was RE: Polling for new WG I-Ds)
To: "Dimitri.Papadimitriou" <[email-masked]>
Cc: "ccamp" <[email-masked]>, "owner-ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Thu, 24 Aug 2006 11:53:36 +0200

Dimitri,
         it depends if you use the parachute before the plane explode :-))

More seriously do you still have problems with the procedure if we move it
to a should/shall/may state?  I think that this would be enough for who
think is a good feture and wants to implement it and do not 'force' anyone
that disagree to implement it.

Regards

Diego

[email-masked] on 24/08/2006 10.18.28

To:    "Diego Caviglia" <[email-masked]>
cc:    [email-masked], [email-masked]

Subject:    Re: CP-->MP Issue (was RE: Polling for new WG I-Ds)

diego -

using your metaphore - if the plane explodes/crashes you can have the
nicer parachute it won't be of great help - meaning it is clear that is
not this process/parachute that is going to increase confidence in CP if
the problem is more fundamental and in part. not technical
(confidence/trust/etc.)

ps: operations are NOT symmetric (if you mean reflective since CP =/=
distributed MP)

"Diego Caviglia" <[email-masked]>
Sent by: [email-masked]
24/08/2006 09:09

        To:     [email-masked]
        cc:
        Subject:        CP-->MP Issue (was RE: Polling for new WG I-Ds)

In my mind the CP->MP feature can be useful for mainly two purposes:
1)    symmetricity with the companion feature (MP->CP)
2)    a sort of "parachute" in case something went wrong with the CP (Igor
made an example on this but another one could a foreseen problem with the
      signalling network, or may be the CP is not running well and its
restoration time are not in line with the expectation, or there is a merge
of    two different networks organizations and the resulting one is not
going to use -may be only at initial stage of merging process- the CP,
...)

We (the authors of the ID) agreed with Dimitri that CP->MP is not a must
and I have no problem to move it to should/shall/may state.

Is this in the scope of CCAMP? I think it is because is CP related and
imho
having such parachute can increase the confidence of carriers in CP.  I
mean I prefer to take a plane if I know I have a parachute on board.

However the focus of the ID is on MP->CP handover and if the community is
strongly against of CP->MP even in the form of a should/shall/may
requirement we can strip this out.

Regards

Diego

Delivery-date: Thu, 24 Aug 2006 09:35:10 +0000
Content-class: urn:content-classes:message
Subject: RE: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas
Date: Thu, 24 Aug 2006 10:33:13 +0100
From: "Trevor Wilson" <[email-masked]>
To: "Huub van Helvoort" <[email-masked]>
Cc: <[email-masked]>

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:[email-masked]]=20
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,

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 ?
>=20
> [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 =3D non-LCAS-capable and
> Dynamic =3D 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
>=20
> [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.
>=20
> [hvh] how do you provision/achieve a signal degrade?
> [tw]	G.806 clause 10.1.1.2 shows "P-Xv_AI_TSD =3D 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",=20
> and the text says "The MI_TSDEnable input controls whether the sink=20
> function uses AI_TSD[i] indications as contributors for signalling=20
> defective members back to the LCAS source function (MI_TSDEnable =3D=20
> true) or whether it ignores AI_TSD[i] indications altogether=20
> (MI_TSDEnable =3D 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.   =20

>> Dynamic, diversely routed: A dynamic VCAT group, transported over at=20
>> least two diversely routed subsets of member signals.  The intent=20
>> here is dynamic resizing and resilience (but differential delay may=20
>> be a limiting factor). Graceful degradation is possible in the event=20
>> of a TSD (Trail Signal Degrade) on a VCG
>> member(s)
>=20
> [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.
>=20
> [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: -
>=20
> 4.1.3		Permanent removal of a VCG member
>=20
> 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=20
> management command. The LCAS in-band signaling step is taken first to=20
> take the component out of the group, either the temporary removal or=20
> as the result of a management command.

[hvh2] good suggestion

>> This permanent removal procedure is only applicable to=20
>> LCAS-capable-VCAT.
>=20
> [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. =09

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

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

Delivery-date: Thu, 24 Aug 2006 08:18:52 +0000
To: "Diego Caviglia" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: CP-->MP Issue (was RE: Polling for new WG I-Ds)
From: [email-masked]
Date: Thu, 24 Aug 2006 10:18:28 +0200

diego -

using your metaphore - if the plane explodes/crashes you can have the 
nicer parachute it won't be of great help - meaning it is clear that is 
not this process/parachute that is going to increase confidence in CP if 
the problem is more fundamental and in part. not technical 
(confidence/trust/etc.)

ps: operations are NOT symmetric (if you mean reflective since CP =/= 
distributed MP)

"Diego Caviglia" <[email-masked]>
Sent by: [email-masked]
24/08/2006 09:09
 
        To:     [email-masked]
        cc: 
        Subject:        CP-->MP Issue (was RE: Polling for new WG I-Ds)

In my mind the CP->MP feature can be useful for mainly two purposes:
1)    symmetricity with the companion feature (MP->CP)
2)    a sort of "parachute" in case something went wrong with the CP (Igor
made an example on this but another one could a foreseen problem with the
      signalling network, or may be the CP is not running well and its
restoration time are not in line with the expectation, or there is a merge
of    two different networks organizations and the resulting one is not
going to use -may be only at initial stage of merging process- the CP, 
...)

We (the authors of the ID) agreed with Dimitri that CP->MP is not a must
and I have no problem to move it to should/shall/may state.

Is this in the scope of CCAMP? I think it is because is CP related and 
imho
having such parachute can increase the confidence of carriers in CP.  I
mean I prefer to take a plane if I know I have a parachute on board.

However the focus of the ID is on MP->CP handover and if the community is
strongly against of CP->MP even in the form of a should/shall/may
requirement we can strip this out.

Regards

Diego

Delivery-date: Thu, 24 Aug 2006 07:58:23 +0000
To: Dan Li <[email-masked]>
Cc: ccamp <[email-masked]>, MEURIC Julien RD-CORE-LAN <[email-masked]>, [email-masked], [email-masked], "Zafar Ali (zali)" <[email-masked]>
Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,
From: [email-masked]
Date: Thu, 24 Aug 2006 09:57:17 +0200

hi -

[dan] In optical transport networks, the control plane failure should not
affect the traffic carried by the transport plane. So usually the 
cross-connect
in the transport plane will not be removed when there is a failure in the 
control
plane, that's why I stated the problem described in this I-D is real.

[dimitri] I think this has been worked out (see RFC 3473, and related) 
such as to prevent drawbacks of releasing resources while there is known 
period during which states can be re-build (using neighbors as helpers)

[dimitri] The concern is if parameters are set such as to make behavior 
being equivalent to a hard state protocol the proposal you made is solving 
a corner case from a mis-use of the protocol mechanisms we have at hand

[dimitri] I understand from Adrian's reply that the case we're dealing 
with is due restart/recovery timers that are set such as to support large 
period of CP outage - where one can not rely on cleanup

[dimitri] I can accept this is a consequence of setting existing 
parameters - but my answer to this is "ok but why shall we have LMP 
intervening in this process if the operator wants to wait for very large 
periods" ... this leads to the (partial) conclusion that i can assume 
their can be cases where the data plane itself may introduce an 
inconsistency (would be interesting to have the viewpoint of "optical 
hardware expert" here) but i don't see how we can have cases where the 
control plane if correctly used and configured can be the instigator of 
such cases 

[dimitri] concerning the detection, the issue resulting from this is that 
the "available" side should - per 4204 - start an LMP verification ... 
pointing to 4204 "Therefore, to ensure proper verification of data link 
connectivity, it is required that, until the data links are allocated for 
user traffic, they must be opaque (i.e., lose their transparency).  To 
support various degrees of opaqueness (e.g., examining overhead bytes, 
terminating the IP payload, etc.) and, hence, different mechanisms to 
transport the Test messages, a Verify Transport Mechanism field is 
included in the BeginVerify and BeginVerifyAck messages." which result in 
"when data links are de-allocated" they should re-enter that state ... the 
issue is that the BeginVerify does not exchange DATA LINK but LINK objects 
(there is no flags in the former) hence the only reply you would receive 
is "unwilling to verify" while ideally you should receive "unwilling to 
verify (allocated)" such as the other side can map it with local knowledge 
and detect the mismatch

-d.

Dan Li <[email-masked]>
24/08/2006 08:29
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     ccamp <[email-masked]>, MEURIC Julien RD-CORE-LAN 
<[email-masked]>, [email-masked], 
[email-masked], "Zafar Ali (zali)" <[email-masked]>
        Subject:        Re: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,

Hi Dimitri,

Please see in-line.

Regards,

Dan

----- Original Message ----- 
From: <[email-masked]>
To: "Dan Li" <[email-masked]>
Cc: "ccamp" <[email-masked]>; "MEURIC Julien RD-CORE-LAN" 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>; "Zafar Ali (zali)" <[email-masked]>
Sent: Wednesday, August 23, 2006 8:45 PM
Subject: Re: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,

> just a brief remark
> 
> i don't see why channel status verification can not be achieved with 
> current mechanism described in section 12.7 of 4204 (and there is a
> need to come with a complete set of messages for this purpose)
> 

[dan] I agree that the LMP messages (17, 18, 19) can do the channel status
verification with some extensions. My concern is that these messages are
used for the fault management, but the inconsistent data channel status 
may
be is not a failure, for example it may be configured on purpose. 

> now i am even unclear how the problem you stated can occur
> 
> "The channel status of a data link may become mismatched during the 
>    LSP deletion process. If the LSP deletion process is aborted in the 
>    middle of the process (perhaps because of a temporary control plane 
>    failure), the cross-connection at the upstream node may be removed 
>    while the downstream node still keeps its cross-connection."
> 
> why do you think the notion of soft-state has been introduced ? once
> the cleanup timeout (set to K times the refresh timeout) interval is
> reached that then triggers a tear-down
> 

[dan] In optical transport networks, the control plane failure should not
affect the traffic carried by the transport plane. So usually the 
cross-connect
in the transport plane will not be removed when there is a failure in the 
control
plane, that's why I stated the problem described in this I-D is real.

> thanks,
> - d.
> 
> 
> 
> 
> 
> 
> Dan Li <[email-masked]>
> Sent by: [email-masked]
> 23/08/2006 09:55
> 
>         To:     [email-masked], "Zafar Ali (zali)" 
<[email-masked]>, 
> MEURIC Julien RD-CORE-LAN <[email-masked]>
>         cc:     ccamp <[email-masked]>
>         Subject:        Re: High level comment on 
> draft-li-ccamp-confirm-data-channel-status-00.txt,
> 
> 
> Hi,
> 
> Thanks Julien and Zafar for your comments. I agree with Julien. This I-D 

> just wants to provide a control plane tool to detect the inconsistent 
data 
> channel status in the tranport plane.
> 
> Actually I have received several private emails think this I-D addresses 
a 
> real problem, but regarding the new LMP messages which are introduced in 

> this I-D, some people pointed out that the already deployed 
channelstatus 
> messages (id = 17, 18, 19 and 20) may be extended to carry also the 
> timeslot information instead only data link. But I have a concern that 
the 
> Fault Management Messages usually are triggered by fault detection, 
these 
> messages should not be sent if no fault is detected. The confirmation of 

> data channel status may need to be performed periodically or triggerd by 

> user.
> 
> I would like to hear from you guys, what's your comments? Not only the 
> concerns raised above, but also other issues in this I-D.
> 
> Regards,
> 
> Dan
> 
> ----- Original Message ----- 
> From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
> To: "Zafar Ali (zali)" <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> Cc: "ccamp" <[email-masked]>
> Sent: Tuesday, July 11, 2006 2:31 AM
> Subject: RE: High level comment on 
> draft-li-ccamp-confirm-data-channel-status-00.txt,
> 
> 
> Hi Zafar.
> 
> I don't really get you on this. I figure out you're referring to
> removing the connection states when RSVP refreshes are not received any
> more, aren't you? If so, I'm afraid this is not enough for transmission
> devices, where resources can be physically cross-connected even though
> there is no (or no longer) corresponding RSVP state. Therefore having a
> mechanism to avoid such discrepancies would be welcome.
> 
> Regards,
> 
> Julien
> 
> 
> P.S.: If you totally rely on a management plane, I agree this should be
> useless (e.g. the NMS should already know if a cross-connection deletion
> failed, cf. Diego's 2nd slides seen this morning).
> 
> ________________________________
> 
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Zafar Ali (zali)
> 
> Dear Authors, 
> 
> RSVP refreshes do this job, so I am not sure motivation for this draft/
> LMP extensions. 
> 
> n.b. The draft state, "Although such a situation can be resolved through
> the use of the Acceptable Label Set object in GMPLS signaling [RFC3473],
> such a procedure is inefficient since it may require an additional
> signaling exchange for each LSP that is set up", so I assume that RSVP
> signaling is present (Although I did not understand the quoted statement
> from the ID). Even if RSVP is not present, e.g., optical core is
> completely controlled by a management entity, I would argue introduce
> presence of LMP. 
> 
> Thanks
> 
> Regards... Zafar 
> 
> 
> 
> 

Delivery-date: Thu, 24 Aug 2006 07:11:16 +0000
Sensitivity: 
Subject: CP-->MP Issue (was RE: Polling for new WG I-Ds)
To: [email-masked]
From: "Diego Caviglia" <[email-masked]>
Date: Thu, 24 Aug 2006 09:09:15 +0200

In my mind the CP->MP feature can be useful for mainly two purposes:
1)    symmetricity with the companion feature (MP->CP)
2)    a sort of "parachute" in case something went wrong with the CP (Igor
made an example on this but another one could a foreseen problem with the
      signalling network, or may be the CP is not running well and its
restoration time are not in line with the expectation, or there is a merge
of    two different networks organizations and the resulting one is not
going to use -may be only at initial stage of merging process- the CP, ...)

We (the authors of the ID) agreed with Dimitri that CP->MP is not a must
and I have no problem to move it to should/shall/may state.

Is this in the scope of CCAMP? I think it is because is CP related and imho
having such parachute can increase the confidence of carriers in CP.  I
mean I prefer to take a plane if I know I have a parachute on board.

However the focus of the ID is on MP->CP handover and if the community is
strongly against of CP->MP even in the form of a should/shall/may
requirement we can strip this out.

Regards

Diego

Delivery-date: Thu, 24 Aug 2006 06:33:30 +0000
Date: Thu, 24 Aug 2006 14:29:47 +0800
From: Dan Li <[email-masked]>
Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,
To: [email-masked]
Cc: ccamp <[email-masked]>, MEURIC Julien RD-CORE-LAN <[email-masked]>, [email-masked], [email-masked], "Zafar Ali (zali)" <[email-masked]>

Hi Dimitri,

Please see in-line.

Regards,

Dan

----- Original Message ----- 
From: <[email-masked]>
To: "Dan Li" <[email-masked]>
Cc: "ccamp" <[email-masked]>; "MEURIC Julien RD-CORE-LAN" <[email-masked]>; <[email-masked]>; <[email-masked]>; "Zafar Ali (zali)" <[email-masked]>
Sent: Wednesday, August 23, 2006 8:45 PM
Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,

> just a brief remark
> 
> i don't see why channel status verification can not be achieved with 
> current mechanism described in section 12.7 of 4204 (and there is a
> need to come with a complete set of messages for this purpose)
> 

[dan] I agree that the LMP messages (17, 18, 19) can do the channel status
verification with some extensions. My concern is that these messages are
used for the fault management, but the inconsistent data channel status may
be is not a failure, for example it may be configured on purpose. 

> now i am even unclear how the problem you stated can occur
> 
> "The channel status of a data link may become mismatched during the 
>    LSP deletion process. If the LSP deletion process is aborted in the 
>    middle of the process (perhaps because of a temporary control plane 
>    failure), the cross-connection at the upstream node may be removed 
>    while the downstream node still keeps its cross-connection."
> 
> why do you think the notion of soft-state has been introduced ? once
> the cleanup timeout (set to K times the refresh timeout) interval is
> reached that then triggers a tear-down
> 

[dan] In optical transport networks, the control plane failure should not
affect the traffic carried by the transport plane. So usually the cross-connect
in the transport plane will not be removed when there is a failure in the control
plane, that's why I stated the problem described in this I-D is real.

> thanks,
> - d.
> 
> 
> 
> 
> 
> 
> Dan Li <[email-masked]>
> Sent by: [email-masked]
> 23/08/2006 09:55
>  
>         To:     [email-masked], "Zafar Ali (zali)" <[email-masked]>, 
> MEURIC Julien RD-CORE-LAN <[email-masked]>
>         cc:     ccamp <[email-masked]>
>         Subject:        Re: High level comment on 
> draft-li-ccamp-confirm-data-channel-status-00.txt,
> 
> 
> Hi,
> 
> Thanks Julien and Zafar for your comments. I agree with Julien. This I-D 
> just wants to provide a control plane tool to detect the inconsistent data 
> channel status in the tranport plane.
> 
> Actually I have received several private emails think this I-D addresses a 
> real problem, but regarding the new LMP messages which are introduced in 
> this I-D, some people pointed out that the already deployed channelstatus 
> messages (id = 17, 18, 19 and 20) may be extended to carry also the 
> timeslot information instead only data link. But I have a concern that the 
> Fault Management Messages usually are triggered by fault detection, these 
> messages should not be sent if no fault is detected. The confirmation of 
> data channel status may need to be performed periodically or triggerd by 
> user.
> 
> I would like to hear from you guys, what's your comments? Not only the 
> concerns raised above, but also other issues in this I-D.
> 
> Regards,
> 
> Dan
> 
> ----- Original Message ----- 
> From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
> To: "Zafar Ali (zali)" <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> Cc: "ccamp" <[email-masked]>
> Sent: Tuesday, July 11, 2006 2:31 AM
> Subject: RE: High level comment on 
> draft-li-ccamp-confirm-data-channel-status-00.txt,
> 
> 
> Hi Zafar.
> 
> I don't really get you on this. I figure out you're referring to
> removing the connection states when RSVP refreshes are not received any
> more, aren't you? If so, I'm afraid this is not enough for transmission
> devices, where resources can be physically cross-connected even though
> there is no (or no longer) corresponding RSVP state. Therefore having a
> mechanism to avoid such discrepancies would be welcome.
> 
> Regards,
> 
> Julien
> 
> 
> P.S.: If you totally rely on a management plane, I agree this should be
> useless (e.g. the NMS should already know if a cross-connection deletion
> failed, cf. Diego's 2nd slides seen this morning).
> 
> ________________________________
> 
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Zafar Ali (zali)
> 
> Dear Authors, 
>  
> RSVP refreshes do this job, so I am not sure motivation for this draft/
> LMP extensions. 
>  
> n.b. The draft state, "Although such a situation can be resolved through
> the use of the Acceptable Label Set object in GMPLS signaling [RFC3473],
> such a procedure is inefficient since it may require an additional
> signaling exchange for each LSP that is set up", so I assume that RSVP
> signaling is present (Although I did not understand the quoted statement
> from the ID). Even if RSVP is not present, e.g., optical core is
> completely controlled by a management entity, I would argue introduce
> presence of LMP. 
>  
> Thanks
>  
> Regards... Zafar 
> 
> 
> 
> 

Delivery-date: Wed, 23 Aug 2006 23:26:46 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 16:24:27 -0700
From: "Drake, John E" <[email-masked]>
To: "Bryskin, Igor" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

>=20
> JD: This means reverting to the previous version of control
> plane software, not the CP->MP->CP detour.
>=20
> IB>> I am talking about the situation when simple reverting is not
> IB>> possible due to incompatibility of the new and old software=20
> IB>> releases.

JD:  This is the first time you have mentioned that you are assuming
that this reversion is not possible.  I think this is total nonsense for
two reasons.  1) I don't believe technically that this reversion would
ever *not* be possible.  Otherwise, I don't see how the new software
could have been incrementally deployed in the first place.  2) The
operator would never deploy  the new software unless had had verified
that it could be backed out. =20

IB>> Agree, I probably should have said *not feasible* instead of  *not=20
IB>> possible*. Imagine that the new CP was run for 1 month before the=20
IB>> problem was encountered. Using backup of old CP would mean loosing=20
IB>> all services that were provisioned within this period.

JD: Let me guess.  You are now making the further assumption that the
databases of the old and new CPs are completely incompatible.  As I
indicated above, if incremental deployment and incremental roll back are
not supported, the new CP will never be deployed.  It's not like there
is anything new here.

IB>> Likewise, if=20
IB>> one made the MP->CP move, worked for some time and then discovered=20
IB>> a problem, using old MP backups would mean loosing all services=20
IB>> that were dynamically created or modified.

JD:  What are you talking about?  We are discussing a CP update.

IB>> CP->MP move would solve=20
IB>> the problem.

JD: Completely unsupported assertion.

Further, why would new CP->MP->old CP work
when new CP->old CP would not work?

IB>> Because you can not perform new CP->old CP conversion=20
IB>> simultameously on all nodes.

JD:  You cannot perform new CP->MP conversion simultaneously on all
nodes either, and there is no reason to assume that simultaneous new
CP->old CP conversion is required.

Igor

>=20
> Furthermore, on more general note, if we decide that we need
> to be capable of doing MP->CP, just from the simmetricity=20
> point of view it makes a lot of sense to me to have CP->MP=20
> capability for debugging and testing the MP->CP move (if for=20
> nothing else)=20
>=20
> Igor
>=20
> >=20
> > Besides, what is the problem with moving "hundreds/thousands of LSPs

> > from CP->MP"?
> >=20
> > Igor
> >=20
> > -----Original Message-----
> > From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
> > Sent: Wednesday, August 23, 2006 11:43 AM
> > To: Drake, John E; Bryskin, Igor; Diego Caviglia;=20
> > Dimitri.Papadimitriou
> > Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian
> > Farrel <adrian; danli
> > Subject: RE: Polling for new WG I-Ds
> >=20
> >=20
> > Agree with John, and control plane failures don't (should not/hope=20
> > not) impact the data plane state. And before doing such a sw=20
> > upgrade, I would not want to have to move hundreds/thousands of LSPs

> > from CP->MP.
> >=20
> > I'm not sure myself on what is meant by CP->MP, need to
> discuss more.
> >=20
> > (chair hat off)
> > Deborah
> >=20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On=20
> > Behalf Of Drake, John E
> > Sent: Wednesday, August 23, 2006 11:13 AM
> > To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
> > Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian
> > Farrel <adrian; danli
> > Subject: RE: Polling for new WG I-Ds
> >=20
> > Snipped
> >=20
> > >=20
> > > Besides I can see at least one quite real application for
> > > CP->MP. Imagine that an operator wants to perform some major
> > > software upgrade with a new software version significantly
> > > incompatible with the previous one.
> >=20
> > JD:  Except that we go to great pains to ensure that this situation=20
> > never occurs.
> >=20
> >=20
> >=20
>=20

Delivery-date: Wed, 23 Aug 2006 21:20:53 +0000
content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 17:06:31 -0400
From: "Bryskin, Igor" <[email-masked]>
To: "Drake, John E" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

>=20
> JD: This means reverting to the previous version of control=20
> plane software, not the CP->MP->CP detour.
>=20
> IB>> I am talking about the situation when simple reverting is not=20
> IB>> possible due to incompatibility of the new and old software=20
> IB>> releases.

JD:  This is the first time you have mentioned that you are assuming
that this reversion is not possible.  I think this is total nonsense for
two reasons.  1) I don't believe technically that this reversion would
ever *not* be possible.  Otherwise, I don't see how the new software
could have been incrementally deployed in the first place.  2) The
operator would never deploy  the new software unless had had verified
that it could be backed out. =20

IB>> Agree, I probably should have said *not feasible* instead of  *not =
possible*. Imagine that the new CP was run for 1 month before the =
problem was encountered. Using backup of old CP would mean loosing all =
services that were provisioned within this period. Likewise, if one made =
the MP->CP move, worked for some time and then discovered a problem, =
using old MP backups would mean loosing all services that were =
dynamically created or modified. CP->MP move would solve the problem.

Further, why would new CP->MP->old CP work
when new CP->old CP would not work?

IB>> Because you can not perform new CP->old CP conversion =
simultameously on all nodes.

Igor

>=20
> Furthermore, on more general note, if we decide that we need=20
> to be capable of doing MP->CP, just from the simmetricity=20
> point of view it makes a lot of sense to me to have CP->MP=20
> capability for debugging and testing the MP->CP move (if for=20
> nothing else)=20
>=20
> Igor
>=20
> >=20
> > Besides, what is the problem with moving "hundreds/thousands
> > of LSPs from CP->MP"?=20
> >=20
> > Igor
> >=20
> > -----Original Message-----
> > From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
> > Sent: Wednesday, August 23, 2006 11:43 AM
> > To: Drake, John E; Bryskin, Igor; Diego Caviglia;
> > Dimitri.Papadimitriou
> > Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian=20
> > Farrel <adrian; danli
> > Subject: RE: Polling for new WG I-Ds
> >=20
> >=20
> > Agree with John, and control plane failures don't (should
> > not/hope not) impact the data plane state. And before doing=20
> > such a sw upgrade, I would not want to have to move=20
> > hundreds/thousands of LSPs from CP->MP.
> >=20
> > I'm not sure myself on what is meant by CP->MP, need to=20
> discuss more.
> >=20
> > (chair hat off)
> > Deborah
> >=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Drake, John E
> > Sent: Wednesday, August 23, 2006 11:13 AM
> > To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
> > Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian=20
> > Farrel <adrian; danli
> > Subject: RE: Polling for new WG I-Ds
> >=20
> > Snipped
> >=20
> > >=20
> > > Besides I can see at least one quite real application for
> > > CP->MP. Imagine that an operator wants to perform some major
> > > software upgrade with a new software version significantly=20
> > > incompatible with the previous one.
> >=20
> > JD:  Except that we go to great pains to ensure that this
> > situation never occurs.=20
> >=20
> >=20
> >=20
>=20

Delivery-date: Wed, 23 Aug 2006 19:52:44 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 12:50:15 -0700
From: "Drake, John E" <[email-masked]>
To: "Bryskin, Igor" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

>=20
> > > Furthermore, sometimes there is a need to actually
> > > downgrade software, for instance, when one wants to add to=20
> > > the network some older equipment.
> >=20
> > Why would anyone want to do this, especially without
> > upgrading this equipments' software?
> >=20
> > IB>> Because the new software was developed on the=20
> assumption that it
> > IB>> will work on the new hardware. Your customer, on the=20
> other hand,=20
> > IB>> purchased your old equipment and you want to protect his=20
> > IB>> investment.
>=20
> This is not what you said initially.  You said 'add to=20
> the network some older equipment.'
>=20
> IB>> No, that's exactly what I meant. My customer purchased a ring of=20
> IB>> new devices with new software. The customer also happens to have=20
> IB>> several rings of older devices running older software.=20
> The customer=20
> IB>> wants to interconnect the new rings with old ones. The customer=20
> IB>> does not mind to downgrade the software on the new ring=20
> so that it=20
> IB>> will be compatible with other rings.

As I said previously, the situation you are describing above is *not*
the same as 'add to=20
the network some older equipment.'  What you are describing is adding
new equipment to an existing network, and there are many options for
doing this, but going from CP->MP is not one of them.  If the existing
equipment was deployed with an MP and you didn't want to upgrade it to
CP, you would just deploy the new equipment with MP from the beginning.
=20
>=20
> Igor
>=20

Delivery-date: Wed, 23 Aug 2006 19:40:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 12:39:19 -0700
From: "Drake, John E" <[email-masked]>
To: "Bryskin, Igor" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

>=20
> JD: This means reverting to the previous version of control=20
> plane software, not the CP->MP->CP detour.
>=20
> IB>> I am talking about the situation when simple reverting is not=20
> IB>> possible due to incompatibility of the new and old software=20
> IB>> releases.

JD:  This is the first time you have mentioned that you are assuming
that this reversion is not possible.  I think this is total nonsense for
two reasons.  1) I don't believe technically that this reversion would
ever *not* be possible.  Otherwise, I don't see how the new software
could have been incrementally deployed in the first place.  2) The
operator would never deploy  the new software unless had had verified
that it could be backed out.  Further, why would new CP->MP->old CP work
when new CP->old CP would not work?

>=20
> Furthermore, on more general note, if we decide that we need=20
> to be capable of doing MP->CP, just from the simmetricity=20
> point of view it makes a lot of sense to me to have CP->MP=20
> capability for debugging and testing the MP->CP move (if for=20
> nothing else)=20
>=20
> Igor
>=20
> >=20
> > Besides, what is the problem with moving "hundreds/thousands
> > of LSPs from CP->MP"?=20
> >=20
> > Igor
> >=20
> > -----Original Message-----
> > From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
> > Sent: Wednesday, August 23, 2006 11:43 AM
> > To: Drake, John E; Bryskin, Igor; Diego Caviglia;
> > Dimitri.Papadimitriou
> > Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian=20
> > Farrel <adrian; danli
> > Subject: RE: Polling for new WG I-Ds
> >=20
> >=20
> > Agree with John, and control plane failures don't (should
> > not/hope not) impact the data plane state. And before doing=20
> > such a sw upgrade, I would not want to have to move=20
> > hundreds/thousands of LSPs from CP->MP.
> >=20
> > I'm not sure myself on what is meant by CP->MP, need to=20
> discuss more.
> >=20
> > (chair hat off)
> > Deborah
> >=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Drake, John E
> > Sent: Wednesday, August 23, 2006 11:13 AM
> > To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
> > Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian=20
> > Farrel <adrian; danli
> > Subject: RE: Polling for new WG I-Ds
> >=20
> > Snipped
> >=20
> > >=20
> > > Besides I can see at least one quite real application for
> > > CP->MP. Imagine that an operator wants to perform some major
> > > software upgrade with a new software version significantly=20
> > > incompatible with the previous one.
> >=20
> > JD:  Except that we go to great pains to ensure that this
> > situation never occurs.=20
> >=20
> >=20
> >=20
>=20

Delivery-date: Wed, 23 Aug 2006 18:49:58 +0000
content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 14:48:31 -0400
From: "Bryskin, Igor" <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, "Drake, John E" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

Deborah,

Have you been in a situation when you just performed a software upgrade
and a network operator tells you that your new release sucks and he
wants the network in the state of this morning prior to the upgrade? No?
Than you are lucky.

Db> that is totally different from this discussion, hopefully they know
what a backup is (for your benefit), and also one does not necessarily
want to use the backup since there could have been changes in the
network since the backup was made, unless the network is static;-)=20

IB>> Exactly my point. If you can not or don't wnat to use backup, what =
is the way out of this mess?

Igor

Would
stongly suggest you (and the operator) have done sufficient testin

Besides, what is the problem with moving "hundreds/thousands of LSPs
from CP->MP"?=20
Db> Good joke;-)

Igor

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Wednesday, August 23, 2006 11:43 AM
To: Drake, John E; Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian Farrel
<adrian; danli
Subject: RE: Polling for new WG I-Ds

Agree with John, and control plane failures don't (should not/hope not)
impact the data plane state. And before doing such a sw upgrade, I would
not want to have to move hundreds/thousands of LSPs from CP->MP.

I'm not sure myself on what is meant by CP->MP, need to discuss more.

(chair hat off)
Deborah=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Drake, John E
Sent: Wednesday, August 23, 2006 11:13 AM
To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian Farrel
<adrian; danli
Subject: RE: Polling for new WG I-Ds

Snipped

>=20
> Besides I can see at least one quite real application for=20
> CP->MP. Imagine that an operator wants to perform some major=20
> software upgrade with a new software version significantly=20
> incompatible with the previous one.

JD:  Except that we go to great pains to ensure that this situation
never occurs.=20

Delivery-date: Wed, 23 Aug 2006 18:43:55 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Snigdho Bardalai" <[email-masked]>, <[email-masked]>
Cc: "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" <[email-masked]>, <[email-masked]>
Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,
Date: Wed, 23 Aug 2006 19:43:27 +0100
Organization: Old Dog Consulting

Dimitri,

I think you are focusing in too closely on an example of how the problem can 
arise. The problem is simply that it is possible that the resources are not 
available in the same way at both ends of the link. The discussion then went 
down the path of how this might arise, and we have become stuck in a 
detailed example. Perhaps a better example would be the failure of a 
hardware component that is represents a label on the TE link, where the 
failure is known at the local node, but cannot be communicated to the remote 
node.

But related to your specific discussion...

> i am not sure to capture your point - let's say states are self-refreshed
> for some time, if the signaling channel is not up before pre-negotiated
> time - and you didn't fix this timer as being infinite - resources will be
> released when the cleanup elapses

So you are saying that there is a timer that can be set on the Hello such 
that if the Hello adjacency is not re-established in that time, all LSPs 
should be torn down. Yes. This is the Restart Cap object Restart Time.

But you say if "you didn't fix this timer as being infinite". But actually 
let's think about how operators like to use this timer. Sure they can say, I 
expect the CP to restart after a fault in 10 minutes, but wht about hardware 
faults? The CPU running the CP could fry, that is likely
to require a truck roll, and the user traffic must not be torn down just 
because of this fault.

So the Restart Time is typically set quite large. You will hear many people 
say that the user traffic is absolute - it must never be torn down because 
of a CP failure - and these people set the Restart Timer to all-f.

Now, once the time has been set large, we don't have automatic cleanup. So 
the cross-connects can get into a mess.

> in case one requires larger maintenance
> windows one provides such configuration beforehand

But note that this is not planned maintenance.

> mis-using one
> mechanism and then require another to reconstruct consistent states is the
> first point that needs to be clarified

So, are you saying that my description, above, represents a mis-use?
If so, how should I configure the Restart Time so that I can survive long CP 
outages?

> (it is also important to clarify
> that LMP does not "reserve resources" it just mediates data link states so
> if the error needs to be corrected it will any interfere with the entity
> that is making use of it

Completely agree with this point. LMP can report problems, but cannot fix 
them.

> what you are trying to achieve is detect mismatch but detect these mismach
> is not a solution to the problem

Agree completely.
What you have suggested before is that prevention is sufficient.
What I believe is that prevention of all cases is probably not possible, 
therefore detection and cure will be needed.

Detection (you are right) is not the same as cure. But cure without 
detection is improbable.

Note that cure is not necessarily the objective! There is a separate problem 
(sending Path with bad choice of label) that can be prevented after 
detection, without the need for cure.

Cure probably reuqires operator intervention.

> but more importantly what is the trigger
> to the detection itself? in brief how does one either of these sides
> knows it should start such "verification" process ... was it not at the
> end the reason for possibility of maintaining the "available" link on
> permanent verification state within LMP ?

Understanding the trigger for the detection process is important.

Section 4 of the I-D currently says:
   The data channel status confirmation related LMP messages are sent
   between adjacent nodes periodically or driven by some events

and this is not enough. We would need to know some more about the "period" 
and the "events" to assess whether this is going to flood the control 
channel or not provide the information in a timely manner.

For example, one could use the receipt of an Acceptable Label Set object 
(and some parsing thereof) as a trigger event.

Cheers,
Adrian

Delivery-date: Wed, 23 Aug 2006 18:39:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 13:38:57 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Bryskin, Igor" <[email-masked]>, "Drake, John E" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

Hi Igor- comments below (as >db, chair hat off)=20

-----Original Message-----
From: Bryskin, Igor [mailto:[email-masked]]=20
Sent: Wednesday, August 23, 2006 12:09 PM
To: Brungard, Deborah A, ALABS; Drake, John E; Diego Caviglia;
Dimitri.Papadimitriou
Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian Farrel
<adrian; danli
Subject: RE: Polling for new WG I-Ds

Deborah.
(My hat off since I am talking to a lady)
Db> thanks;-)

Have you been in a situation when you just performed a software upgrade
and a network operator tells you that your new release sucks and he
wants the network in the state of this morning prior to the upgrade? No?
Than you are lucky.
Db> that is totally different from this discussion, hopefully they know
what a backup is (for your benefit), and also one does not necessarily
want to use the backup since there could have been changes in the
network since the backup was made, unless the network is static;-) Would
stongly suggest you (and the operator) have done sufficient testing.

Besides, what is the problem with moving "hundreds/thousands of LSPs
from CP->MP"?=20
Db> Good joke;-)

Igor

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Wednesday, August 23, 2006 11:43 AM
To: Drake, John E; Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian Farrel
<adrian; danli
Subject: RE: Polling for new WG I-Ds

Agree with John, and control plane failures don't (should not/hope not)
impact the data plane state. And before doing such a sw upgrade, I would
not want to have to move hundreds/thousands of LSPs from CP->MP.

I'm not sure myself on what is meant by CP->MP, need to discuss more.

(chair hat off)
Deborah=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Drake, John E
Sent: Wednesday, August 23, 2006 11:13 AM
To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian Farrel
<adrian; danli
Subject: RE: Polling for new WG I-Ds

Snipped

>=20
> Besides I can see at least one quite real application for=20
> CP->MP. Imagine that an operator wants to perform some major=20
> software upgrade with a new software version significantly=20
> incompatible with the previous one.

JD:  Except that we go to great pains to ensure that this situation
never occurs.=20

Delivery-date: Wed, 23 Aug 2006 18:17:43 +0000
Date: Wed, 23 Aug 2006 11:17:02 -0700
From: Richard Rabbat <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Polling for new WG I-Ds

Ben,
see inline.

[email-masked] wrote:
> Igor,
>
> [email-masked] <> wrote:
>   
>> Deborah.
>> (My hat off since I am talking to a lady)
>>
>> Have you been in a situation when you just performed a
>> software upgrade and a network operator tells you that your
>> new release sucks and he wants the network in the state of
>> this morning prior to the upgrade? No? Than you are lucky.
>>     
>
> I'm not sure I understand the relevance of this.
>
>   
>> Besides, what is the problem with moving "hundreds/thousands
>> of LSPs from CP->MP"?
>>     
>
> The operating tenet is "if it aint broke don't fix it" so it'd likely
> have to be a very good reason in order to make an operator move
> hundreds/thousands of LSPs from CP->MP or MP->CP.  
I guess the jury is still out w/r to CP->MP as the discussion on the ML 
shows; but w/r to MP->CP, when an operator decides to deploy a CP, then 
control functions that resided in the MP should be delegated to that CP. 
There needs to be a migration strategy for that operation.

> It'd also have to be
> something forseeable as I can't see operators moving their LSPs from
> CP->MP routinely when doing a software change.
>   
I believe the authors were concerned about error handling and are not 
talking about this as a routine operation

> Ben
Richard.

Delivery-date: Wed, 23 Aug 2006 18:13:13 +0000
To: Snigdho Bardalai <[email-masked]>
Cc: ccamp <[email-masked]>, Dan Li <[email-masked]>, MEURIC Julien RD-CORE-LAN <[email-masked]>, [email-masked], [email-masked], "Zafar Ali (zali)" <[email-masked]>
Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,
From: [email-masked]
Date: Wed, 23 Aug 2006 20:12:49 +0200

hi - 

i am not sure to capture your point - let's say states are self-refreshed 
for some time, if the signaling channel is not up before pre-negotiated 
time - and you didn't fix this timer as being infinite - resources will be 
released when the cleanup elapses, in case one requires larger maintenance 
windows one provides such configuration beforehand => mis-using one 
mechanism and then require another to reconstruct consistent states is the 
first point that needs to be clarified (it is also important to clarify 
that LMP does not "reserve resources" it just mediates data link states so 
if the error needs to be corrected it will any interfere with the entituy 
that is making use of it

what you are trying to achieve is detect mismatch but detect these mismach 
is not a solution to the problem but more importantly what is the trigger 
to the detection itself ? in brief how does one either of these sides 
knows it should start such "verification" process ... was it not at the 
end the reason for possibility of maintaining the "available" link on 
permanent verification state within LMP ?

thanks,
-d.

Snigdho Bardalai <[email-masked]>
23/08/2006 18:14
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Dan Li <[email-masked]>, ccamp <[email-masked]>, 
MEURIC Julien RD-CORE-LAN <[email-masked]>, 
[email-masked], [email-masked], "Zafar Ali (zali)" 
<[email-masked]>
        Subject:        Re: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,

Hi Dimitri,

Since a control-channel failure leads to RSVP hello failure the clean-up
timeout event will not occur (due to auto-refresh).

In case an intermediate or egress node initiates the deletion process and
there is a temporary control-plane failure that disallows the delete 
request
from reaching the ingress node, then there is a potential problem.

Even though the intermediate or egress node initiates the force deletion 
process
after the "no-response" timer expires the connection may get re-created 
once
the control-plane recovers, because the ingress may continuously be 
transmitting
Path messages. Even if the Path message contains the RECOVERY object, this
will cause re-creation of the connection (Refer to RFC 3473 Section 
9.5.2).

One posible solution is to carry out a channel-status audit in order to 
detect
such anamolies.

Regards,
Snigdho

[email-masked] wrote:

>just a brief remark
>
>i don't see why channel status verification can not be achieved with 
>current mechanism described in section 12.7 of 4204 (and there is a
>need to come with a complete set of messages for this purpose)
>
>now i am even unclear how the problem you stated can occur
>
>"The channel status of a data link may become mismatched during the 
>   LSP deletion process. If the LSP deletion process is aborted in the 
>   middle of the process (perhaps because of a temporary control plane 
>   failure), the cross-connection at the upstream node may be removed 
>   while the downstream node still keeps its cross-connection."
>
>why do you think the notion of soft-state has been introduced ? once
>the cleanup timeout (set to K times the refresh timeout) interval is
>reached that then triggers a tear-down
>
>thanks,
>- d.
>
>
>
>
>
>
>Dan Li <[email-masked]>
>Sent by: [email-masked]
>23/08/2006 09:55
> 
>        To:     [email-masked], "Zafar Ali (zali)" 
<[email-masked]>, 
>MEURIC Julien RD-CORE-LAN <[email-masked]>
>        cc:     ccamp <[email-masked]>
>        Subject:        Re: High level comment on 
>draft-li-ccamp-confirm-data-channel-status-00.txt,
>
>
>Hi,
>
>Thanks Julien and Zafar for your comments. I agree with Julien. This I-D 
>just wants to provide a control plane tool to detect the inconsistent 
data 
>channel status in the tranport plane.
>
>Actually I have received several private emails think this I-D addresses 
a 
>real problem, but regarding the new LMP messages which are introduced in 
>this I-D, some people pointed out that the already deployed channelstatus 

>messages (id = 17, 18, 19 and 20) may be extended to carry also the 
>timeslot information instead only data link. But I have a concern that 
the 
>Fault Management Messages usually are triggered by fault detection, these 

>messages should not be sent if no fault is detected. The confirmation of 
>data channel status may need to be performed periodically or triggerd by 
>user.
>
>I would like to hear from you guys, what's your comments? Not only the 
>concerns raised above, but also other issues in this I-D.
>
>Regards,
>
>Dan
>
>----- Original Message ----- 
>From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
>To: "Zafar Ali (zali)" <[email-masked]>; <[email-masked]>; 
><[email-masked]>
>Cc: "ccamp" <[email-masked]>
>Sent: Tuesday, July 11, 2006 2:31 AM
>Subject: RE: High level comment on 
>draft-li-ccamp-confirm-data-channel-status-00.txt,
>
>
>Hi Zafar.
>
>I don't really get you on this. I figure out you're referring to
>removing the connection states when RSVP refreshes are not received any
>more, aren't you? If so, I'm afraid this is not enough for transmission
>devices, where resources can be physically cross-connected even though
>there is no (or no longer) corresponding RSVP state. Therefore having a
>mechanism to avoid such discrepancies would be welcome.
>
>Regards,
>
>Julien
>
>
>P.S.: If you totally rely on a management plane, I agree this should be
>useless (e.g. the NMS should already know if a cross-connection deletion
>failed, cf. Diego's 2nd slides seen this morning).
>
>________________________________
>
>
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Zafar Ali (zali)
>
>Dear Authors, 
> 
>RSVP refreshes do this job, so I am not sure motivation for this draft/
>LMP extensions. 
> 
>n.b. The draft state, "Although such a situation can be resolved through
>the use of the Acceptable Label Set object in GMPLS signaling [RFC3473],
>such a procedure is inefficient since it may require an additional
>signaling exchange for each LSP that is set up", so I assume that RSVP
>signaling is present (Although I did not understand the quoted statement
>from the ID). Even if RSVP is not present, e.g., optical core is
>completely controlled by a management entity, I would argue introduce
>presence of LMP. 
> 
>Thanks
> 
>Regards... Zafar 
>
>
>
>
> 
>

Envelope-to: [email-masked]
Delivery-date: Wed, 23 Aug 2006 18:11:27 +0000
Date: Wed, 23 Aug 2006 11:10:40 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4606 on Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
From: [email-masked]
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4606

        Title:      Generalized Multi-Protocol Label Switching (GMPLS) 
                    Extensions for Synchronous Optical Network (SONET) 
                    and Synchronous Digital Hierarchy (SDH) Control 
        Author:     E. Mannie, D. Papadimitriou
        Status:     Standards Track
        Date:       August 2006
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      25
        Characters: 53492
        Obsoletes:  RFC3946
        See-Also:   

        I-D Tag:    draft-ietf-ccamp-rfc3946bis-01.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4606.txt

This document provides minor clarification to RFC 3946.

This document is a companion to the Generalized Multi-protocol
Label Switching (GMPLS) signaling.  It defines the Synchronous
Optical Network (SONET)/Synchronous Digital Hierarchy (SDH)
technology-specific information needed when GMPLS signaling is used.  
[STANDARDS TRACK]

This document is a product of the Common Control and Measurement Plane
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.  Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Delivery-date: Wed, 23 Aug 2006 18:06:10 +0000
content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 14:05:41 -0400
From: "Bryskin, Igor" <[email-masked]>
To: "Drake, John E" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

Snipped

> > Furthermore, sometimes there is a need to actually=20
> > downgrade software, for instance, when one wants to add to=20
> > the network some older equipment.
>=20
> Why would anyone want to do this, especially without=20
> upgrading this equipments' software?
>=20
> IB>> Because the new software was developed on the assumption that it=20
> IB>> will work on the new hardware. Your customer, on the other hand,=20
> IB>> purchased your old equipment and you want to protect his=20
> IB>> investment.

This is not what you said initially.  You said 'add to=20
the network some older equipment.'

IB>> No, that's exactly what I meant. My customer purchased a ring of =
new devices with new software. The customer also happens to have several =
rings of older devices running older software. The customer wants to =
interconnect the new rings with old ones. The customer does not mind to =
downgrade the software on the new ring so that it will be compatible =
with other rings.

Igor

Delivery-date: Wed, 23 Aug 2006 17:59:06 +0000
content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 13:58:12 -0400
From: "Bryskin, Igor" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Ben,

> Deborah.
> (My hat off since I am talking to a lady)
>=20
> Have you been in a situation when you just performed a
> software upgrade and a network operator tells you that your
> new release sucks and he wants the network in the state of
> this morning prior to the upgrade? No? Than you are lucky.

I'm not sure I understand the relevance of this.

IB>> Imagine the situation when a major software upgrade was performed =
on all network controllers. The new software is significantly different =
from the old release. After the upgrade a serious problem was =
discovered. The operator wants to go back to the old software. Simple =
software reversion is not possible. The operator does not want to loose =
any of active services. So what do you do in this case? I say, do =
CP->MP->CP

> Besides, what is the problem with moving "hundreds/thousands
> of LSPs from CP->MP"?

The operating tenet is "if it aint broke don't fix it" so it'd likely
have to be a very good reason in order to make an operator move
hundreds/thousands of LSPs from CP->MP or MP->CP.  It'd also have to be
something forseeable as I can't see operators moving their LSPs from
CP->MP routinely when doing a software change.

IB>> From my remark above it should be obvious that I am not talking =
about routine CP->MP procedures. I am talking about "Don't stand, do =
something" kind of situation.

Igor
 =20

Delivery-date: Wed, 23 Aug 2006 17:46:42 +0000
content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 13:44:07 -0400
From: "Bryskin, Igor" <[email-masked]>
To: "Drake, John E" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

>=20
> Have you been in a situation when you just performed a=20
> software upgrade and a network operator tells you that your=20
> new release sucks and he wants the network in the state of=20
> this morning prior to the upgrade? No? Than you are lucky.

JD: This means reverting to the previous version of control plane
software,
not the CP->MP->CP detour.

IB>> I am talking about the situation when simple reverting is not =
possible due to incompatibility of the new and old software releases.

Furthermore, on more general note, if we decide that we need to be =
capable of doing MP->CP, just from the simmetricity point of view it =
makes a lot of sense to me to have CP->MP capability for debugging and =
testing the MP->CP move (if for nothing else)=20

Igor

>=20
> Besides, what is the problem with moving "hundreds/thousands=20
> of LSPs from CP->MP"?=20
>=20
> Igor
>=20
> -----Original Message-----
> From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
> Sent: Wednesday, August 23, 2006 11:43 AM
> To: Drake, John E; Bryskin, Igor; Diego Caviglia;=20
> Dimitri.Papadimitriou
> Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian=20
> Farrel <adrian; danli
> Subject: RE: Polling for new WG I-Ds
>=20
>=20
> Agree with John, and control plane failures don't (should=20
> not/hope not) impact the data plane state. And before doing=20
> such a sw upgrade, I would not want to have to move=20
> hundreds/thousands of LSPs from CP->MP.
>=20
> I'm not sure myself on what is meant by CP->MP, need to discuss more.
>=20
> (chair hat off)
> Deborah=20
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Drake, John E
> Sent: Wednesday, August 23, 2006 11:13 AM
> To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
> Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian=20
> Farrel <adrian; danli
> Subject: RE: Polling for new WG I-Ds
>=20
> Snipped
>=20
> >=20
> > Besides I can see at least one quite real application for
> > CP->MP. Imagine that an operator wants to perform some major
> > software upgrade with a new software version significantly
> > incompatible with the previous one.
>=20
> JD:  Except that we go to great pains to ensure that this=20
> situation never occurs.=20
>=20
>=20
>=20

Delivery-date: Wed, 23 Aug 2006 16:40:09 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>, "Dan Li" <[email-masked]>
Cc: "xuhuiying" <[email-masked]>, "Zafar Ali" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" <[email-masked]>, <[email-masked]>
Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,
Date: Wed, 23 Aug 2006 12:49:33 +0100
Organization: Old Dog Consulting

Hi all,

The problem statement in this draft is clear, and it seems to me that this 
problem might arise in a real network depending on the way the network is 
managed.

It is also clear to me that the current signaling protocols handle this type 
of problem , but that the process is not ideal. That is, LSPs would not 
necessarily fail to set up, but there might be some exchange of PathErr 
messages with Acceptable Label Set objects. Since the problem described in 
the draft is likely to be persistent, this signaling exchange would possibly 
be required on every LSP setup that uses the link in question. Functional, 
but not ideal.

It would be good if you could add a short sub-section to section 2 to 
describe how the existing signaling protocols will handle the problem and 
why you believe that this is not adequate.

Now, in general, we don't develop protocol extensions to optimise for error 
cases, so we have to be careful. If your proposals required continuous 
monitoring of available resources on each link, that would be a step to far. 
But if your proposal reflects a start-of-day cross-check followed 
(optionally) by updates triggered by operator intervention or infrequent 
timers, that is likely to be acceptable.

With regard to the use of existing messages or the definition of new 
messages: there are architectural and implementation choices. Although we 
inevitably need to be driven by the implementations, I am not a fan of 
overloading messages. IMHO the Fault Management messages are currently 
triggered by a perceived fault: they are used to report and isolated faults. 
The new function is used to detect faults, not to report or isolate them.

While I can see Diego's point that the objective is to find faults, the 
messages proposed by Dan do not report faults, they report information. 
Faults are only detected when the correlation between information at the two 
ends of the link is made. I think that if you wanted to go down the route 
suggested by Diego you would probably want to limit the information 
exchanged to only the data channels that are suspect, but I don't see how 
you can report the channels that are not available (because you might not 
know about them!) - it is only by hearing about the channels that your 
partner believes exist that you can deduce problems.

In terms of implementation, it really doesn't seem to be very expensive 
either way. You might want to consider how backward compatibility works with 
the two options. It is pretty clear how to handle a new message type that is 
not supported. What will be the impact of adding new TLVs to existing 
messages?

Cheers,
Adrian
----- Original Message ----- 
From: "Diego Caviglia" <[email-masked]>
To: "Dan Li <danli" <[email-masked]>
Cc: "xuhuiying" <[email-masked]>; "Zafar Ali (zali) <zali" 
<[email-masked]>; "MEURIC Julien RD-CORE-LAN <julien.meuric" 
<[email-masked]>; "ccamp <ccamp" <[email-masked]>
Sent: Wednesday, August 23, 2006 10:31 AM
Subject: Re: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,

>
> Hi Dan,
>        first of all I think that the ID addresses a real problem.
>
> Regarding the bits and bytes I prefer to not implemet new messages but 
> just
> updateds the existing ones that seems to fit to the problem.
>
> I think that having a timeslot that should be usable that is actually
> unusable is a failure from the control plane prespective.
>
> So I think that is correct to use the Fault Management Messages to convey
> information about unusable channles.
>
> Regards
>
> Diego
>
>
>
> Dan Li <[email-masked]>@ops.ietf.org on 23/08/2006 09.55.49
>
> Sent by:    [email-masked]
>
>
> To:    [email-masked], "Zafar Ali (zali)" <[email-masked]>, MEURIC
>       Julien RD-CORE-LAN <[email-masked]>
> cc:    ccamp <[email-masked]>
>
> Subject:    Re: High level comment on
>       draft-li-ccamp-confirm-data-channel-status-00.txt,
>
> Hi,
>
> Thanks Julien and Zafar for your comments. I agree with Julien. This I-D
> just wants to provide a control plane tool to detect the inconsistent data
> channel status in the tranport plane.
>
> Actually I have received several private emails think this I-D addresses a
> real problem, but regarding the new LMP messages which are introduced in
> this I-D, some people pointed out that the already deployed channelstatus
> messages (id = 17, 18, 19 and 20) may be extended to carry also the
> timeslot information instead only data link. But I have a concern that the
> Fault Management Messages usually are triggered by fault detection, these
> messages should not be sent if no fault is detected. The confirmation of
> data channel status may need to be performed periodically or triggerd by
> user.
>
> I would like to hear from you guys, what's your comments? Not only the
> concerns raised above, but also other issues in this I-D.
>
> Regards,
>
> Dan
>
> ----- Original Message -----
> From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
> To: "Zafar Ali (zali)" <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> Cc: "ccamp" <[email-masked]>
> Sent: Tuesday, July 11, 2006 2:31 AM
> Subject: RE: High level comment on
> draft-li-ccamp-confirm-data-channel-status-00.txt,
>
>
> Hi Zafar.
>
> I don't really get you on this. I figure out you're referring to
> removing the connection states when RSVP refreshes are not received any
> more, aren't you? If so, I'm afraid this is not enough for transmission
> devices, where resources can be physically cross-connected even though
> there is no (or no longer) corresponding RSVP state. Therefore having a
> mechanism to avoid such discrepancies would be welcome.
>
> Regards,
>
> Julien
>
>
> P.S.: If you totally rely on a management plane, I agree this should be
> useless (e.g. the NMS should already know if a cross-connection deletion
> failed, cf. Diego's 2nd slides seen this morning).
>
> ________________________________
>
>
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Zafar Ali (zali)
>
> Dear Authors,
>
> RSVP refreshes do this job, so I am not sure motivation for this draft/
> LMP extensions.
>
> n.b. The draft state, "Although such a situation can be resolved through
> the use of the Acceptable Label Set object in GMPLS signaling [RFC3473],
> such a procedure is inefficient since it may require an additional
> signaling exchange for each LSP that is set up", so I assume that RSVP
> signaling is present (Although I did not understand the quoted statement
> from the ID). Even if RSVP is not present, e.g., optical core is
> completely controlled by a management entity, I would argue introduce
> presence of LMP.
>
> Thanks
>
> Regards... Zafar
>
>
>
>
>
>
>
>
>
> 

Delivery-date: Wed, 23 Aug 2006 16:35:25 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 09:34:55 -0700
From: "Drake, John E" <[email-masked]>
To: "Bryskin, Igor" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

Snipped

> > Furthermore, sometimes there is a need to actually=20
> > downgrade software, for instance, when one wants to add to=20
> > the network some older equipment.
>=20
> Why would anyone want to do this, especially without=20
> upgrading this equipments' software?
>=20
> IB>> Because the new software was developed on the assumption that it=20
> IB>> will work on the new hardware. Your customer, on the other hand,=20
> IB>> purchased your old equipment and you want to protect his=20
> IB>> investment.

This is not what you said initially.  You said 'add to=20
the network some older equipment.'

Delivery-date: Wed, 23 Aug 2006 16:28:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 09:27:05 -0700
From: "Drake, John E" <[email-masked]>
To: "Bryskin, Igor" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

>=20
> Have you been in a situation when you just performed a=20
> software upgrade and a network operator tells you that your=20
> new release sucks and he wants the network in the state of=20
> this morning prior to the upgrade? No? Than you are lucky.

JD: This means reverting to the previous version of control plane
software,
not the CP->MP->CP detour.

>=20
> Besides, what is the problem with moving "hundreds/thousands=20
> of LSPs from CP->MP"?=20
>=20
> Igor
>=20
> -----Original Message-----
> From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
> Sent: Wednesday, August 23, 2006 11:43 AM
> To: Drake, John E; Bryskin, Igor; Diego Caviglia;=20
> Dimitri.Papadimitriou
> Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian=20
> Farrel <adrian; danli
> Subject: RE: Polling for new WG I-Ds
>=20
>=20
> Agree with John, and control plane failures don't (should=20
> not/hope not) impact the data plane state. And before doing=20
> such a sw upgrade, I would not want to have to move=20
> hundreds/thousands of LSPs from CP->MP.
>=20
> I'm not sure myself on what is meant by CP->MP, need to discuss more.
>=20
> (chair hat off)
> Deborah=20
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Drake, John E
> Sent: Wednesday, August 23, 2006 11:13 AM
> To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
> Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian=20
> Farrel <adrian; danli
> Subject: RE: Polling for new WG I-Ds
>=20
> Snipped
>=20
> >=20
> > Besides I can see at least one quite real application for
> > CP->MP. Imagine that an operator wants to perform some major
> > software upgrade with a new software version significantly
> > incompatible with the previous one.
>=20
> JD:  Except that we go to great pains to ensure that this=20
> situation never occurs.=20
>=20
>=20
>=20

Delivery-date: Wed, 23 Aug 2006 16:28:01 +0000
content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 12:16:16 -0400
From: "Bryskin, Igor" <[email-masked]>
To: "Drake, John E" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

>=20
> JD:  Except that we go to great pains to ensure that this=20
> situation never occurs.=20
>=20
> You are right, we do. In theory such situations should not=20
> happen, however, we all know that in practice there are=20
> always cases when original (especially proprietary) protocol=20
> solutions are not thought through enough, and it is=20
> impossible to maintain backward compatibility between the=20
> software releases. That's why I am talking about *major*=20
> upgrades. Furthermore, sometimes there is a need to actually=20
> downgrade software, for instance, when one wants to add to=20
> the network some older equipment.

Why would anyone want to do this, especially without upgrading this
equipments' software?

IB>> Because the new software was developed on the assumption that it =
will work on the new hardware. Your customer, on the other hand, =
purchased your old equipment and you want to protect his investment.

> Again, the ability to do=20
> the CP->MP->CP trick would help

Except that, as Lyndon and Deborah pointed out, the CP->MP->CP trick has
perils of its own.

IB>> Except that they were not specific what those perils are.

Igor

Delivery-date: Wed, 23 Aug 2006 16:18:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 17:17:55 +0100
From: <[email-masked]>
To: <[email-masked]>

Igor,

[email-masked] <> wrote:
> Deborah.
> (My hat off since I am talking to a lady)
>=20
> Have you been in a situation when you just performed a
> software upgrade and a network operator tells you that your
> new release sucks and he wants the network in the state of
> this morning prior to the upgrade? No? Than you are lucky.

I'm not sure I understand the relevance of this.

> Besides, what is the problem with moving "hundreds/thousands
> of LSPs from CP->MP"?

The operating tenet is "if it aint broke don't fix it" so it'd likely
have to be a very good reason in order to make an operator move
hundreds/thousands of LSPs from CP->MP or MP->CP.  It'd also have to be
something forseeable as I can't see operators moving their LSPs from
CP->MP routinely when doing a software change.

Ben
 =20

Delivery-date: Wed, 23 Aug 2006 16:15:49 +0000
Date: Wed, 23 Aug 2006 11:14:32 -0500
From: Snigdho Bardalai <[email-masked]>
Organization: Fujitsu Network Communications
To: [email-masked]
CC: Dan Li <[email-masked]>, ccamp <[email-masked]>, MEURIC Julien RD-CORE-LAN <[email-masked]>, [email-masked], [email-masked], "Zafar Ali (zali)" <[email-masked]>
Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,

Hi Dimitri,

Since a control-channel failure leads to RSVP hello failure the clean-up
timeout event will not occur (due to auto-refresh).

In case an intermediate or egress node initiates the deletion process and
there is a temporary control-plane failure that disallows the delete request
from reaching the ingress node, then there is a potential problem.

Even though the intermediate or egress node initiates the force deletion 
process
after the "no-response" timer expires the connection may get re-created once
the control-plane recovers, because the ingress may continuously be 
transmitting
Path messages. Even if the Path message contains the RECOVERY object, this
will cause re-creation of the connection (Refer to RFC 3473 Section 9.5.2).

One posible solution is to carry out a channel-status audit in order to 
detect
such anamolies.

Regards,
Snigdho

[email-masked] wrote:

>just a brief remark
>
>i don't see why channel status verification can not be achieved with 
>current mechanism described in section 12.7 of 4204 (and there is a
>need to come with a complete set of messages for this purpose)
>
>now i am even unclear how the problem you stated can occur
>
>"The channel status of a data link may become mismatched during the 
>   LSP deletion process. If the LSP deletion process is aborted in the 
>   middle of the process (perhaps because of a temporary control plane 
>   failure), the cross-connection at the upstream node may be removed 
>   while the downstream node still keeps its cross-connection."
>
>why do you think the notion of soft-state has been introduced ? once
>the cleanup timeout (set to K times the refresh timeout) interval is
>reached that then triggers a tear-down
>
>thanks,
>- d.
>
>
>
>
>
>
>Dan Li <[email-masked]>
>Sent by: [email-masked]
>23/08/2006 09:55
> 
>        To:     [email-masked], "Zafar Ali (zali)" <[email-masked]>, 
>MEURIC Julien RD-CORE-LAN <[email-masked]>
>        cc:     ccamp <[email-masked]>
>        Subject:        Re: High level comment on 
>draft-li-ccamp-confirm-data-channel-status-00.txt,
>
>
>Hi,
>
>Thanks Julien and Zafar for your comments. I agree with Julien. This I-D 
>just wants to provide a control plane tool to detect the inconsistent data 
>channel status in the tranport plane.
>
>Actually I have received several private emails think this I-D addresses a 
>real problem, but regarding the new LMP messages which are introduced in 
>this I-D, some people pointed out that the already deployed channelstatus 
>messages (id = 17, 18, 19 and 20) may be extended to carry also the 
>timeslot information instead only data link. But I have a concern that the 
>Fault Management Messages usually are triggered by fault detection, these 
>messages should not be sent if no fault is detected. The confirmation of 
>data channel status may need to be performed periodically or triggerd by 
>user.
>
>I would like to hear from you guys, what's your comments? Not only the 
>concerns raised above, but also other issues in this I-D.
>
>Regards,
>
>Dan
>
>----- Original Message ----- 
>From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
>To: "Zafar Ali (zali)" <[email-masked]>; <[email-masked]>; 
><[email-masked]>
>Cc: "ccamp" <[email-masked]>
>Sent: Tuesday, July 11, 2006 2:31 AM
>Subject: RE: High level comment on 
>draft-li-ccamp-confirm-data-channel-status-00.txt,
>
>
>Hi Zafar.
>
>I don't really get you on this. I figure out you're referring to
>removing the connection states when RSVP refreshes are not received any
>more, aren't you? If so, I'm afraid this is not enough for transmission
>devices, where resources can be physically cross-connected even though
>there is no (or no longer) corresponding RSVP state. Therefore having a
>mechanism to avoid such discrepancies would be welcome.
>
>Regards,
>
>Julien
>
>
>P.S.: If you totally rely on a management plane, I agree this should be
>useless (e.g. the NMS should already know if a cross-connection deletion
>failed, cf. Diego's 2nd slides seen this morning).
>
>________________________________
>
>
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Zafar Ali (zali)
>
>Dear Authors, 
> 
>RSVP refreshes do this job, so I am not sure motivation for this draft/
>LMP extensions. 
> 
>n.b. The draft state, "Although such a situation can be resolved through
>the use of the Acceptable Label Set object in GMPLS signaling [RFC3473],
>such a procedure is inefficient since it may require an additional
>signaling exchange for each LSP that is set up", so I assume that RSVP
>signaling is present (Although I did not understand the quoted statement
>from the ID). Even if RSVP is not present, e.g., optical core is
>completely controlled by a management entity, I would argue introduce
>presence of LMP. 
> 
>Thanks
> 
>Regards... Zafar 
>
>
>
>
>  
>

Delivery-date: Wed, 23 Aug 2006 16:09:36 +0000
content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 12:08:59 -0400
From: "Bryskin, Igor" <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, "Drake, John E" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

Deborah.
(My hat off since I am talking to a lady)

Have you been in a situation when you just performed a software upgrade =
and a network operator tells you that your new release sucks and he =
wants the network in the state of this morning prior to the upgrade? No? =
Than you are lucky.

Besides, what is the problem with moving "hundreds/thousands of LSPs =
from CP->MP"?=20

Igor

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Wednesday, August 23, 2006 11:43 AM
To: Drake, John E; Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian Farrel
<adrian; danli
Subject: RE: Polling for new WG I-Ds

Agree with John, and control plane failures don't (should not/hope not)
impact the data plane state. And before doing such a sw upgrade, I would
not want to have to move hundreds/thousands of LSPs from CP->MP.

I'm not sure myself on what is meant by CP->MP, need to discuss more.

(chair hat off)
Deborah=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Drake, John E
Sent: Wednesday, August 23, 2006 11:13 AM
To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian Farrel
<adrian; danli
Subject: RE: Polling for new WG I-Ds

Snipped

>=20
> Besides I can see at least one quite real application for=20
> CP->MP. Imagine that an operator wants to perform some major=20
> software upgrade with a new software version significantly=20
> incompatible with the previous one.

JD:  Except that we go to great pains to ensure that this situation
never occurs.=20

Delivery-date: Wed, 23 Aug 2006 16:09:28 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 09:08:45 -0700
From: "Drake, John E" <[email-masked]>
To: "Bryskin, Igor" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

>=20
> JD:  Except that we go to great pains to ensure that this=20
> situation never occurs.=20
>=20
> You are right, we do. In theory such situations should not=20
> happen, however, we all know that in practice there are=20
> always cases when original (especially proprietary) protocol=20
> solutions are not thought through enough, and it is=20
> impossible to maintain backward compatibility between the=20
> software releases. That's why I am talking about *major*=20
> upgrades. Furthermore, sometimes there is a need to actually=20
> downgrade software, for instance, when one wants to add to=20
> the network some older equipment.

Why would anyone want to do this, especially without upgrading this
equipments' software?

> Again, the ability to do=20
> the CP->MP->CP trick would help

Except that, as Lyndon and Deborah pointed out, the CP->MP->CP trick has
perils of its own.

Delivery-date: Wed, 23 Aug 2006 15:55:44 +0000
content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 11:54:59 -0400
From: "Bryskin, Igor" <[email-masked]>
To: "Drake, John E" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

John.

>=20
> Besides I can see at least one quite real application for=20
> CP->MP. Imagine that an operator wants to perform some major=20
> software upgrade with a new software version significantly=20
> incompatible with the previous one.

JD:  Except that we go to great pains to ensure that this situation
never occurs.=20

You are right, we do. In theory such situations should not happen, =
however, we all know that in practice there are always cases when =
original (especially proprietary) protocol solutions are not thought =
through enough, and it is impossible to maintain backward compatibility =
between the software releases. That's why I am talking about *major* =
upgrades. Furthermore, sometimes there is a need to actually downgrade =
software, for instance, when one wants to add to the network some older =
equipment. Again, the ability to do the CP->MP->CP trick would help

Igor

Delivery-date: Wed, 23 Aug 2006 15:42:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 10:42:43 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Drake, John E" <[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

Agree with John, and control plane failures don't (should not/hope not)
impact the data plane state. And before doing such a sw upgrade, I would
not want to have to move hundreds/thousands of LSPs from CP->MP.

I'm not sure myself on what is meant by CP->MP, need to discuss more.

(chair hat off)
Deborah=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Drake, John E
Sent: Wednesday, August 23, 2006 11:13 AM
To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian Farrel
<adrian; danli
Subject: RE: Polling for new WG I-Ds

Snipped

>=20
> Besides I can see at least one quite real application for=20
> CP->MP. Imagine that an operator wants to perform some major=20
> software upgrade with a new software version significantly=20
> incompatible with the previous one.

JD:  Except that we go to great pains to ensure that this situation
never occurs.=20

Delivery-date: Wed, 23 Aug 2006 15:36:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 11:35:21 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Drake, John E" <[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

I agree with this.  Besides, transitioning from CP->MP would=20
introduce its own risks.=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Drake, John E
Sent: Wednesday, August 23, 2006 8:13 AM
To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian Farrel
<adrian; danli
Subject: RE: Polling for new WG I-Ds

Snipped

>=20
> Besides I can see at least one quite real application for
> CP->MP. Imagine that an operator wants to perform some major
> software upgrade with a new software version significantly=20
> incompatible with the previous one.

JD:  Except that we go to great pains to ensure that this situation
never occurs.=20

Delivery-date: Wed, 23 Aug 2006 15:15:15 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 08:12:41 -0700
From: "Drake, John E" <[email-masked]>
To: "Bryskin, Igor" <[email-masked]>, "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

Snipped

>=20
> Besides I can see at least one quite real application for=20
> CP->MP. Imagine that an operator wants to perform some major=20
> software upgrade with a new software version significantly=20
> incompatible with the previous one.

JD:  Except that we go to great pains to ensure that this situation
never occurs.=20

Delivery-date: Wed, 23 Aug 2006 14:43:57 +0000
content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 23 Aug 2006 10:43:23 -0400
From: "Bryskin, Igor" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>, "Dimitri.Papadimitriou" <[email-masked]>
Cc: "\" ccamp \" <ccamp" <[email-masked]>, "\" owner-ccamp \" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>

Hi,

I agree with Diego on this. One of the reasons why operators are so =
nervous about using CP is CP's unpredictability (because of its dynamic =
nature). I am sure they will be more confident if/when they know that =
there is a way to undo everything or something that might go wrong with =
migration to CP without breaking active services.

Besides I can see at least one quite real application for CP->MP. =
Imagine that an operator wants to perform some major software upgrade =
with a new software version significantly incompatible with the previous =
one. One way to perform such an upgrade:
a) CP->MP;
b) perform software upgrade on all controllers
c) MP->CP

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Diego Caviglia
Sent: Wednesday, August 23, 2006 10:12 AM
To: Dimitri.Papadimitriou
Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian Farrel
<adrian; danli
Subject: Re: Polling for new WG I-Ds

Hi Dimitri,
            in line.

Regards

Diego

[email-masked] on 23/08/2006 15.51.23

To:    "Diego Caviglia" <[email-masked]>
cc:    "ccamp" <[email-masked]>, "owner-ccamp"
       <[email-masked]>, Adrian Farrel <[email-masked]>,
       [email-masked]

Subject:    Re: Polling for new WG I-Ds

hi diego -

[snipped]

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

[dp] concerning CP->MP input you provided would be helpful to have
carrier's speaking for themselves

[dc] I think they or some of them already did this.  Looking at the pool
seems that at least 4 carries voted yes to the ID.

[dp] not sure they express specific opinion on this aspect which is =
"shall
we take care about how to step back from GMPLS ?" it may be the case but
then the discussion has much fundamental impact than the discussion =
around
this specific i-d
[dc] I dont' think they said "we agree on moving this ID to WG" without
having read the doc, the point in the ID (we already agreed that is not =
a
mandatory requirement but only optional) is that should (or may or =
shall)
be possible to move back to NMS a circuit that was provisioned by the =
CP.
That is in the ID.
I was just pointing out that some carriers have already expressed their
opinion on the ID and thus on the CP->MP feature.  This is in line with =
the
Dan sentence.

The sentence "shall we take care about how to step back from GMPLS?" was
not in the intention of the ID.

 - 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)
[dc] Of course I think we should.

[dp] if i well understand your conclusion putting both of your answers
toghether it would mean that CCAMP should take care about how "removing"
GMPLS CP ?
[dc] No the point is that IMHO could be useful for carriers to have the
possibility to move a CP created circuit to the NMS.  May be this =
operation
can be performed via CP. This does not means to remove the whole control
plane.

... interesting opinion, it took 6 years for CCAMP to have something =
more
or less workable now you and your co-authors are probably trying to init
an item to disband this work, if this is the case i don't even =
understand
how we are polling for this document on this list
[dc] I don't think this is in the ID.  If my previous answer suggested =
this
is my fault.

[snipped]

Delivery-date: Wed, 23 Aug 2006 14:14:20 +0000
Sensitivity: 
Subject: Re: Polling for new WG I-Ds
To: "Dimitri.Papadimitriou" <[email-masked]>
Cc: ""ccamp" <ccamp" <[email-masked]>, ""owner-ccamp" <owner-ccamp" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "danli" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 23 Aug 2006 16:12:11 +0200

Hi Dimitri,
            in line.

Regards

Diego

[email-masked] on 23/08/2006 15.51.23

To:    "Diego Caviglia" <[email-masked]>
cc:    "ccamp" <[email-masked]>, "owner-ccamp"
       <[email-masked]>, Adrian Farrel <[email-masked]>,
       [email-masked]

Subject:    Re: Polling for new WG I-Ds

hi diego -

[snipped]

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

[dp] concerning CP->MP input you provided would be helpful to have
carrier's speaking for themselves

[dc] I think they or some of them already did this.  Looking at the pool
seems that at least 4 carries voted yes to the ID.

[dp] not sure they express specific opinion on this aspect which is "shall
we take care about how to step back from GMPLS ?" it may be the case but
then the discussion has much fundamental impact than the discussion around
this specific i-d
[dc] I dont' think they said "we agree on moving this ID to WG" without
having read the doc, the point in the ID (we already agreed that is not a
mandatory requirement but only optional) is that should (or may or shall)
be possible to move back to NMS a circuit that was provisioned by the CP.
That is in the ID.
I was just pointing out that some carriers have already expressed their
opinion on the ID and thus on the CP->MP feature.  This is in line with the
Dan sentence.

The sentence "shall we take care about how to step back from GMPLS?" was
not in the intention of the ID.

 - 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)
[dc] Of course I think we should.

[dp] if i well understand your conclusion putting both of your answers
toghether it would mean that CCAMP should take care about how "removing"
GMPLS CP ?
[dc] No the point is that IMHO could be useful for carriers to have the
possibility to move a CP created circuit to the NMS.  May be this operation
can be performed via CP. This does not means to remove the whole control
plane.

... interesting opinion, it took 6 years for CCAMP to have something more
or less workable now you and your co-authors are probably trying to init
an item to disband this work, if this is the case i don't even understand
how we are polling for this document on this list
[dc] I don't think this is in the ID.  If my previous answer suggested this
is my fault.

[snipped]

Delivery-date: Wed, 23 Aug 2006 13:53:18 +0000
To: "Diego Caviglia" <[email-masked]>
Cc: "ccamp" <[email-masked]>, "owner-ccamp" <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: Polling for new WG I-Ds
From: [email-masked]
Date: Wed, 23 Aug 2006 15:51:23 +0200

hi diego -

"Diego Caviglia" <[email-masked]>
23/08/2006 11:13
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Dan Li <danli", "Adrian Farrel <adrian", "ccamp" 
<[email-masked]>, "owner-ccamp" <[email-masked]>
        Subject:        Re: Polling for new WG I-Ds

Hi Dimitri,
            some comments in line.

Regards

Diego

[email-masked]@ops.ietf.org on 23/08/2006 10.33.10

Sent by:    [email-masked]

To:    Dan Li <[email-masked]>
cc:    Adrian Farrel <[email-masked]>, [email-masked],
       [email-masked]

Subject:    Re: Polling for new WG I-Ds

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

[snipped]

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

[dp] concerning CP->MP input you provided would be helpful to have
carrier's speaking for themselves

[dc] I think they or some of them already did this.  Looking at the pool
seems that at least 4 carries voted yes to the ID.

[dp] not sure they express specific opinion on this aspect which is "shall
we take care about how to step back from GMPLS ?" it may be the case but 
then the discussion has much fundamental impact than the discussion around
this specific i-d

 - 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)
[dc] Of course I think we should.

[dp] if i well understand your conclusion putting both of your answers
toghether it would mean that CCAMP should take care about how "removing" 
GMPLS CP ? 

... interesting opinion, it took 6 years for CCAMP to have something more 
or less workable now you and your co-authors are probably trying to init 
an item to disband this work, if this is the case i don't even understand
how we are polling for this document on this list

[snipped]

Delivery-date: Wed, 23 Aug 2006 12:48:06 +0000
To: Dan Li <[email-masked]>
Cc: ccamp <[email-masked]>, MEURIC Julien RD-CORE-LAN <[email-masked]>, [email-masked], [email-masked], "Zafar Ali (zali)" <[email-masked]>
Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,
From: [email-masked]
Date: Wed, 23 Aug 2006 14:45:41 +0200

just a brief remark

i don't see why channel status verification can not be achieved with 
current mechanism described in section 12.7 of 4204 (and there is a
need to come with a complete set of messages for this purpose)

now i am even unclear how the problem you stated can occur

"The channel status of a data link may become mismatched during the 
   LSP deletion process. If the LSP deletion process is aborted in the 
   middle of the process (perhaps because of a temporary control plane 
   failure), the cross-connection at the upstream node may be removed 
   while the downstream node still keeps its cross-connection."

why do you think the notion of soft-state has been introduced ? once
the cleanup timeout (set to K times the refresh timeout) interval is
reached that then triggers a tear-down

thanks,
- d.

Dan Li <[email-masked]>
Sent by: [email-masked]
23/08/2006 09:55
 
        To:     [email-masked], "Zafar Ali (zali)" <[email-masked]>, 
MEURIC Julien RD-CORE-LAN <[email-masked]>
        cc:     ccamp <[email-masked]>
        Subject:        Re: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,

Hi,

Thanks Julien and Zafar for your comments. I agree with Julien. This I-D 
just wants to provide a control plane tool to detect the inconsistent data 
channel status in the tranport plane.

Actually I have received several private emails think this I-D addresses a 
real problem, but regarding the new LMP messages which are introduced in 
this I-D, some people pointed out that the already deployed channelstatus 
messages (id = 17, 18, 19 and 20) may be extended to carry also the 
timeslot information instead only data link. But I have a concern that the 
Fault Management Messages usually are triggered by fault detection, these 
messages should not be sent if no fault is detected. The confirmation of 
data channel status may need to be performed periodically or triggerd by 
user.

I would like to hear from you guys, what's your comments? Not only the 
concerns raised above, but also other issues in this I-D.

Regards,

Dan

----- Original Message ----- 
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Zafar Ali (zali)" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: "ccamp" <[email-masked]>
Sent: Tuesday, July 11, 2006 2:31 AM
Subject: RE: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,

Hi Zafar.

I don't really get you on this. I figure out you're referring to
removing the connection states when RSVP refreshes are not received any
more, aren't you? If so, I'm afraid this is not enough for transmission
devices, where resources can be physically cross-connected even though
there is no (or no longer) corresponding RSVP state. Therefore having a
mechanism to avoid such discrepancies would be welcome.

Regards,

Julien

P.S.: If you totally rely on a management plane, I agree this should be
useless (e.g. the NMS should already know if a cross-connection deletion
failed, cf. Diego's 2nd slides seen this morning).

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Zafar Ali (zali)

Dear Authors, 
 
RSVP refreshes do this job, so I am not sure motivation for this draft/
LMP extensions. 
 
n.b. The draft state, "Although such a situation can be resolved through
the use of the Acceptable Label Set object in GMPLS signaling [RFC3473],
such a procedure is inefficient since it may require an additional
signaling exchange for each LSP that is set up", so I assume that RSVP
signaling is present (Although I did not understand the quoted statement
from the ID). Even if RSVP is not present, e.g., optical core is
completely controlled by a management entity, I would argue introduce
presence of LMP. 
 
Thanks
 
Regards... Zafar 

Delivery-date: Wed, 23 Aug 2006 09:33:11 +0000
Sensitivity: 
Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,
To: "Dan Li <danli" <[email-masked]>
Cc: "xuhuiying" <[email-masked]>, ""Zafar Ali (zali)" <zali" <[email-masked]>, "MEURIC Julien RD-CORE-LAN <julien.meuric" <[email-masked]>, "ccamp <ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 23 Aug 2006 11:31:23 +0200

Hi Dan,
        first of all I think that the ID addresses a real problem.

Regarding the bits and bytes I prefer to not implemet new messages but just
updateds the existing ones that seems to fit to the problem.

I think that having a timeslot that should be usable that is actually
unusable is a failure from the control plane prespective.

So I think that is correct to use the Fault Management Messages to convey
information about unusable channles.

Regards

Diego

Dan Li <[email-masked]>@ops.ietf.org on 23/08/2006 09.55.49

Sent by:    [email-masked]

To:    [email-masked], "Zafar Ali (zali)" <[email-masked]>, MEURIC
       Julien RD-CORE-LAN <[email-masked]>
cc:    ccamp <[email-masked]>

Subject:    Re: High level comment on
       draft-li-ccamp-confirm-data-channel-status-00.txt,

Hi,

Thanks Julien and Zafar for your comments. I agree with Julien. This I-D
just wants to provide a control plane tool to detect the inconsistent data
channel status in the tranport plane.

Actually I have received several private emails think this I-D addresses a
real problem, but regarding the new LMP messages which are introduced in
this I-D, some people pointed out that the already deployed channelstatus
messages (id = 17, 18, 19 and 20) may be extended to carry also the
timeslot information instead only data link. But I have a concern that the
Fault Management Messages usually are triggered by fault detection, these
messages should not be sent if no fault is detected. The confirmation of
data channel status may need to be performed periodically or triggerd by
user.

I would like to hear from you guys, what's your comments? Not only the
concerns raised above, but also other issues in this I-D.

Regards,

Dan

----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Zafar Ali (zali)" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: "ccamp" <[email-masked]>
Sent: Tuesday, July 11, 2006 2:31 AM
Subject: RE: High level comment on
draft-li-ccamp-confirm-data-channel-status-00.txt,

Hi Zafar.

I don't really get you on this. I figure out you're referring to
removing the connection states when RSVP refreshes are not received any
more, aren't you? If so, I'm afraid this is not enough for transmission
devices, where resources can be physically cross-connected even though
there is no (or no longer) corresponding RSVP state. Therefore having a
mechanism to avoid such discrepancies would be welcome.

Regards,

Julien

P.S.: If you totally rely on a management plane, I agree this should be
useless (e.g. the NMS should already know if a cross-connection deletion
failed, cf. Diego's 2nd slides seen this morning).

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Zafar Ali (zali)

Dear Authors,

RSVP refreshes do this job, so I am not sure motivation for this draft/
LMP extensions.

n.b. The draft state, "Although such a situation can be resolved through
the use of the Acceptable Label Set object in GMPLS signaling [RFC3473],
such a procedure is inefficient since it may require an additional
signaling exchange for each LSP that is set up", so I assume that RSVP
signaling is present (Although I did not understand the quoted statement
from the ID). Even if RSVP is not present, e.g., optical core is
completely controlled by a management entity, I would argue introduce
presence of LMP.

Thanks

Regards... Zafar

Delivery-date: Wed, 23 Aug 2006 09:17:59 +0000
Sensitivity: 
Subject: Re: Polling for new WG I-Ds
To: "Dimitri.Papadimitriou" <[email-masked]>
Cc: "Dan Li <danli" <[email-masked]>, "Adrian Farrel <adrian" <[email-masked]>, "ccamp" <[email-masked]>, "owner-ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 23 Aug 2006 11:13:44 +0200

Hi Dimitri,
            some comments in line.

Regards

Diego

[email-masked]@ops.ietf.org on 23/08/2006 10.33.10

Sent by:    [email-masked]

To:    Dan Li <[email-masked]>
cc:    Adrian Farrel <[email-masked]>, [email-masked],
       [email-masked]

Subject:    Re: Polling for new WG I-Ds

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

[snipped]

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

[dp] concerning CP->MP input you provided would be helpful to have
carrier's speaking for themselves
[dc] I think they or some of them already did this.  Looking at the pool
seems that at least 4 carries voted yes to the ID.

 - 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)
[dc] Of course I think we should.

[snipped]

Delivery-date: Wed, 23 Aug 2006 08:34:09 +0000
To: Dan Li <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Polling for new WG I-Ds
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

> adrian - see in-line
> 
> Adrian Farrel wrote:
> > 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.
> 
> - ok - 
> 
> > 
> 
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt

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

[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
 
> 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)
[dan] I think the CP->MP should not be the mandatory requirement.

[dp] this is what i thought

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

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

http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt 

> 
> > 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 ?
> 
> > Please send yes or no for these I-Ds.
> > 
> > Reasons and opinions are also welcomed.
> > 
> > Thanks,
> > Adrian 
> 
> 

Delivery-date: Wed, 23 Aug 2006 08:01:43 +0000
Date: Wed, 23 Aug 2006 15:55:49 +0800
From: Dan Li <[email-masked]>
Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,
To: [email-masked], "Zafar Ali (zali)" <[email-masked]>, MEURIC Julien RD-CORE-LAN <[email-masked]>
Cc: ccamp <[email-masked]>

Hi,

Thanks Julien and Zafar for your comments. I agree with Julien. This I-D just wants to provide a control plane tool to detect the inconsistent data channel status in the tranport plane.

Actually I have received several private emails think this I-D addresses a real problem, but regarding the new LMP messages which are introduced in this I-D, some people pointed out that the already deployed channelstatus messages (id = 17, 18, 19 and 20) may be extended to carry also the timeslot information instead only data link. But I have a concern that the Fault Management Messages usually are triggered by fault detection, these messages should not be sent if no fault is detected. The confirmation of data channel status may need to be performed periodically or triggerd by user.

I would like to hear from you guys, what's your comments? Not only the concerns raised above, but also other issues in this I-D.

Regards,

Dan

----- Original Message ----- 
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Zafar Ali (zali)" <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: "ccamp" <[email-masked]>
Sent: Tuesday, July 11, 2006 2:31 AM
Subject: RE: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,

Hi Zafar.

I don't really get you on this. I figure out you're referring to
removing the connection states when RSVP refreshes are not received any
more, aren't you? If so, I'm afraid this is not enough for transmission
devices, where resources can be physically cross-connected even though
there is no (or no longer) corresponding RSVP state. Therefore having a
mechanism to avoid such discrepancies would be welcome.

Regards,

Julien

P.S.: If you totally rely on a management plane, I agree this should be
useless (e.g. the NMS should already know if a cross-connection deletion
failed, cf. Diego's 2nd slides seen this morning).

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Zafar Ali (zali)

Dear Authors, 
 
RSVP refreshes do this job, so I am not sure motivation for this draft/
LMP extensions. 
 
n.b. The draft state, "Although such a situation can be resolved through
the use of the Acceptable Label Set object in GMPLS signaling [RFC3473],
such a procedure is inefficient since it may require an additional
signaling exchange for each LSP that is set up", so I assume that RSVP
signaling is present (Although I did not understand the quoted statement
from the ID). Even if RSVP is not present, e.g., optical core is
completely controlled by a management entity, I would argue introduce
presence of LMP. 
 
Thanks
 
Regards... Zafar 

Delivery-date: Wed, 23 Aug 2006 00:31:23 +0000
Date: Wed, 23 Aug 2006 09:28:58 +0900
From: Tomohiro Otani <[email-masked]>
To: Tomohiro Otani <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: Polling for new WG I-Ds

Hello,

I also support the others.

Regards,

tomo

Tomohiro Otani wrote:
> Hi Adrian,
> 
> I support the third draft to be a WG.
> 
> Regards,
> 
> tomo
> 
> 
> Adrian Farrel wrote:
>> 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
>>
>>
>>
> 
> 
> 

Delivery-date: Tue, 22 Aug 2006 08:52:51 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Fw: I-D ACTION:draft-andersson-rtg-gmpls-change-03.txt 
Date: Tue, 22 Aug 2006 09:49:54 +0100
Organization: Old Dog Consulting

All,

After much debate and discussion, the ADs and WG chairs have produced a new 
revision of the (G)MPLS change process draft. This should be read in 
conjunction with 
http://www.ietf.org/internet-drafts/draft-carpenter--protocol-extensions-01.txt

To avoid cross-posting, please send any comments (which will be gratefully 
received) to the Routing Area discussion mailing list only.

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 21, 2006 11:50 PM
Subject: I-D ACTION:draft-andersson-rtg-gmpls-change-03.txt

>A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title : Change Process for Multiprotocol Label Switching (MPLS) and 
> Generalized MPLS (GMPLS) Protocols and Procedures
> Author(s) : L. Andersson, A. Farrel
> Filename : draft-andersson-rtg-gmpls-change-03.txt
> Pages : 22
> Date : 2006-8-21
>
> The issues surrounding the extensibility of IETF protocols have been
> widely debated. These issues include when it is reasonable to
> extend IETF protocols with little or no review, and when extensions
> or variations need to be reviewed by the larger IETF community.
> Experience with IETF protocols has shown that extensibility of
> protocols without early IETF review can cause problems.
>
> The Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
> suites of protocols have become popular for a number of applications
> and deployment scenarios. One result of this popularity is a large
> number of suggestions for modifications and extensions.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-andersson-rtg-gmpls-change-03.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-andersson-rtg-gmpls-change-03.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-andersson-rtg-gmpls-change-03.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

--------------------------------------------------------------------------------

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 

Delivery-date: Mon, 21 Aug 2006 16:37:21 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Mon, 21 Aug 2006 09:36:06 -0700
From: "Dean Cheng \(dcheng\)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Yes to all.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Saturday, August 12, 2006 7:56 AM
> To: [email-masked]
> Subject: Polling for new WG I-Ds
>=20
> Hi,
>=20
> As discussed in Montreal, we need to poll for a couple of new=20
> WG drafts.
>=20
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpl
s-vcat-lcas-04.txt
> has been updated by the authors to provide further details=20
> and clarification.
>=20
> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-an
d-sc-reqs-02.txt
> has been updated since the version discussed in Montreal.
>=20
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace
ful-shutdown-04.txt
> has been updated as Zafar says in his previous email.
>=20
>=20
> Please send yes or no for these I-Ds.
>=20
> Reasons and opinions are also welcomed.
>=20
> Thanks,
> Adrian=20
>=20
>=20

Delivery-date: Mon, 21 Aug 2006 13:39:53 +0000
Date: Mon, 21 Aug 2006 06:38:52 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: Polling for new WG I-Ds
To: Adrian Farrel <[email-masked]>
Cc: [email-masked], [email-masked]

--0-1570073915-1156167532=:30514
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  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

> adrian - see in-line
> 
> Adrian Farrel wrote:
> > 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.
> 
> - ok - 
> 
> > 
> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt
> 
> - 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 ? 

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

> 
> 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)
> 
[dan] I think the CP->MP should not be the mandatory requirement.

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

> > 
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt 
> 
> > 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 ?
> 
> > Please send yes or no for these I-Ds.
> > 
> > Reasons and opinions are also welcomed.
> > 
> > Thanks,
> > Adrian 
> 
> 

---------------------------------
Do you Yahoo!?
 Next-gen email? Have it all with the  all-new Yahoo! Mail Beta.
--0-1570073915-1156167532=:30514
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">  <div>Hi,</div>  <div>&nbsp;</div>  <div>Yes to all three.</div>  <div>&nbsp;</div>  <div>Igor</div>  <div>&nbsp;</div>  <div>&nbsp;</div>  <div>----- Original Message ----- <BR>From: <[email-masked]><BR>To: "Adrian Farrel" <[email-masked]><BR>Cc: <[email-masked]>; <[email-masked]><BR>Sent: Thursday, August 17, 2006 6:32 AM<BR>Subject: Re: Polling for new WG I-Ds<BR><BR><BR>&gt; adrian - see in-line<BR>&gt; <BR>&gt; Adrian Farrel wrote:<BR>&gt; &gt; Hi,<BR>&gt; &gt; <BR>&gt; &gt; As discussed in Montreal, we need to poll for a couple of new WG drafts.<BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt <BR>&gt; <BR>&gt; &gt; has been updated by the authors to provide further details and <BR>&gt; &gt; clarification.<BR>&gt; <BR>&gt; - ok - <BR>&gt; <BR>&gt; &gt; <BR>&gt;
 http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt<BR>&gt; <BR>&gt; - guess it is v03.txt ? -<BR>&gt; <BR>&gt; &gt; has been updated since the version discussed in Montreal.<BR>&gt; <BR>&gt; i am ok in investigating the MP-&gt;CP but i have two concerns that imho <BR>&gt; should deserve more specific attention to maintain consistency wrt to <BR>&gt; CP-&gt;MP<BR>&gt; <BR>&gt; section 2.2: if control is lost for an LSP (during CP failure) how can it <BR>&gt; be possible transfer that LSP from the CP -&gt; MP ? <BR><BR>[dan] Yes, there is a problem if we still want to use the control plane to do the <BR>CP-&gt;MP transfer. Unless the transfer is based on the predetermined policy, MP <BR>takes the control of the LSP resource directly (no signaling required), but this way<BR>should not be discussed in CCAMP.<BR><BR>&gt; <BR>&gt; section 4.4: why the document assumes that both MUST be supported ? in <BR>&gt; part. concerning the CP-&gt;MP if one does
 implement current GMPLS signaling <BR>&gt; restart/recovery why shall this be mandated ? in brief, the document shall <BR>&gt; take into account existing mechanisms and prevent overlaps (with existing <BR>&gt; GMPLS mechanisms)<BR>&gt; <BR>[dan] I think the CP-&gt;MP should not be the mandatory requirement.<BR><BR>&gt; hence, it is strongly suggested to identify conditions when such CP-&gt;MP is <BR>&gt; required (and not an alternative to existing CP mechanisms) b/f <BR>&gt; progressing that part<BR>&gt; <BR>[dan] In order to make the carriers' life easy, when we provide the MP-&gt;CP<BR>conversion feature, the reverse procedure (CP-&gt;MP) may also is needed just<BR>simply in case the carriers want to withdraw their previous decision, and<BR>they also feel more comfortable with this "undo" function; In order to achieve<BR>this, we should have the working control plane. <BR><BR>&gt; &gt; <BR>&gt;
 http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt <BR>&gt; <BR>&gt; &gt; has been updated as Zafar says in his previous email.<BR>&gt; <BR>&gt; informational imho - in its current version <BR>&gt; <BR>&gt; - not sure to understand why the PathErr/Notify can be processed by the <BR>&gt; head-end only (what about segment recovery and stitching case) - why only <BR>&gt; MBB is possible upon reception (pls use E2E recovery/Segment recovery <BR>&gt; capabilities as you address GMPLS networks)<BR>&gt; <BR>&gt; - compared to path-reopt, error description is identical for the TE link <BR>&gt; case which leads to the following point - if errors code/value are the <BR>&gt; same how to distinguish them (assuming that the query procedure described <BR>&gt; in path-reopt is used during the setup of that LSP) ? - comment is more <BR>&gt; for the path-reopt draft than yours but since there is an overlap ... it <BR>&gt; must be addressed in a way or another
 (note that when fully head-end <BR>&gt; driven operations look similar but there is a major difference role of <BR>&gt; timing and severity of the error code/value) <BR>&gt; <BR>&gt; - in case shutdown of a protected component link (of a bundle) is <BR>&gt; initiated why can't link protection be used ?<BR>&gt; <BR>&gt; &gt; Please send yes or no for these I-Ds.<BR>&gt; &gt; <BR>&gt; &gt; Reasons and opinions are also welcomed.<BR>&gt; &gt; <BR>&gt; &gt; Thanks,<BR>&gt; &gt; Adrian <BR>&gt; <BR>&gt; <BR><BR></div></BLOCKQUOTE><BR><p>&#32;
		<hr size=1>Do you Yahoo!?<br> Next-gen email? Have it all with the <a href="http://us.rd.yahoo.com/evt=42241/*http://advision.webevents.yahoo.com/handraisers"> all-new Yahoo! Mail Beta.</a>
--0-1570073915-1156167532=:30514--

Delivery-date: Mon, 21 Aug 2006 12:35:24 +0000
Date: Mon, 21 Aug 2006 08:34:20 -0400
From: Eric W Gray <[email-masked]>
Reply-To: [email-masked]
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: Polling for new WG I-Ds

Yes to all three...

Adrian Farrel wrote:

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

Delivery-date: Mon, 21 Aug 2006 07:47:15 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Mon, 21 Aug 2006 09:46:01 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi,

Yes to all

Regards,

JL=20

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de Adrian Farrel
> Envoy=E9 : samedi 12 ao=FBt 2006 16:56
> =C0 : [email-masked]
> Objet : Polling for new WG I-Ds
>=20
> Hi,
>=20
> As discussed in Montreal, we need to poll for a couple of new=20
> WG drafts.
>=20
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpl
> s-vcat-lcas-04.txt
> has been updated by the authors to provide further details=20
> and clarification.
>=20
> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-an
> d-sc-reqs-02.txt
> has been updated since the version discussed in Montreal.
>=20
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace
> ful-shutdown-04.txt
> has been updated as Zafar says in his previous email.
>=20
>=20
> Please send yes or no for these I-Ds.
>=20
> Reasons and opinions are also welcomed.
>=20
> Thanks,
> Adrian=20
>=20
>=20
>=20
>=20

Delivery-date: Mon, 21 Aug 2006 04:54:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Mon, 21 Aug 2006 00:54:33 -0400
From: "Zafar Ali \(zali\)" <[email-masked]>
To: <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Dimitri,=20

Please see my reply inline.=20

Thanks for your support for Graceful Shutdown ID.=20

Regards.. Zafar =20

<snip>=20

> =20
> >=20
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace
> ful-shutdown-04.txt=20
>=20
> > has been updated as Zafar says in his previous email.
>=20
> informational imho - in its current version=20
>=20
> - not sure to understand why the PathErr/Notify can be=20
> processed by the=20
> head-end only (what about segment recovery and stitching=20
> case) - why only=20
> MBB is possible upon reception (pls use E2E recovery/Segment recovery=20
> capabilities as you address GMPLS networks)
>=20

This is a good point and we can address these scenarios in the next
version of the ID.=20

> - compared to path-reopt, error description is identical for=20
> the TE link=20
> case which leads to the following point - if errors=20
> code/value are the=20
> same how to distinguish them (assuming that the query=20
> procedure described=20
> in path-reopt is used during the setup of that LSP) ? -=20
> comment is more=20
> for the path-reopt draft than yours but since there is an=20
> overlap ...=20

In that case I will let authors of the path-reopt draft to reply/
comment on this point.=20

> it=20
> must be addressed in a way or another (note that when fully head-end=20
> driven operations look similar but there is a major=20
> difference role of=20
> timing and severity of the error code/value)=20
>=20
> - in case shutdown of a protected component link (of a bundle) is=20
> initiated why can't link protection be used ?
>=20

I think this also comes under the category of scenario you mentioned
above. We can address it and share the ID with you for further comments,
before publishing.=20
=20
> > Please send yes or no for these I-Ds.
> >=20
> > Reasons and opinions are also welcomed.
> >=20
> > Thanks,
> > Adrian=20
>=20

Delivery-date: Mon, 21 Aug 2006 04:44:09 +0000
Date: Mon, 21 Aug 2006 13:44:15 +0900
From: Tomohiro Otani <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: Re: Polling for new WG I-Ds

Hi Adrian,

I support the third draft to be a WG.

Regards,

tomo

Adrian Farrel wrote:
> 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
> 
> 
> 

Delivery-date: Mon, 21 Aug 2006 04:40:53 +0000
Date: Mon, 21 Aug 2006 13:40:10 +0900
From: Kenji Kumaki <[email-masked]>
To: [email-masked]
Subject: Re: Polling for new WG I-Ds

Hi,

Yes to all.

Thanks,
Kenji

Adrian Farrel wrote:
> 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
> 
> 
> 

Delivery-date: Mon, 21 Aug 2006 04:08:44 +0000
From: "wjq" <[email-masked]>
To: "IETF" <[email-masked]>
Subject: =?gb2312?B?cmWjulBvbGxpbmcgZm9yIG5ldyBXRyBJLURz?=
Date: Mon, 21 Aug 2006 12:07:04 +0800

This is a multi-part message in MIME format.

------=_NextPart_000_00A9_01C6C51A.50C38410
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

DQpZZXMgdG8gQUxMLg0KDQpSZWdhcmRzDQoNCg0KDQoNClNpbmNlcmVseSBZb3Vycw0KV2FuZyBK
aWFucXVhbg0KQXNzb2NpYXRlIFByb2Zlc3Nvcg0KRW5naW5lZXJpbmcgVGVjaG5vbG9neSBEaXZp
c2lvbg0KTmV0d29ya3MgQ29uc3RydWN0aW9uIERlcGFydG1lbnQsDQpDaGluYSBVbml0ZWQsVGVs
ZWNvbW11bmljYXRpb25zIENvcnBvcmF0aW9uLA0KTm8uMTMzQSxYaWRhbiBOb3J0aCBTdHJlZXQs
WGljaGVuZyBEaXN0cmljdCxCZWlqaW5nLCAxMDAwMzIsQ2hpbmENClRlbDogICs4NiAxMCA2NjUw
NTczOQ0KTW9iaWxlo7orODYgMTMzMzEwMTY2MDYNCkZheDogICAgKzg2IDEwIDY2NTA1ODQ0DQpF
bWFpbDogIHdhbmdqcUBjaGluYXVuaWNvbS5jb20uY24NCg==

------=_NextPart_000_00A9_01C6C51A.50C38410
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

------=_NextPart_000_00A9_01C6C51A.50C38410--

Delivery-date: Mon, 21 Aug 2006 03:22:44 +0000
Date: Mon, 21 Aug 2006 05:21:52 +0200
From: [email-masked]
To: [email-masked]
Subject: RE:Polling for new WG I-Ds

Yes to ALL.

Regards

Jing Ruiquan

China Telecom BRI

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, August 12, 2006 10:56 PM
Subject: Polling for new WG I-Ds

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

Delivery-date: Mon, 21 Aug 2006 02:02:35 +0000
Date: Mon, 21 Aug 2006 10:01:00 +0800
From: Dan Li <[email-masked]>
Subject: Re: Polling for new WG I-Ds
To: [email-masked], Adrian Farrel <[email-masked]>
Cc: [email-masked], [email-masked]

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

> adrian - see in-line
> 
> Adrian Farrel wrote:
> > 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.
> 
> - ok - 
> 
> > 
> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt
> 
> - 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 ? 

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

> 
> 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)
> 
[dan] I think the CP->MP should not be the mandatory requirement.

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

> > 
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt 
> 
> > 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 ?
>  
> > Please send yes or no for these I-Ds.
> > 
> > Reasons and opinions are also welcomed.
> > 
> > Thanks,
> > Adrian 
> 
> 

Delivery-date: Fri, 18 Aug 2006 21:50:28 +0000
Date: Fri, 18 Aug 2006 23:49:26 +0200
From: Huub van Helvoort <[email-masked]>
To: Trevor Wilson <[email-masked]>
CC:  [email-masked]
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.

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

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

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

Cheers, and have a nice weekend, Huub.

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

Delivery-date: Fri, 18 Aug 2006 19:51:57 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-04.txt 
Date: Fri, 18 Aug 2006 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: GMPLS - Communication of Alarm Information
	Author(s)	: L. Berger
	Filename	: draft-ietf-ccamp-gmpls-alarm-spec-04.txt
	Pages		: 18
	Date		: 2006-8-18
	
This document describes an extension to Generalized MPLS (Multi-
Protocol Label Switching) signaling to support communication of alarm
information.  GMPLS signaling already supports the control of alarm
reporting, but not the communication of alarm information.  This
document presents both a functional description and GMPLS-RSVP
specifics of such an extension.  This document also proposes
modification of the RSVP ERROR_SPEC object.

This document updates RFC 3473 "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions" through the addition of new,
optional protocol elements. It does not change, and is fully backward
compatible with the procedures specified in RFC 3473.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-gmpls-alarm-spec-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-alarm-spec-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 17 Aug 2006 18:33:28 +0000
Content-class: urn:content-classes:message
Subject: RE: Updated version of draft-ietf-ccamp-gmpls-rsvp-te-call
Date: Thu, 17 Aug 2006 13:32:34 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Bill Fenner" <[email-masked]>, "Ross Callon" <[email-masked]>
Cc: <[email-masked]>, "Adrian Farrel" <[email-masked]>

Bill and Ross,

This draft has been through CCAMP WG last call and has been updated to
my satisfaction. All changes were in response to LC comments and my
nits.

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-
01.txt

Please take it on its next step to being an RFC.

Thanks everyone,
Deborah

Delivery-date: Thu, 17 Aug 2006 15:31:38 +0000
Content-class: urn:content-classes:message
Subject: RE: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas -- was Re: Polling for new WG I-Ds
Date: Thu, 17 Aug 2006 16:30:09 +0100
From: "Trevor Wilson" <[email-masked]>
To: "Huub van Helvoort" <[email-masked]>, <[email-masked]>

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.=20
>
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:[email-masked]]=20
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,

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:
>=20
> 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 =3D non-LCAS-capable and =
Dynamic
=3D 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=20
> 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=20
> is far more unlikely).

[hvh] see my previous comment

> Regarding 'graceful degradation in the event of a failure': surely=20
> this is a misnomer ? Graceful degradation can only be achieved if the=20
> VCG capacity is hitlessly decreased. A full blown failure on any VCG=20
> 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 =3D 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 =3D true) or
whether it ignores AI_TSD[i] indications altogether (MI_TSDEnable =3D
false)."

> Suggested text for 3.2 (partial)
>=20
> Fixed, diversely routed: A fixed bandwidth VCG, transported over=20
>       at least two diversely routed subsets of member signals.  In
this=20
>       case, the subsets are link-disjoint over at least one link of
the=20
>       route.  The intent here is more efficient use of network=20
> resources
>=20
>       (no unique route has the required bandwidth), (note=20
>       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=20
>       at least two diversely routed subsets of member signals.  The=20
>       intent here is dynamic resizing and resilience (but differential

>       delay may be a limiting factor). Graceful degradation is=20
> 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
>=20
> Typo on second line of last paragraph: VC4-7v should be VC-4-7v.

[hvh] OK

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

> (permanent removal). Each of these has distinct meanings and I think=20
> that this ID should make that distinction also, or at least be more=20
> pedantic in the use of 'removal'.
>=20
> Perhaps (as far as GMPLS is concerned) there is only the need to=20
> address the VCG capacity decrease (permanent removal), since the=20
> 'temporary removal' is an autonomous action performed by the LCAS=20
> 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: -
>=20
> 4.1.3. Decreasing VCG capacity
>=20
> 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
>=20
> 4.1.3.1	Temporary Removal of a VCG member
>=20
> This is an autonomous action performed by the LCAS protocol whenever a

> failure occurs on an active VCG member(s). The relevant VCG member=20
> will then be in the DNU state.
>=20
> There is no management intervention required to perform this=20
> operation.
>=20
> This member can then be permanently removed from the VCG. (4.1.3.2)
>=20
> 4.1.3.2		Planned permanent removal of a VCG member
>=20
>    The procedure to remove a component signal is similar to that used=20
> to
>=20
>    add components as described in Section 4.1.2.  The LCAS in-band=20
>    signaling step is taken first to take the component out of the=20
> group as the result of a remove command from the LCAS controller; the=20
> 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]
>=20
>    In this case, the NVC value is decremented by 1 and the timeslot=20
>    identifier for the dropped component is removed from the ordered=20
> list
>=20
>    in the Generalized Label.
>=20
> This permanent removal procedure is only applicable to=20
> 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. =09

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

Kind regards, Huub van Helvoort.

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

Delivery-date: Wed, 16 Aug 2006 22:34:06 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Polling for new WG I-Ds
From: [email-masked]
Date: Thu, 17 Aug 2006 00:32:35 +0200

adrian - see in-line

Adrian Farrel wrote:
> 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.

- ok - 

http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt

- 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
 
http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt 

> 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 ?
 
> Please send yes or no for these I-Ds.
> 
> Reasons and opinions are also welcomed.
> 
> Thanks,
> Adrian 

Delivery-date: Wed, 16 Aug 2006 18:03:09 +0000
Date: Wed, 16 Aug 2006 20:01:55 +0200
From: Huub van Helvoort <[email-masked]>
To:  [email-masked]
CC: Trevor Wilson <[email-masked]>
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.

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

[hvh] a mis-connection is also 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).

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

> 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

> 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

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

> 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

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

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

Delivery-date: Wed, 16 Aug 2006 15:56:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for new WG I-Ds
Date: Wed, 16 Aug 2006 16:55:21 +0100
From: "Trevor Wilson" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C14C.6374150F
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

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=20
      at least two diversely routed subsets of member signals.  In this=20
      case, the subsets are link-disjoint over at least one link of the=20
      route.  The intent here is more efficient use of network resources

      (no unique route has the required bandwidth), (note=20
      that differential delay may be a limiting factor).

Dynamic, diversely routed: A dynamic VCAT group, transported over=20
      at least two diversely routed subsets of member signals.  The=20
      intent here is dynamic resizing and resilience (but differential=20
      delay may be a limiting factor). Graceful degradation is possible
in the event of a TSD (Trail Signal Degrade) on a VCG member(s) =20

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=20

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=20
   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]=20

   In this case, the NVC value is decremented by 1 and the timeslot=20
   identifier for the dropped component is removed from the ordered list

   in the Generalized Label. =20

This permanent removal procedure is only applicable to
LCAS-capable-VCAT.=20

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,

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-lca
s-04.txt=20
has been updated by the authors to provide further details and=20
clarification.

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

http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdo
wn-04.txt=20
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=20

------_=_NextPart_001_01C6C14C.6374150F
Content-Type: application/msword;
	name="ID-draft bernstein.... VCAT-LCAS..TW-comments.doc"
Content-Transfer-Encoding: base64
Content-Description: ID-draft bernstein.... VCAT-LCAS..TW-comments.doc
Content-Disposition: attachment;
	filename="ID-draft bernstein.... VCAT-LCAS..TW-comments.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAAwEAAAAAAAAA
EAAABgEAAAEAAAD+////AAAAAPwAAAAFAQAABAEAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////AQAAAP7/////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------_=_NextPart_001_01C6C14C.6374150F--

Delivery-date: Wed, 16 Aug 2006 06:51:12 +0000
Sensitivity: 
Subject: Re: Polling for new WG I-Ds
To: "Adrian Farrel" <[email-masked]>
Cc: "<ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 16 Aug 2006 08:48:05 +0200

Hi All,
        yes to all.

Regards

Diego

"Adrian Farrel" <[email-masked]>@ops.ietf.org on 12/08/2006 16.56.02

Please respond to "Adrian Farrel" <[email-masked]>

Sent by:    [email-masked]

To:    <[email-masked]>
cc:

Subject:    Polling for new WG I-Ds

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

Delivery-date: Tue, 15 Aug 2006 12:21:57 +0000
Date: Tue, 15 Aug 2006 14:20:14 +0200
From: Huub van Helvoort <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC:  [email-masked]
Subject: Re: Polling for new WG I-Ds

Hello Adrian,

You asked:

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

Yes to all.

Cheers, Huub.

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

Delivery-date: Tue, 15 Aug 2006 09:19:23 +0000
Date: Tue, 15 Aug 2006 18:17:55 +0900
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
From: Wataru Imajuku <[email-masked]>
Subject: Re: Polling for new WG I-Ds

Hi, All

  Yes to all.

Best Regards
Wataru

At 23:56 06/08/12, Adrian Farrel wrote:
 >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
 >
 >
 >
 >

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

Delivery-date: Tue, 15 Aug 2006 01:20:23 +0000
Date: Tue, 15 Aug 2006 09:18:59 +0800
From: Dan Li <[email-masked]>
Subject: Re: Polling for new WG I-Ds
To: Adrian Farrel <[email-masked]>, [email-masked]

Hi,

Yes to all.

Regards,

Dan

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, August 12, 2006 10:56 PM
Subject: Polling for new WG I-Ds

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

Delivery-date: Mon, 14 Aug 2006 21:09:39 +0000
From: "Stephanie Pruitt" <[email-masked]>
To: <[email-masked]>
Subject: CFP-MPLS 2006 International Conference, Oct 15-18 2006
Date: Mon, 14 Aug 2006 17:08:23 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_002D_01C6BFC4.403D6B20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Early bird registration ends soon!

Register for MPLS 2006 International Conference Today!

OCTOBER 15-18, 2006
Omni Shoreham Hotel
WASHINGTON, D.C. 
9th Annual International Conference on MPLS and Related Technologies

To register: 
Click here: http://www.mpls2006.com/onlineregis.htm

Conference Program:

http://www.isocore.com/mpls2006/program.htm 

Conference Hotel Information:

To reserve your room at the hotel, please visit:

http://www.mpls2006.com/hotel.htm 

Stephanie Pruitt

MPLS 2006 

12359 Sunrise Valley Drive, Suite 100

Reston, VA 20191

Office: (703) 860-1777

Fax: (703) 860-1778

------=_NextPart_000_002D_01C6BFC4.403D6B20
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Book Antiqua";
	panose-1:2 4 6 2 5 3 5 3 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D3 color=3Dred face=3D"Courier =
New"><span
style=3D'font-size:12.0pt;color:red'>Early bird registration ends =
soon!</span></font><font
size=3D3><span style=3D'font-size:12.0pt'><o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:
12.0pt'>Register for MPLS 2006 International Conference =
Today!<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:
12.0pt'>OCTOBER 15-18, 2006<br>
Omni Shoreham Hotel<br>
<st1:place w:st=3D"on"><st1:City w:st=3D"on">WASHINGTON</st1:City>, =
<st1:State
 w:st=3D"on">D.C.</st1:State></st1:place> <br>
9th Annual International Conference on MPLS and Related =
Technologies<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><b><font size=3D3 color=3Dnavy face=3D"Courier =
New"><span
style=3D'font-size:12.0pt;color:navy;font-weight:bold'><o:p>&nbsp;</o:p><=
/span></font></b></p>

<p class=3DMsoPlainText><b><font size=3D3 color=3Dnavy face=3D"Courier =
New"><span
style=3D'font-size:12.0pt;color:navy;font-weight:bold'>To register: <br>
</span></font></b><font size=3D3><span style=3D'font-size:12.0pt'>Click =
here: <a
href=3D"http://www.mpls2006.com/onlineregis.htm"
title=3D"http://www.mpls2006.com/onlineregis.htm">http://www.mpls2006.com=
/onlineregis.htm</a><o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><b><font size=3D3 color=3Dnavy face=3D"Courier =
New"><span
style=3D'font-size:12.0pt;color:navy;font-weight:bold'>Conference =
Program:<o:p></o:p></span></font></b></p>

<p class=3DMsoPlainText><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:
12.0pt'><a href=3D"http://www.isocore.com/mpls2006/program.htm"
title=3D"http://www.isocore.com/mpls2006/program.htm">http://www.isocore.=
com/mpls2006/program.htm</a>
<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><b><font size=3D3 color=3Dnavy face=3D"Courier =
New"><span
style=3D'font-size:12.0pt;color:navy;font-weight:bold'>Conference Hotel
Information:</span></font></b><font size=3D3><span =
style=3D'font-size:12.0pt'><o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:
12.0pt'>To reserve your room at the hotel, please =
visit:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:
12.0pt'><a href=3D"http://www.mpls2006.com/hotel.htm"
title=3D"http://www.mpls2006.com/hotel.htm">http://www.mpls2006.com/hotel=
.htm</a>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#804040" =
face=3D"Book Antiqua"><span
style=3D'font-size:12.0pt;font-family:"Book =
Antiqua";color:#804040'>Stephanie
Pruitt</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#804040" =
face=3D"Book Antiqua"><span
style=3D'font-size:12.0pt;font-family:"Book Antiqua";color:#804040'>MPLS =
2006 </span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><st1:Street w:st=3D"on"><st1:address =
w:st=3D"on"><strong><b><font
  size=3D3 color=3D"#804040" face=3D"Book Antiqua"><span =
style=3D'font-size:12.0pt;
  font-family:"Book Antiqua";color:#804040'>12359 Sunrise Valley Drive, =
Suite
  =
100</span></font></b></strong></st1:address></st1:Street><o:p></o:p></p>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:City =
w:st=3D"on"><strong><b><font
  size=3D3 color=3D"#804040" face=3D"Book Antiqua"><span =
style=3D'font-size:12.0pt;
  font-family:"Book =
Antiqua";color:#804040'>Reston</span></font></b></strong></st1:City><stro=
ng><b><font
 color=3D"#804040" face=3D"Book Antiqua"><span =
style=3D'font-family:"Book Antiqua";
 color:#804040'>, <st1:State w:st=3D"on">VA</st1:State> <st1:PostalCode =
w:st=3D"on">20191</st1:PostalCode></span></font></b></strong></st1:place>=
<o:p></o:p></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#804040" =
face=3D"Book Antiqua"><span
style=3D'font-size:12.0pt;font-family:"Book =
Antiqua";color:#804040'>Office: (703)
860-1777</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#804040" =
face=3D"Book Antiqua"><span
style=3D'font-size:12.0pt;font-family:"Book Antiqua";color:#804040'>Fax: =
(703)
860-1778</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_002D_01C6BFC4.403D6B20--

Delivery-date: Mon, 14 Aug 2006 19:50:55 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt 
Date: Mon, 14 Aug 2006 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls
	Author(s)	: D. Papadimitriou, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt
	Pages		: 29
	Date		: 2006-8-14
	
In certain networking topologies, it may be advantageous to maintain
associations between endpoints and key transit points to support an
instance of a service. Such associations are known as Calls.

A Call does not provide the actual connectivity for transmitting user
traffic, but only builds a relationship by which subsequent
Connections may be made. In Generalized MPLS (GMPLS) such Connections
are known as Label Switched Paths (LSPs).

This document specifies how GMPLS RSVP-TE signaling may be used and
extended to support Calls. These mechanisms provide full and logical
Call/Connection separation.

The mechanisms proposed in this document are applicable to any
environment (including multi-area), and for any type of interface:
packet, layer-2, time-division multiplexed, lambda or fiber
switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 14 Aug 2006 17:04:23 +0000
Date: Mon, 14 Aug 2006 10:02:20 -0700
From: Richard Rabbat <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: Polling for new WG I-Ds

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
--
Adrian Farrel wrote:
> 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
>
>

Delivery-date: Sun, 13 Aug 2006 04:32:03 +0000
Date: Sun, 13 Aug 2006 13:30:22 +0900
From: Kenji Kumaki <[email-masked]>
To: [email-masked]
Subject: Re: Montreal draft minutes posted

Hi,

I believe that ccamper give me some comments.

>Deborah: Should make any comments during the next few weeks on the list and do a respin.

Thanks,
Kenji 

On Tue, 1 Aug 2006 17:50:47 +0100
"Adrian Farrel" <[email-masked]> wrote:

> http://www3.ietf.org/proceedings/06jul/minutes/ccamp.htm
> 
> Please review.
> 
> Apologies for the delay which is all my fault.
> 
> Thanks to the note takers and to Deborah for compiling the minutes.
> 
> Adrian
> 

-- 
Kenji Kumaki <[email-masked]>

Delivery-date: Sat, 12 Aug 2006 15:02:21 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Polling for new WG I-Ds
Date: Sat, 12 Aug 2006 15:56:02 +0100
Organization: Old Dog Consulting

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 

Delivery-date: Sat, 12 Aug 2006 15:02:13 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Updated version of draft-ietf-ccamp-gmpls-rsvp-te-call
Date: Sat, 12 Aug 2006 15:37:39 +0100
Organization: Old Dog Consulting

Hi,

We have just submitted an updated version of 
draft-ietf-ccamp-gmpls-rsvp-te-call.

These changes result from:
- WG chair review by Deborah
- extensive post WG last call discussions on the CCAMP list.

Note that we polled the MPLS WG via the mailing list on the use of the 
previously reserved bits in the Session object and received no comments.

Changes are:

==
Throughout...
Minor punctuation changes
==
Throughout
s/LINK CAPABILITY/LINK_CAPABILITY/
==
Abstract
s/connection/Connection/ (twice)
==
Section 2
s/connection/Connection/ (four times)
==
Section 2
OLD
A Call may be associated with zero, one more Connections,
NEW
A Call may be associated with zero, one, or more than one Connection,
==
Section 4.2
Use period not colon before list.
==
Section 3.3
s/Call Segments capabilities/Call Segment capabilities/
==
Section 4.3
OLD
   It is useful for the ingress node of an LSP to know the link
   capabilities of the link between the network and the egress node.
   This information may allow the ingress node to tailor its LSP request
   to fit those capabilities and to better utilize network resources
   with regard to those capabilities.

   In particular, this may be used to achieve end-to-end spectral
   routing attribute negotiation for signal quality negotiation (such as
   BER) in photonic environments where network edges are signal
   regeneration capable. Similarly, it may be used to provide end-to-end
   spatial routing attribute negotiation in multi-area routing
   environments, in particular, when TE links have been bundled based on
   technology specific attributes.

  Call setup may provide a suitable mechanism to exchange information
  for this purpose, although several other possibilities exist.
NEW
   In an overlay model, it is useful for the ingress node of an LSP to
   know the link capabilities of the link between the network and the
   remote overlay network. In the language of [RFC4208], the ingress
   node can make use of information about the link between the egress
   network node (NN) and the remote edge node (EN). We call this link
   the egress network link. This information may allow the ingress node
   to tailor its LSP request to fit those capabilities and to better
   utilize network resources with regard to those capabilities.

   For example, this might be used in transparent optical networks to
   supply information on lambda availability on egress network links,
   or, where the egress NN is capable of signal regeneration, it might
   provide a mechanism for negotiating signal quality attributes (such
   as bit error rate). Similarly, in multi-domain routing environments
   it could be used to provide end-to-end selection of component links
   (i.e., spatial attribute negotiation) where TE links have been
   bundled based on technology specific attributes.

   In some circumstances, the Traffic Engineering Database (TED) may
   contain sufficient information for decisions to be made about which
   egress network link to use. In other circumstances, the TED might not
   contain this information and Call setup may provide a suitable
   mechanism to exchange information for this purpose. The
   Call-responder may use the Call parameters to select a subset of the
   available egress network links between the egress NN and the remote
   EN, and may report these links and their capabilities on the Call
   response so that the Call-initiator may select a suitable link.

   The sections that follow indicate the cases where the TED may be
   used, and those where Call parameter exchange may be appropriate.
==
Section 4.3.1
OLD
   In this case, there may be no need to distribute additional link
   capability information over and above the information distributed by
   the TE and GMPLS extensions to the IGP. Further, it is possible that
   future extensions to these IGPs will allow the distribution of more
   detailed information including optical impairments.
NEW
   In this case the ingress (and correspondingly the egress) lie within
   the network and there may be no need to distribute additional link
   capability information over and above the information distributed by
   the TE and GMPLS extensions to the IGP. Further, it is possible that
   future extensions to these IGPs will allow the distribution of more
   detailed information including optical impairments.
==
Section 4.3.2
OLD
   In this case, edge link information may not be visible within the
   core network, nor (and specifically) at other edge nodes. This may
   prevent an ingress from requesting suitable LSP characteristics to
   ensure successful LSP setup.

   Various solutions to this problem exist including the definition of
   static TE links (that is, not advertised by a routing protocol)
   between the core network and the edge nodes. Nevertheless, special
   procedures may be necessary to advertise edge TE link information to
   the edge nodes outside of the network without advertising the
   information specific to the contents of the network.

   In the future, when the requirements are understood on the
   information that needs to be supported, TE extensions to EGPs may be
   defined that provide this function.
NEW
   In this case the ingress (and correspondingly the egress) lie outside
   the network. Edge link information may not be visible within the
   core network, nor (and specifically) at other edge nodes. This may
   prevent an ingress from requesting suitable LSP characteristics to
   ensure successful LSP setup.

   Various solutions to this problem exist, including the definition of
   static TE links (that is, not advertised by a routing protocol)
   between the NNs and ENs. Nevertheless, special procedures may be
   necessary to advertise to the edge nodes outside of the network
   information about egress network links without also advertising the
   information specific to the contents of the network.

   In the future, when the requirements on the information that needs to
   be supported are better understood, TE extensions to EGPs may be
   defined that provide this function, and new rules for leaking TE
   information between routing instances may be used.
==
Section 4.3.3
OLD
   When IGP and EGP solutions are not available at the UNI, there is
   still a requirement to have, at the local edge nodes, the knowledge
   of the remote edge link capabilities.

   The Call setup procedure provides an opportunity to discover edge
   link capabilities of remote edge nodes before LSP setup is attempted.
   The LINK CAPABILITY object is defined to allow this information to be
   exchanged. The information that is included in this object is similar
   to that distributed by GMPLS-capable IGPs (see [RFC4202]).
NEW
   When IGP and EGP solutions are not available at the User-to-Network
   Interface (UNI), there is still a requirement to have, at the local
   edge nodes, the knowledge of the remote edge link capabilities.

   The Call setup procedure provides an opportunity to discover edge
   link capabilities of remote edge nodes before LSP setup is attempted.

   - The Call-responder can return information on one or more egress
     network links. The Call-reponder could return a full list of the
     available links with information about the link capabilities, or it
     could filter the list to return information about only those links
     which might be appropriate to support the Connections needed by the
     Call. To do this second option, the Call-responder must determine
     such appropriate links from information carried in the Call request
     including destination of the Call, and the level of service
     (bandwidth, protection, etc.) required.

   - On receiving a Call response, the Call-initiator must determine
     paths for the Connections (LSPs) that it will set up. The way that
     it does this is out of scope for this document since it is an
     implementation-specific, algorithmic process. However, it can take
     as input the information about the available egress network links
     as supplied in the Call response.

   The LINK_CAPABILITY object is defined to allow this information to be
   exchanged. The information that is included in this object is similar
   to that distributed by GMPLS-capable IGPs (see [RFC4202]).
==
Section 5.1
s/connection/Connection/ (twice)
==
Section 5.2
s/connection/Connection/ (three times)
==
Section 5.2.2
s/connection/Connection/
==
Section 5.3
Use period not colon before list.
==
Section 5.3
OLD
   The LINK CAPABILITY object is introduced to support link capability
   exchange during Call setup and MAY be included in a Notify message
   used for Call setup. This optional object includes the bundled link
   local capabilities of the Call initiating node (or terminating node)
   indicated by the source address of the Notify message.
NEW
   The LINK_CAPABILITY object is introduced to support link capability
   exchange during Call setup and MAY be included in a Notify message
   used for Call setup. This optional object includes the link local
   capabilities of a link joining the Call-initiating node (or
   Call-terminating node) to the network. The specific node is indicated
   by the source address of the Notify message.

   The link reported can be a single link or can be a bundled link
   [RFC4201].
==
Section 5.3
OLD
   - Type 1: the link local IPv4 address (numbered bundle) using the
     format defined in [RFC3209]
   - Type 2: the link local IPv6 address (numbered bundle) using the
     format defined in [RFC3209]
   - Type 4: the link local identifier (unnumbered links and bundles)
     using the format defined in [RFC3477]
   - Type 64: the Maximum Reservable Bandwidth corresponding to this
     bundle (see [RFC4201])
   - Type 65: the interface switching capability descriptor (see
     [RFC4202]) corresponding to this bundle (see also [RFC4201]).
NEW
   - Type 1: the link local IPv4 address of a link or a numbered bundle
     using the format defined in [RFC3209]
   - Type 2: the link local IPv6 address of a link or a numbered bundle
     using the format defined in [RFC3209]
   - Type 4: the link local identifier of an unnumbered link or bundle
     using the format defined in [RFC3477]
   - Type 64: the Maximum Reservable Bandwidth corresponding to this
     link or bundle (see [RFC4201])
   - Type 65: the interface switching capability descriptor (see
     [RFC4202]) corresponding to this link or bundle (see also
     [RFC4201]).
==
Section 5.3
OLD
   This object MAY also be used to exchange more than one bundled link
   capability. In this case, the following ordering MUST be followed:
   one identifier subobject (Type 1, 2 or 4) MUST be inserted before any
   capability subobject (Type 64 or 65) to which it refers.
NEW
   A single instance of this object MAY be used to exchange capability
   information relating to more than one link or bundled link. In this
   case, the following ordering MUST be used:
   - each link MUST be identified by an identifier subobject (Type 1, 2
     or 4)
   - capability subobjects (Type 64 or 65, and future subobjects) MUST
     be placed after the identifier subobject for the link or bundle to
     which they refer.

   Multiple instances of the LINK_CAPABILITY object within the same
   Notify message are not supported by this specification. In the event
   that a Notify message contains multiple LINK_CAPABILITY objects, the
   receiver SHOULD process the first one as normal and SHOULD ignore
   subsequent instances of the object.
==
Section 5.4.1
s/ATTIBUTE/ATTRIBUTE/
==
Section 5.5
OLD
   The format and the contents of the ADMIN_STATUS object are both
   dictated by [RFC3473] in favor of [RFC3471]. The new "C" bit is added
   as shown below.
NEW
   [RFC3473] indicates that the format and contents of the ADMIN_STATUS
   object are as defined in [RFC3471]. The new "C" bit is added for Call
   control as shown below.
==
Section 6.1
s/connection/Connection/
==
Section 6.1 bullet two
s/a further Connection/another Connection/
==
Section 6.2
Use period not colon before list.
==
Section 6.2 bullet one
s/call terminating/Call-terminating/
==
Section 6.2 bullet two
s/value is assigning/value in assigning/
==
Section 6.2 bullet three
s/call initiating/Call-initiating/
==
Section 6.6.1
s/RFC3743/RFC3473/
==
Section 6.6.3 3rd para
Alignment fixed
s/at least the five/at least five/
==
Section 6.7
s/call/Call/
s/connection/Connection/  (twice)
s/link failures, and the addition/link failures, or the addition/
==
Section 7.3.1
s/call/Call/
==
Section 9.1
OLD
   Note, additionally, that the process of Call establishment
   independent of LSP setup may be used to apply an extra level of
   authentication and policy to hop-by-hop LSP setup.
NEW
   Note, additionally, that the process of independent Call
   establishment, where the Call is set up separately from the LSPs, may
   be used to apply an extra level of authentication and policy for the
   end-to-end LSPs above that which is available with Call-less,
   hop-by-hop LSP setup.
==
Section 9.1
s/Insect/IPsec/
==
Section 9.1
ADD
   The frequency of Call establishment is application dependent and hard
   to generalize. Key exchange for Call-related message exchanges is
   therefore something that should be configured or arranged dynamically
   in different deployments according to the advice in [RFC4107]. Note
   that the remote RSVP-TE signaling relationship between Call endpoints
   is no different from the signaling relationship between LSRs that
   establish an LSP. That is, the LSRs are not necessarily IP-adjacent
   in the control plane in either case. Thus key exchange should be
   regarded as a remote procedure, not a single hop procedure. There are
   several procedures for automatic remote exchange of keys, and IKE
   [RFC2409] is particularly suggested in [RFC3473].
==
Section 11.
Updated acknowledgements
==
Section 12.1
Added RFC 2709
==
Section 12.2
Added RFC 4107
==
Section 13
Updated Arthi's coordinates
==

Regards,
Adrian and Dimitri

Delivery-date: Sat, 12 Aug 2006 14:29:58 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Subject: Please publish draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt
Date: Sat, 12 Aug 2006 15:26:16 +0100
Organization: Old Dog Consulting

This is a multi-part message in MIME format.

------=_NextPart_000_0545_01C6BE23.A76B2EB0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Please publish the attached I-D and notify the CCAMP mailing list.
Thanks,
Adrian
------=_NextPart_000_0545_01C6BE23.A76B2EB0
Content-Type: text/plain;
	format=flowed;
	name="draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt";
	reply-type=original
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt"

CCAMP Working Group                                              Editors
Internet Draft                                D. Papadimitriou (Alcatel)
Updates RFC 3473                          A. Farrel (Old Dog Consulting)
Proposed Category: Standard Track
Expiration Date: February 2007                               August 2006

          Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions
                           in support of Calls

                draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

Abstract

   In certain networking topologies, it may be advantageous to maintain
   associations between endpoints and key transit points to support an
   instance of a service. Such associations are known as Calls.

   A Call does not provide the actual connectivity for transmitting user
   traffic, but only builds a relationship by which subsequent
   Connections may be made. In Generalized MPLS (GMPLS) such Connections
   are known as Label Switched Paths (LSPs).

   This document specifies how GMPLS RSVP-TE signaling may be used and
   extended to support Calls. These mechanisms provide full and logical
   Call/Connection separation.

   The mechanisms proposed in this document are applicable to any
   environment (including multi-area), and for any type of interface:
   packet, layer-2, time-division multiplexed, lambda or fiber
   switching.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                      [Page 1]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

Table of Content

   1. Conventions used in this document ............................. 3
   2. Introduction .................................................. 3
   2.1 Applicability to ASON ........................................ 4
   3. Requirements .................................................. 4
   3.1 Basic Call Function .......................................... 4
   3.2 Call/Connection Separation ................................... 4
   3.3 Call Segments ................................................ 5
   4. Concepts and Terms ............................................ 5
   4.1 What is a Call? .............................................. 5
   4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs .......... 5
   4.3 Exchanging Access Link Capabilities .......................... 6
   4.3.1 Network-initiated Calls .................................... 7
   4.3.2 User-initiated Calls ....................................... 7
   4.3.3 Utilizing Call Setup ....................................... 7
   5. Protocol Extensions for Calls and Connections ................. 8
   5.1 Call Setup and Teardown ...................................... 8
   5.2 Call Identification .......................................... 8
   5.2.1 Long Form Call Identification .............................. 9
   5.2.2 Short Form Call Identification ............................. 9
   5.2.3 Short Form Call ID Encoding ................................ 9
   5.3 LINK_CAPABILITY object ...................................... 10
   5.4 Revised Message Formats ..................................... 11
   5.4.1 Notify Message ............................................ 21
   5.5 ADMIN_STATUS Object ......................................... 21
   6. Procedures in Support of Calls and Connections ............... 32
   6.1 Call/Connection Setup Procedures ............................ 32
   6.2 Call Setup .................................................. 32
   6.2.1 Accepting Call Setup ...................................... 54
   6.2.2 Call Setup Failure and Rejection .......................... 65
   6.3 Adding a Connections to a Call .............................. 65
   6.3.1 Adding a Reverse Direction LSP to a Call .................. 76
   6.4 Call-Free Connection Setup .................................. 76
   6.5 Call Collision .............................................. 76
   6.6 Call/Connection Teardown .................................... 87
   6.6.1 Removal of a Connection from a Call ....................... 98
   6.6.2 Removal of the Last Connection from a Call ................ 98
   6.6.3 Teardown of an "Empty" Call ............................... 98
   6.6.4 Attempted Teardown of a Call with Existing Connections .... 98
   6.6.5 Teardown of a Call from the Egress ........................ 20
   6.7 Control Plane Survivability ................................. 20
   7. Applicability of Call and Connection Procedures .............. 21
   7.1 Network-initiated Calls ..................................... 21
   7.2 User-initiated Calls ........................................ 21
   7.3 External Call Managers ...................................... 22
   7.3.1 Call Segments ............................................. 22
   8. Non-support of Call ID ....................................... 22
   8.1 Non-Support by External Call Managers ....................... 23
   8.2 Non-Support by Transit Node ................................. 23

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                      [Page 2]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   8.3 Non-Support by Egress Node .................................. 24
   9. Security Considerations ...................................... 24
   9.1 Call and Connection Security Considerations ................. 24
   10. IANA Considerations ......................................... 25
   10.1 RSVP Objects ............................................... 25
   10.2 RSVP Error Codes and Error Values .......................... 25
   10.3 RSVP ADMIN_STATUS object Bits .............................. 25
   11. Acknowledgements ............................................ 26
   12. References .................................................. 26
   12.1 Normative References ....................................... 26
   12.2 Informative References ..................................... 27
   13. Authors' Addresses .......................................... 28

1. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In addition, the reader is assumed to be familiar with the
   terminology used in [RFC3471], [RFC3473], [RFC3477] and [RFC3945].

2. Introduction

   This document defines protocol procedures and extensions to support
   Calls within Generalized MPLS (GMPLS).

   A Call is an association between endpoints and possibly between key
   transit points (such as network boundaries) in support of an instance
   of a service. The end-to-end association is termed a "Call," and the
   association between two transit points or between an endpoint and a
   transit point is termed a "Call Segment." An entity that processes a
   Call or Call Segment is called a "Call Manager."

   A Call does not provide the actual connectivity for transmitting user
   traffic, but only builds a relationship by which subsequent
   Connections may be made. In GMPLS such Connections are known as Label
   Switched Paths (LSPs).

   A Call may be associated with zero, one, or more than one Connection,
   and a Connection may be associated with zero or one Call. Thus full
   and logical Call/Connection separation is needed.

   An example of the requirement for Calls can be found in the ITU-T's
   Automatically Switched Optical Network (ASON) architecture [G.8080]
   and specific requirements for support of Calls in this context can be
   found in [RFC4139]. Note, however, that while the mechanisms
   described in this document meet the requirements stated in [RFC4139],
   they have wider applicability.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                      [Page 3]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   The mechanisms defined in this document are equally applicable to any
   packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable
   interfaces, LSC interfaces, or FSC interfaces. The mechanisms and
   protocol extensions are backward compatible, and can be used for Call
   management where only the Call Managers need to be aware of the
   protocol extensions.

2.1 Applicability to ASON

   [RFC4139] details the requirements on GMPLS signaling to satisfy the
   ASON architecture described in [G.8080]. The mechanisms described in
   this document meet the requirements for Calls as described in
   Sections 4.2 and 4.3 of [RFC4139] and the additional Call-related
   requirements in Sections 4.4, 4.7, 5 and 6 of [RFC4139].

   [ASON-APPL] describes the applicability of GMPLS protocols to the
   ASON architecture.

3. Requirements

3.1 Basic Call Function

   The Call concept is used to deliver the following capabilities.

   - Verification and identification of the Call initiator (prior to
     LSP setup).

   - Support of virtual concatenation with diverse path component LSPs.

   - Association of multiple LSPs with a single Call (note aspects
     related to recovery are detailed in [RFC4426] and [GMPLS-E2E]).

   - Facilitation of control plane operations by allowing operational
     status change of the associated LSP.

   Procedures and protocol extensions to support Call setup, and the
   association of Calls with Connections are described in Section 5 and
   onwards of this document.

3.2 Call/Connection Separation

   Full and logical Call and Connection separation is required. That is:

   - It MUST be possible to establish a Connection without dependence
      on a Call.

   - It MUST be possible to establish a Call without any associated
     Connections.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                      [Page 4]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   - It MUST be possible to associate more than one Connection with a
     Call.

   - Removal of the last Connection associated with a Call SHOULD NOT
     result in the automatic removal of the Call except as a matter of
     local policy at the ingress of the Call.

   - Signaling of a Connection associated with a Call MUST NOT require
     the distribution or retention of Call-related information (state)
     within the network.

3.3 Call Segments

   Call Segment capabilities MUST be supported.

   Procedures and (GMPLS) RSVP-TE signaling protocol extensions to
   support Call Segments are described in Section 7.3.1 of this
   document.

4. Concepts and Terms

   The concept of a Call and a Connection are also discussed in the ASON
   architecture [G.8080] and [RFC4139]. This section is not intended as
   a substitute for those documents, but is a brief summary of the key
   terms and concepts.

4.1 What is a Call?

   A Call is an agreement between endpoints possibly in cooperation with
   the nodes that provide access to the network. Call setup may include
   capability exchange, policy, authorization and security.

   A Call is used to facilitate and manage a set of Connections that
   provide end to end data services. While Connections require state to
   be maintained at nodes along the data path within the network, Calls
   do not involve the participation of transit nodes except to forward
   the Call management requests as transparent messages.

   A Call may be established and maintained independently of the
   Connections that it supports.

4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs

   Clearly there is a hierarchical relationship between Calls and
   Connections. One or more Connections may be associated with a Call. A
   Connection may not be part of more than one Call. A Connection may,
   however, exist without a Call.

   In GMPLS RSVP-TE [RFC3473], a Connection is identified with a GMPLS
   TE Tunnel. Commonly a Tunnel is identified with a single LSP, but it

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                      [Page 5]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   should be noted that for protection, load balancing and many other
   functions, a Tunnel may be supported by multiple parallel LSPs. The
   following identification reproduces this hierarchy.

   - Call IDs are unique within the context of the pair of addresses
     that are the source and destination of the Call.

   - Tunnel IDs are unique within the context of the Session (that is
     the destination of the Tunnel). Applications may also find it
     convenient to keep the Tunnel ID unique within the context of a
     Call.

   - LSP IDs are unique within the context of a Tunnel.

   Note that the Call_ID value of zero is reserved and MUST NOT be used
   during LSP-independent Call establishment.

   Throughout the remainder of this document, the terms LSP and Tunnel
   are used interchangeably with the term Connection. The case of a
   Tunnel that is supported by more than one LSP is covered implicitly.

4.3 Exchanging Access Link Capabilities

   In an overlay model, it is useful for the ingress node of an LSP to
   know the link capabilities of the link between the network and the
   remote overlay network. In the language of [RFC4208], the ingress
   node can make use of information about the link between the egress
   network node (NN) and the remote edge node (EN). We call this link
   the egress network link. This information may allow the ingress node
   to tailor its LSP request to fit those capabilities and to better
   utilize network resources with regard to those capabilities.

   For example, this might be used in transparent optical networks to
   supply information on lambda availability on egress network links,
   or, where the egress NN is capable of signal regeneration, it might
   provide a mechanism for negotiating signal quality attributes (such
   as bit error rate). Similarly, in multi-domain routing environments
   it could be used to provide end-to-end selection of component links
   (i.e., spatial attribute negotiation) where TE links have been
   bundled based on technology specific attributes.

   In some circumstances, the Traffic Engineering Database (TED) may
   contain sufficient information for decisions to be made about which
   egress network link to use. In other circumstances, the TED might not
   contain this information and Call setup may provide a suitable
   mechanism to exchange information for this purpose. The
   Call-responder may use the Call parameters to select a subset of the
   available egress network links between the egress NN and the remote
   EN, and may report these links and their capabilities on the Call
   response so that the Call-initiator may select a suitable link.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                      [Page 6]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   The sections that follow indicate the cases where the TED may be
   used, and those where Call parameter exchange may be appropriate.

4.3.1 Network-initiated Calls

   In this case the ingress (and correspondingly the egress) lie within
   the network and there may be no need to distribute additional link
   capability information over and above the information distributed by
   the TE and GMPLS extensions to the IGP. Further, it is possible that
   future extensions to these IGPs will allow the distribution of more
   detailed information including optical impairments.

4.3.2 User-initiated Calls

   In this case the ingress (and correspondingly the egress) lie outside
   the network. Edge link information may not be visible within the
   core network, nor (and specifically) at other edge nodes. This may
   prevent an ingress from requesting suitable LSP characteristics to
   ensure successful LSP setup.

   Various solutions to this problem exist, including the definition of
   static TE links (that is, not advertised by a routing protocol)
   between the NNs and ENs. Nevertheless, special procedures may be
   necessary to advertise to the edge nodes outside of the network
   information about egress network links without also advertising the
   information specific to the contents of the network.

   In the future, when the requirements on the information that needs to
   be supported are better understood, TE extensions to EGPs may be
   defined that provide this function, and new rules for leaking TE
   information between routing instances may be used.

4.3.3 Utilizing Call Setup

   When IGP and EGP solutions are not available at the User-to-Network
   Interface (UNI), there is still a requirement to have, at the local
   edge nodes, the knowledge of the remote edge link capabilities.

   The Call setup procedure provides an opportunity to discover edge
   link capabilities of remote edge nodes before LSP setup is attempted.

   - The Call-responder can return information on one or more egress
     network links. The Call-reponder could return a full list of the
     available links with information about the link capabilities, or it
     could filter the list to return information about only those links
     which might be appropriate to support the Connections needed by the
     Call. To do this second option, the Call-responder must determine
     such appropriate links from information carried in the Call request
     including destination of the Call, and the level of service
     (bandwidth, protection, etc.) required.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                      [Page 7]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   - On receiving a Call response, the Call-initiator must determine
     paths for the Connections (LSPs) that it will set up. The way that
     it does this is out of scope for this document since it is an
     implementation-specific, algorithmic process. However, it can take
     as input the information about the available egress network links
     as supplied in the Call response.

   The LINK_CAPABILITY object is defined to allow this information to be
   exchanged. The information that is included in this object is similar
   to that distributed by GMPLS-capable IGPs (see [RFC4202]).

5. Protocol Extensions for Calls and Connections

   This section describes the protocol extensions needed in support of
   Call identification and management of Calls and Connections.
   Procedures for the use of these protocol extensions are described in
   Section 6.

5.1 Call Setup and Teardown

   Calls are established independently of Connections through the use of
   the Notify message. The Notify message is a targeted message and does
   not follow the path of LSPs through the network.

   Simultaneous Call and Connection establishment (sometimes referred to
   as piggybacking) is not supported.

5.2 Call Identification

   As soon as the concept of a Call is introduced, it is necessary to
   support some means of identifying the Call. This becomes particularly
   important when Calls and Connections are separated and Connections
   must contain some reference to the Call.

   A Call may be identified by a sequence of bytes that may have
   considerable (but not arbitrary) length. A Call ID of 40 bytes would
   not be unreasonable. It is not the place of this document to supply
   rules for encoding or parsing Call IDs, but it must provide a
   suitable means to communicate Call IDs within the protocol. The full
   Call identification is referred to as the long Call ID.

   The Call_ID is only relevant at the sender and receiver nodes.
   Maintenance of this information in the signaling state is not
   mandated at any intermediate node. Thus no change in [RFC3473]
   transit implementations is required and there are no backward
   compatibility issues. Forward compatibility is maintained by using
   the existing default values to indicate that no Call processing is
   required.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                      [Page 8]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   Further, the long Call ID is not required as part of the Connection
   (LSP) state even at the sender and receiver nodes so long as some
   form of correlation is available. This correlation is provided
   through the short Call ID.

5.2.1 Long Form Call Identification

   The long Call ID is only required on the Notify message used to
   establish the Call. It is carried in the "Session Name" field of the
   SESSION_ATTRIBUTE Object on the Notify message.

   A unique value per Call is inserted in the "Session Name" field by
   the initiator of the Call. Subsequent network nodes MAY inspect this
   object and MUST forward this object transparently across network
   interfaces until reaching the egress node. Note that the structure of
   this field MAY be the object of further formatting depending on the
   naming convention(s). However, [RFC3209] defines the "Session Name"
   field as a Null padded display string, and that any formatting
   conventions for the Call ID must be limited to this scope.

5.2.2 Short Form Call Identification

   The Connections (LSPs) associated with a Call need to carry a
   reference to the Call - the short Call ID. A new field is added to
   the signaling protocol to identify an individual LSP with the Call to
   which it belongs.

   The new field is a 16-bit identifier (unique within the context of
   the address pairing provided by the Tunnel_End_Point_Address and the
   Sender_Address of the SENDER TEMPLATE object) that MUST be exchanged
   on the Notify message during Call initialization and is used on all
   subsequent LSP messages that are associated with the Call. This
   identifier is known as the short Call ID and is encoded as described
   in Section 5.2.3. The Call ID MUST NOT be used as part of the
   processing to determine the session to which an RSVP signaling
   message applies. This does not generate any backward compatibility
   issue since the reserved field of the SESSION object defined in
   [RFC3209] MUST NOT be examined on receipt.

   In the unlikely case of short Call_ID exhaustion, local node policy
   decides upon specific actions to be taken, but might include the use
   of second Sender_Address. Local policy details are outside of the
   scope of this document.

5.2.3 Short Form Call ID Encoding

   The short Call ID is carried in a 16-bit field in the SESSION object
   carried on the Notify message used during Call setup, and on all
   messages during LSP setup and management. The field used was
   previously reserved (MUST be set to zero on transmission and ignored

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                      [Page 9]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   on receipt). This ensures backward compatibility with nodes that do
   not utilize Calls.

   The figure below shows the new version of the object.

   Class =3D SESSION, Class-Num =3D 1, C-Type =3D 7(IPv4)/8(IPv6)

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~               IPv4/IPv6 Tunnel end point address              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call_ID            |           Tunnel ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209])

   Call_ID: 16 bits

        A 16-bit identifier used in the SESSION object that remains
        constant over the life of the Call. The Call_ID value MUST be
        set to zero when there is no corresponding Call.

   Tunnel ID: 16 bits (see [RFC3209])

   Extended Tunnel ID: 32 bits/128 bits (see [RFC3209])

5.3 LINK_CAPABILITY object

   The LINK_CAPABILITY object is introduced to support link capability
   exchange during Call setup and MAY be included in a Notify message
   used for Call setup. This optional object includes the link local
   capabilities of a link joining the Call-initiating node (or
   Call-terminating node) to the network. The specific node is indicated
   by the source address of the Notify message.

   The link reported can be a single link or can be a bundled link
   [RFC4201].

   The Class Number is selected so that the nodes that do not recognize
   this object drop it silently. That is, the top bit is set and the
   next bit is clear.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 10]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   This object has the following format:

   Class-Num =3D TBA (form 10bbbbbb), C_Type =3D 1

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                        (Subobjects)                         //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The contents of the LINK_CAPABILITY object is defined as series of
   variable-length data items called subobjects. The subobject format is
   defined in [RFC3209].

   The following subobjects are currently defined.
   - Type 1: the link local IPv4 address of a link or a numbered bundle
     using the format defined in [RFC3209]
   - Type 2: the link local IPv6 address of a link or a numbered bundle
     using the format defined in [RFC3209]
   - Type 4: the link local identifier of an unnumbered link or bundle
     using the format defined in [RFC3477]
   - Type 64: the Maximum Reservable Bandwidth corresponding to this
     link or bundle (see [RFC4201])
   - Type 65: the interface switching capability descriptor (see
     [RFC4202]) corresponding to this link or bundle (see also
     [RFC4201]).

   Note: future revisions of this document may extend the above list.

   A single instance of this object MAY be used to exchange capablity
   information relating to more than one link or bundled link. In this
   case, the following ordering MUST be used:
   - each link MUST be identified by an identifier subobject (Type 1, 2
     or 4)
   - capability subobjects (Type 64 or 65, and future subobjects) MUST
     be placed after the identifier subobject for the link or bundle to
     which they refer.

   Mulitple instances of the LINK_CAPABILITY object within the same
   Notify message are not supported by this specification. In the event
   that a Notify message contains multiple LINK_CAPABILITY objects, the
   receiver SHOULD process the first one as normal and SHOULD ignore
   subsequent instances of the object.

5.4 Revised Message Formats

   The Notify message is enhanced to support Call establishment and
   teardown of Calls. See Section 6 for a description of the procedures.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 11]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

5.4.1 Notify Message

   The Notify message is modified in support of Call establishment by
   the optional addition of the LINK CAPABILTY object. Further, the
   SESSION ATTRIBUTE object is added to the <notify session> sequence to
   carry the long Call ID. The presence of the SESSION ATTRIBUTE object
   MAY be used to distinguish a Notify message used for Call management,
   but see Section 5.5 for another mechanism. The <notify session list>
   MAY be used to simultaneously set up multiple Calls.

   The format of the Notify Message is as follows:

   <Notify message>  ::=3D <Common Header> [ <INTEGRITY> ]
                         [[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
                         [ <MESSAGE_ID> ]
                         <ERROR_SPEC>
                         <notify session list>

   <notify session list> ::=3D [ <notify session list> ] <notify =
session>

   <notify session>  ::=3D <SESSION> [ <ADMIN_STATUS> ]
                         [ <POLICY_DATA>...]
                         [ <LINK_CAPABILITY> ]
                         [ <SESSION_ATTRIBUTE> ]
                         [ <sender descriptor> | <flow descriptor> ]

   <sender descriptor> ::=3D see [RFC3473]

   <flow descriptor> ::=3D see [RFC3473]

5.5 ADMIN_STATUS Object

   Notify messages exchanged for Call control and management purposes
   carry a specific new bit (the Call Management or C bit) in the ADMIN
   STATUS object.

   [RFC3473] indicates that the format and contents of the ADMIN_STATUS
   object are as defined in [RFC3471]. The new "C" bit is added for Call
   control as shown below.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|                        Reserved                     |C|T|A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Reflect (R): 1 bit - see [RFC3471]
        Testing (T): 1 bit - see [RFC3471]
        Administratively down (A): 1 bit - see [RFC3471]
        Deletion in progress (D): 1 bit - see [RFC3471]

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 12]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

        Call Management (C): 1 bit

            This bit is set when the message is being used to control
            and manage a Call.

   The procedures for the use of the C bit are described in Section 6.

6. Procedures in Support of Calls and Connections

6.1 Call/Connection Setup Procedures

   This section describes the processing steps for Call and Connection
   setup.

   There are three cases considered:

   - A Call is set up without any associated
     Connection. It is assumed that Connections will be added to the
     Call at a later time, but this is neither a requirement nor
     a constraint.

   - A Connection may be added to an existing Call. This may happen if
     the Call was set up without any associated Connections, or if
     another Connection is added to a Call that already has one or more
     associated Connections.

   - A Connection may be established without any reference to a Call
     (see Section 6.4). This encompasses the previous LSP setup
     procedure.

   Note that a Call MAY NOT be imposed upon a Connection that is already
   established. To do so would require changing the short Call ID in the
   SESSION OBJECT of the existing LSPs and this would constitute a
   change in the Session Identifier. This is not allowed by existing
   protocol specifications.

   Call and Connection teardown procedures are described later in
   Section 6.6.

6.2 Call Setup

   A Call is set up before, and independent of, LSP (i.e. Connection)
   setup.

   Call setup MAY necessitate verification of the link status and link
   capability negotiation between the Call ingress node and the Call
   egress node. The procedure described below is applied only once for a
   Call and hence only once for the set of LSPs associated with a Call.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 13]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   The Notify message (see [RFC3473]) is used to signal the Call setup
   request and response. The new Call Management (C) bit in the
   ADMIN_STATUS object is used to indicate that this Notify is managing
   a Call. The Notify message is sent with source and destination
   IPv4/IPv6 addresses set to any of the routable ingress/egress node
   addresses respectively.

   At least one session MUST be listed in the <notify session list> of
   the Notify message. In order to allow for long identification of the
   Call, the SESSION_ATTRIBUTE object is added as part of the <notify
   session list>. Note that the ERROR SPEC object is not relevant in
   Call setup and MUST carry the Error Code zero ("Confirmation") to
   indicate that there is no error.

   During Call setup, the ADMIN STATUS object is sent with the following
   bits set. Bits not listed MUST be set to zero.

   R - to cause the egress to respond
   C - to indicate that the Notify message is managing a Call.

   The SESSION, SESSION ATTRIBUTE, SENDER_TEMPLATE, SENDER_TSPEC objects
   included in the <notify session> of the Notify message are built as
   follows.

   - The SESSION object includes as Tunnel_End_Point_Address any of the
     Call-terminating (egress) node's IPv4/IPv6 routable addresses. The
     Call_ID is set to a non-zero value unique within the context of
     the address pairing provided by the Tunnel_End_Point_Address and
     the Sender_Address from the SENDER TEMPLATE object (see below).
     This value will be used as the short Call ID carried on all
     messages for LSPs associated with this Call.

     Note that the Call_ID value of zero is reserved and MUST NOT be
     used since it will be present in SESSION objects of LSPs
     that are not associated with Calls. The Tunnel_ID of
     the SESSION object is not relevant for this procedure and SHOULD
     be set to zero. The Extended_Tunnel_ID of the SESSION object is
     not relevant for this procedure and MAY be set to zero or to an
     address of the ingress node.

   - The SESSION ATTRIBUTE object contains priority flags. Currently no
     use of these flags is envisioned, however, future work may
     identify value in assigning priorities to Calls; accordingly the
     Priority fields MAY be set to non-zero values. None of the Flags
     in the SESSION ATTRIBUTE object is relevant to this process and
     this field SHOULD be set to zero. The Session Name field is used
     to carry the long Call Id as described in Section 5.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 14]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   - The SENDER_TEMPLATE object includes as Sender Address any of the
     Call-initiating (ingress) node's IPv4/IPv6 routable addresses. The
     LSP_ID is not relevant and SHOULD be set to zero.

   - The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC
     objects MUST be ignored upon receipt and SHOULD be set to zero
     when sent.

   Additionally, ingress/egress nodes that need to communicate their
   respective link local capabilities may include a LINK_CAPABILITY
   object in the Notify message.

   The receiver of a Notify message may identify whether it is part of
   Call management or reporting an error by the presence or absence of
   the SESSION ATTRIUBTE object in the <notify session list>. Full
   clarity, however, may be achieved by inspection of the new Call
   Management (C) bit in the ADMIN STATUS object.

   Note that the POLICY_DATA object may be included in the <notify
   session list> and MAY be used to identify requestor credentials,
   account numbers, limits, quotas, etc. This object is opaque to RSVP,
   which simply passes it to policy control when required.

   Message IDs MUST be used during Call setup.

6.2.1 Accepting Call Setup

   A node that receives a Notify message carrying the ADMIN STATUS
   object with the R and C bits set is being requested to set up a Call.
   The receiver MAY perform authorization and policy according to local
   requirements.

   If the Call is acceptable, the receiver responds with a Notify
   message reflecting the information from the Call request with two
   exceptions.

   - The responder removes any LINK CAPABLITY object that was received
     and MAY insert a LINK_CAPABILITY object that describes its own
     access link.

   - The ADMIN STATUS object is sent with only the C bit set. All other
     bits MUST be set to zero.

   The responder MUST use the Message ID object to ensure reliable
   delivery of the response. If no Message ID Acknowledgement is
   received after the configured number of retries, the responder SHOULD
   continue to assume that the Call was successfully established. Call
   liveliness procedures are covered in Section 6.7.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 15]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

6.2.2 Call Setup Failure and Rejection

   Call setup may fail or be rejected.

   If the Notify message can not be delivered, no Message ID
   acknowledgement will be received by the sender. In the event that the
   sender has retransmitted the Notify message a configurable number of
   times without receiving a Message ID Acknowledgement (as described in
   [RFC2961]), the initiator SHOULD declare the Call failed and SHOULD
   send a Call teardown request (see Section 6.6).

   It is also possible that a Message ID Acknowledgement is received but
   no Call response Notify message is received. In this case, the
   initiator MAY re-send the Call setup request a configurable number of
   times (see Section 6.7) before declaring that the Call has failed. At
   this point the initiator MUST send a Call teardown request (see
   Section 6.6).

   If the Notify message cannot be parsed or is in error it MAY be
   responded to with a Notify message carrying the error code 13
   ("Unknown object class") or 14 ("Unknown object C-Type") if
   appropriate to the error detected.

   The Call setup MAY be rejected by the receiver because of security,
   authorization or policy reasons. Suitable error codes already exist
   [RFC2205] and can be used in the ERROR SPEC object included in the
   Notify message sent in response.

   Error response Notify messages SHOULD also use the Message ID object
   to achieve reliable delivery. No action should be taken on the
   failure to receive a Message ID Acknowledgement after the configured
   number of retries.

6.3 Adding a Connections to a Call

   Once a Call has been established, LSPs can be added to the Call.
   Since the short Call ID is part of the SESSION Object, any LSP that
   has the same Call ID value in the SESSION Object belongs to the same
   Call, and the Notify message used to establish the Call carried the
   same Call ID in its SESSION object.

   There will be no confusion between LSPs that are associated with a
   Call and those which are not, since the Call ID value MUST be equal
   to zero for LSPs which are not associated with a Call, and MUST NOT
   be equal to zero for a valid Call ID.

   LSPs for different Calls can be distinguished because the Call ID is
   unique within the context of the source address (in the SENDER
   TEMPLATE object) and the destination address (in the SESSION object).

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 16]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   Ingress and egress nodes MAY group together LSPs associated with the
   same Call and process them as a group according to implementation
   requirements. Transit nodes need not be aware of the association of
   multiple LSPs with the same Call.

   The ingress node MAY choose to set the "Session Name" of an LSP to
   match the long Call ID of the associated Call.

   The C bit of the ADMIN STATUS object MUST NOT be set on LSP messages
   including on Notify messages that pertain to the LSP and MUST be
   ignored.

6.3.1 Adding a Reverse Direction LSP to a Call

   Note that once a Call has been established it is symmetric. That is,
   either end of the Call may add LSPs to the Call.

   Special care is needed when managing LSPs in the reverse direction
   since the addresses in the SESSION and SENDER TEMPLATE are reversed.
   However, since the short Call ID is unique in the context of a given
   ingress-egress address pair it may safely be used to associate the
   LSP with the Call.

   Note that since Calls are defined here to be symmetrical, the issue
   of potential Call ID collision arises. This is discussed in Section
   6.5.

6.4 Call-Free Connection Setup

   It continues to be possible to set up LSPs as per [RFC3473] without
   associating them with a Call. If the short Call ID in the SESSION
   Object is set to zero, there is no associated Call and the Session
   Name field in the SESSION ATTRIBUTE object MUST be interpreted simply
   as the name of the session (see [RFC3209]).

   The C bit of the ADMIN STATUS object MUST NOT be set on messages for
   LSP control, including on Notify messages that pertain to LSPs, and
   MUST be ignored when received on such messages.

6.5 Call Collision

   Since Calls are symmetrical, it is possible that both ends of a Call
   will attempt to establish Calls with the same long Call IDs at the
   same time. This is only an issue if the source and destination
   address pairs match. This situation can be avoided by applying some
   rules to the contents of the long Call ID, but such mechanisms are
   outside the scope of this document.

   If a node that has sent a Call setup request and has not yet received
   a response, itself receives a Call setup request with the same long

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 17]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   Call ID and matching source/destination addresses, it SHOULD process
   as follows.

   - If its source address is numerically greater than the remote
     source address, it MUST discard the received message and continue
     to wait for a response to its setup request.

   - If its source address is numerically smaller than the remote
     source address, it MUST discard state associated with the Call
     setup that it initiated, and MUST respond to the received Call
     setup.

   If a node receives a Call setup request carrying an address pair and
   long Call ID that match an existing Call, the node MUST return an
   error message (Notify message) with the new Error Code "Call
   Management" and the new Error Value "Duplicate Call" in response to
   the new Call request, and MUST NOT make any changes to the existing
   Call.

   A further possibility for contention arises when short Call IDs are
   assigned by a pair of nodes for two distinct Calls that are set up
   simultaneously using different long Call IDs. In this event a node
   receives a Call setup request carrying a short Call ID that matches
   one that it previously sent for the same address pair. The following
   processing MUST be followed.

   - If the receiver's source address is numerically greater than the
     remote source address, the receiver returns an error (Notify
     message) with the new Error Code "Call Management" and the new
     Error Value "Call ID Contention".

   - If the receiver's source address is numerically less than the
     remote source address, the receiver accepts and processes the Call
     request. It will receive an error message sent as described above,
     and at that point it selects a new short Call ID and re-sends the
     Call setup request.

6.6 Call/Connection Teardown

   As with Call/Connection setup, there are several cases to consider.

   - Removal of a Connection from a Call
   - Removal of the last Connection from a Call
   - Teardown of an "empty" Call

   The case of tearing down an LSP that is not associated with a Call
   does not need to be examined as it follows exactly the procedures
   described in [RFC3473].

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 18]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

6.6.1 Removal of a Connection from a Call

   An LSP that is associated with a Call may be deleted using the
   standard procedures described in [RFC3473]. No special procedures are
   required.

   Note that it is not possible to remove an LSP from a Call without
   deleting the LSP. It is not valid to change the short Call ID from
   non-zero to zero since this involves a change to the SESSION object,
   which is not allowed.

6.6.2 Removal of the Last Connection from a Call

   When the last LSP associated with a Call is deleted, the question
   arises as to what happens to the Call. Since a Call may exist
   independently of Connections, it is not always acceptable to say that
   the removal of the last LSP from a Call removes the Call.

   The removal of the last LSP does not remove the Call and the
   procedures described in the next Section MUST be used to delete the
   Call.

6.6.3 Teardown of an "Empty" Call

   When all LSPs have been removed from a Call, the Call may be torn
   down or left for use by future LSPs.

   Deletion of Calls is achieved by sending a Notify message just as for
   Call setup, but the ADMIN STATUS object carries the R, D and C bits
   on the teardown request and the D and C bits on the teardown
   response. Other bits MUST be set to zero.

   When a Notify message is sent for deleting a Call and the initiator
   does not receive the corresponding reflected Notify message (or
   possibly even the Message ID Ack), the initiator MAY retry the
   deletion request using the same retry procedures as used during Call
   establishment. If no response is received after full retry, the node
   deleting the Call MAY declare the Call deleted, but under such
   circumstances the node SHOULD avoid re-using the long or short Call
   IDs for at least five times the Notify refresh period.

6.6.4 Attempted Teardown of a Call with Existing Connections

   If a Notify request with the D bit of the ADMIN STATUS object set is
   received for a Call for which LSPs still exist, the request MUST be
   rejected with the Error Code "Call Management" and Error Value
   "Connections Still Exist". The state of the Call MUST NOT be changed.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 19]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

6.6.5 Teardown of a Call from the Egress

   Since Calls are symmetric they may be torn down from the ingress or
   egress.

   When the Call is "empty" (has no associated LSPs) it may be deleted
   by the egress sending a Notify message just as described above.

   Note that there is a possibility that both ends of a Call initiate
   Call deletion at the same time. In this case, the Notify message
   acting as teardown request MAY be interpreted by its recipient as a
   teardown response. But since the Notify messages acting as teardown
   requests carry the R bit in the ADMIN STATUS object, they MUST be
   responded to anyway. If a teardown request Notify message is received
   for an unknown Call ID, it is, nevertheless, responded to in the
   affirmative.

6.7 Control Plane Survivability

   Delivery of Notify messages is secured using message ID
   acknowledgements as described in previous sections.

   Notify messages provide end-to-end communication that does not rely
   on constant paths through the network. Notify messages are routed
   according to IGP routing information. No consideration is, therefore,
   required for network resilience (for example, make-before-break,
   protection, fast re-route), although end-to-end resilience is of
   interest for node restart and completely disjoint networks.

   Periodic Notify messages SHOULD be sent by the initiator and
   terminator of the Call to keep the Call alive and to handle ingress
   or egress node restart. The time period for these retransmissions is
   a local matter, but it is RECOMMENDED that this period should be
   twice the shortest refresh period of any LSP associated with the
   Call. When there are no LSPs associated with a Call, an LSR is
   RECOMMENDED to use a refresh period of no less than one minute. The
   Notify messages are identical to those sent as if establishing the
   Call for the first time, except for the LINK_CAPABILITY object, which
   may have changed since the Call was first established, due to, e.g.,
   the establishment of Connections, link failures, or the addition of
   new component links. The current link information is useful for the
   establishment of subsequent Connections. A node that receives a
   refresh Notify message carrying the R bit in the ADMIN STATUS object
   MUST respond with a Notify response. A node that receives a refresh
   Notify message (response or request) MAY reset its timer - thus, in
   normal processing, Notify refreshes involve a single exchange once
   per time period.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 20]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   A node (sender or receiver) that is unsure of the status of a Call
   MAY immediately send a Notify message as if establishing the Call for
   the first time.

   Failure to receive a refresh Notify request has no specific meaning.
   A node that fails to receive a refresh Notify request MAY send its
   own refresh Notify request to establish the status of the Call. If a
   node receives no response to a refresh Notify request (including no
   Message ID Acknowledgement) a node MAY assume that the remote node is
   unreachable or unavailable. It is a local policy matter whether this
   causes the local node to teardown associated LSPs and delete the
   Call.

   In the event that an edge node restarts without preserved state, it
   MAY relearn LSP state from adjacent nodes and Call state from remote
   nodes. If a Path or Resv message is received with a non-zero Call ID
   but without the C bit in the ADMIN STATUS, and for a Call ID that is
   not recognized, the receiver is RECOMMENDED to assume that the Call
   establishment is delayed and ignore the received message. If the Call
   setup never materializes, the failure by the restarting node to
   refresh state will cause the LSPs to be torn down. Optionally, the
   receiver of such an LSP message for an unknown Call ID may return an
   error (PathErr or ResvErr message) with the error code "Call
   Management" and Error Value "Unknown Call ID".

7. Applicability of Call and Connection Procedures

   This section considers the applicability of the different Call
   establishment procedures at the NNI and UNI reference points. This
   section is informative and is not intended to prescribe or prevent
   other options.

7.1 Network-initiated Calls

   Since the link properties and other traffic-engineering attributes
   are likely known through the IGP, the LINK_CAPABILITY object is not
   usually required.

   In multi-domain networks, it is possible that access link properties
   and other traffic-engineering attributes are not known since the
   domains do not share this sort of information. In this case, the Call
   setup mechanism may include the LINK_CAPABILITY object.

7.2 User-initiated Calls

   It is possible that the access link properties and other traffic-
   engineering attributes are not shared across the core network. In
   this case, the Call setup mechanism may include the LINK_CAPABILITY
   object.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 21]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   Further, the first node within the network may be responsible for
   managing the Call. In this case, the Notify message that is used to
   set up the Call is addressed by the user network edge node to the
   first node of the core network. Moreover, neither the long Call ID
   nor the short Call ID is supplied (the Session Name Length is set to
   zero and the Call ID value is set to zero). The Notify message is
   passed to the first network node which is responsible for generating
   the long and short Call IDs before dispatching the message to the
   remote Call end point (which is known from the SESSION object).

   Further, when used in an overlay context, the first core node is
   allowed (see [RFC4208]) to replace the Session Name assigned by the
   ingress node and passed in the Path message. In the case of Call
   management, the first network node:
    1) MAY insert a long Call ID in the Session Name of a Path message
    2) MUST replace the Session Name with that originally issued by the
   user edge node when it returns the Resv message to the ingress node.

7.3 External Call Managers

   Third party Call management agents may be used to apply policy and
   authorization at a point that is neither the initiator nor terminator
   of the Call. The previous example is a particular case of this, but
   the process and procedures are identical.

7.3.1 Call Segments

   Call Segments exist between a set of default and configured External
   Call Managers along a path between the ingress and egress nodes, and
   use the protocols described in this document.

   The techniques that are used by a given service provider to identify
   which External Call Managers within its network should process a
   given Call are beyond the scope of this document.

   An External Call Manager uses normal IP routing to route the Notify
   message to the next External Call Manager. Notify messages (requests
   and responses) are therefore encapsulated in IP packets that identify
   the sending and receiving External Call Managers, but the addresses
   used to identify the Call (the Sender Address in the SENDER TEMPLATE
   object and the Tunnel Endpoint Address in the SESSION object)
   continue to identify the endpoints of the Call.

8. Non-support of Call ID

   It is important that the procedures described above operate as
   seamlessly as possible with legacy nodes that do not support the
   extensions described.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 22]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   Clearly, there is no need to consider the case where the Call
   initiator does not support Call setup initiation.

8.1 Non-Support by External Call Managers

   It is unlikely that a Call initiator will be configured to send Call
   establishment Notify requests to an external Call manager, including
   the first network node, if that node does not support Call setup.

   A node that receives an unexpected Call setup request will fall into
   one of the following categories.

   - Node does not support RSVP. The message will fail to be delivered
     or responded. No Message ID Acknowledgement will be sent. The
     initiator will retry and then give up.

   - Node supports RSVP or RSVP-TE but not GMPLS. The message will be
     delivered but not understood. It will be discarded. No Message ID
     Acknowledgement will be sent. The initiator will retry and then
     give up.

   - Node supports GMPLS but not Call management. The message will be
     delivered, but parsing will fail because of the presence of the
     SESSION ATTRIBUTE object. A Message ID Acknowledgement may be sent
     before the parse fails. When the parse fails the Notify message
     may be discarded in which case the initiator will retry and then
     give up, alternatively a parse error may be generated and returned
     in a Notify message which will indicate to the initiator that Call
     management is not supported.

8.2 Non-Support by Transit Node

   Transit nodes SHOULD not examine Notify messages that are not
   addressed to them. However, they will see short Call IDs in all LSPs
   associated with Calls.

   Previous specifications state that these fields SHOULD be ignored on
   receipt and MUST be transmitted as zero. This is interpreted by some
   implementations as meaning that the fields should be zeroed before
   the objects are forwarded. If this happens, LSP setup will not be
   possible. If either of the fields is zeroed either on the Path or the
   Resv message, the Resv message will reach the initiator with the
   field set to zero - this is indication to the initiator that some
   node in the network is preventing Call management. Use of Explicit
   Routes may help to mitigate this issue by avoiding such nodes.
   Ultimately, however, it may be necessary to upgrade the offending
   nodes to handle these protocol extensions.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 23]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

8.3 Non-Support by Egress Node

   It is unlikely that an attempt will be made to set up a Call to
   remote node that does not support Calls.

   If the egress node does not support Call management through the
   Notify message it will react (as described in Section 8.1) in the
   same way as an External Call Manager.

9. Security Considerations

   Please refer to each of the referenced documents for a description of
   the security considerations applicable to the features that they
   provide.

9.1 Call and Connection Security Considerations

   Call setup is vulnerable to attacks both of spoofing and denial of
   service. Since Call setup uses Notify messages, the process can be
   protected by the measures applicable to securing those messages as
   described in [RFC3473].

   Note, additionally, that the process of independent Call
   establishment, where the Call is set up separately from the LSPs, may
   be used to apply an extra level of authentication and policy for the
   end-to-end LSPs above that which is available with Call-less,
   hop-by-hop LSP setup. It may be possible to protect the Call setup
   exchange using end-to-end security mechanisms such as those provided
   by IPsec (see [RFC2402] and [RFC2406]).

   The frequency of Call establishment is application dependent and hard
   to generalize. Key exchange for Call-related message exchanges is
   therefore something that should be configured or arranged dynamically
   in different deployments according to the advice in [RFC4107]. Note
   that the remote RSVP-TE signaling relationship between Call endpoints
   is no different from the signaling relationship between LSRs that
   establish an LSP. That is, the LSRs are not necessarily IP-adjacent
   in the control plane in either case. Thus key exchange should be
   regarded as a remote procedure, not a single hop procedure. There are
   several procedures for automatic remote exchange of keys, and IKE
   [RFC2409] is particularly suggested in [RFC3473].

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 24]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

10. IANA Considerations

10.1 RSVP Objects

   A new RSVP object is introduced:

   o  LINK_CAPABILITY object

      Class-Num =3D TBA (form 10bbbbbb)

      The Class Number is selected so that nodes not recognizing
      this object drop it silently. That is, the top bit is set
      and the next bit is cleared.

      C-Type =3D 1 (TE Link Capabilities)

      The LINK_CAPABILITY object is only defined for inclusion on Notify
      messages.

      Refer to Section 5.3 of this document.

10.2 RSVP Error Codes and Error Values

   New RSVP Error Codes and Error Values are introduced

   o  Error Codes:

      - Call Management (value TBA)

   o  Error Values:

      - Call Management/Call ID Contention      (value TBA)
      - Call Management/Connections still Exist (value TBA)
      - Call Management/Unknown Call ID         (value TBA)
      - Call Management/Duplicate Call          (value TBA)

10.3 RSVP ADMIN_STATUS object Bits

   [GMPLS-E2E] requests IANA to manage the bits of the RSVP ADMIN_STATUS
   object.

   One new bit, the C bit, is defined in this document. Bit number 28 is
   suggested.

   See Section 5.5 of this document.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 25]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

11. Acknowledgements

   The authors would like to thank George Swallow, Yakov Rekhter,
   Lou Berger, Jerry Ash and Kireeti Kompella for their very useful
   input to, and comments on, an earlier revision of this document.

   Thanks to Lyndon Ong and Ben Mack-Crane for lengthy discussions
   during and after working group last call, and to Deborah Brungard for
   a final, detailed review.

12. References

12.1 Normative References

   [GMPLS-E2E]   Lang, J.P., Rekhter, Y., and D. Papadimitriou, "RSVP-
                 TE Extensions in support of End-to-End Generalized
                 Multi-Protocol Label Switching (GMPLS)-based Recovery,"
                 draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in
                 progress.

   [RFC2119]     S. Bradner, "Key words for use in RFCs to Indicate
                 Requirement Levels," BCP 14, RFC 2119, March 1997.

   [RFC2205]     R. Braden et al., "Resource ReSerVation Protocol
                 (RSVP)- Version 1 Functional Specification,"
                 RFC 2205, September 1997.

   [RFC2402]     Kent, S. and R. Atkinson, "IP Authentication Header,"
                 RFC 2402, November 1998.

   [RFC2406]     Kent, S. and R. Atkinson, "IP Encapsulating Payload
                 (ESP)," RFC 2406, November 1998.

   [RFC2409]     Harkins, D. and D. Carrel, "The Internet Key Exchange
                 (IKE)", RFC 2409, November 1998.

   [RFC2747]     Baker, F., Lindell, B. and M. Talwar, "RSVP
                 Cryptographic Authentication", RFC 2747, January
                 2000.

   [RFC2961]     Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
                 F. and S. Molendini, "RSVP Refresh Overhead
                 Reduction Extensions", RFC 2961, April 2001.

   [RFC3209]     D. Awduche et al., "RSVP-TE: Extensions to RSVP for
                 LSP Tunnels," RFC 3209, December 2001.

   [RFC3471]     L. Berger (Editor) et al., "Generalized MPLS -
                 Signaling Functional Description," RFC 3471, January
                 2003.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 26]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   [RFC3473]     L. Berger (Editor) et al., "Generalized MPLS Signaling
                 - RSVP-TE Extensions," RFC 3473, January 2003.

   [RFC3477]     Kompella, K. and Y. Rekhter, "Signalling Unnumbered
                 Links in Resource ReSerVation Protocol - Traffic
                 Engineering (RSVP-TE)," RFC 3477, January 2003.

   [RFC3945]     E. Mannie, Ed., "Generalized Multi-Protocol Label
                 Switching (GMPLS) Architecture", RFC 3945, October
                 2004.

   [RFC4139]     D. Papadimitriou, et al., "Requirements for Generalized
                 MPLS (GMPLS) Signaling Usage and Extensions for
                 Automatically Switched Optical Network (ASON)," RFC
                 4139, July 2005.

   [RFC4201]     Kompella K., Rekhter Y., and L. Berger, "Link Bundling
                 in MPLS Traffic Engineering," RFC 4201, October 2005.

   [RFC4202]     Kompella, K. and Y. Rekhter (Editors) et al., "Routing
                 Extensions in Support of Generalized MPLS," RFC 4202,
                 October 2005.

   [RFC4208]     Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y.
                 "Generalized Multiprotocol Label Switching (GMPLS)
                 User-Network Interface (UNI): Resource ReserVation
                 Protocol-Traffic Engineering (RSVP-TE) Support for the
                 Overlay Model", RFC 4208, October 2005.

   [RFC4426]     Lang, J.P., and B. Rajagopalan (Editors) et al.,
                 "Generalized MPLS Recovery Functional
                 Specification," RFC 4426, March 2006.

12.2 Informative References

   [ASON-APPL]   D. Papadimitriou et. al., "Generalized MPLS (GMPLS)
                 RSVP-TE signaling usage in support of Automatically
                 Switched Optical Network (ASON),"
                 draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progress.

   [RFC4107]     S. Bellovin and R. Housley, "Guidelines for
                 Cryptographic Key Management", BCP 107, RFC 4107, June
                 2005.

   For information on the availability of the following document,
   please see http://www.itu.int.

   [G.8080]      ITU-T, "Architecture for the Automatically Switched
                 Optical Network (ASON)," Recommendation G.8080/
                 Y.1304, November 2001 (and Revision, January 2003).

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 27]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

13. Authors' Addresses

   Dimitri Papadimitriou (Alcatel)
   Fr. Wellesplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 240-8491
   EMail: [email-masked]

   John Drake
   Boeing Satellite Systems
   2300 East Imperial Highway
   El Segundo, CA 90245
   EMail: [email-masked]

   Adrian Farrel
   Old Dog Consulting
   Phone: +44 (0) 1978 860944
   EMail: [email-masked]

   Deborah Brungard (AT&T)
   Rm. D1-3C22 - 200 S. Laurel Ave.
   Middletown, NJ 07748, USA
   EMail: [email-masked]

   Zafar Ali (Cisco)
   100 South Main St. #200
   Ann Arbor, MI 48104, USA
   EMail: [email-masked]

   Arthi Ayyangar (Nuova Systems)
   2600 San Tomas Expressway
   Santa Clara, CA 95051
   EMail: [email-masked]

   Don Fedyk (Nortel Networks)
   600 Technology Park Drive
   Billerica, MA, 01821, USA
   Email: [email-masked]

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 28]
=0C
Papadimitriou and Farrel - Expires February 2007             August 2006

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt                     [Page 29]
=0C

------=_NextPart_000_0545_01C6BE23.A76B2EB0--

Delivery-date: Fri, 11 Aug 2006 10:25:19 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Two new communications from the OIF
Date: Fri, 11 Aug 2006 11:23:27 +0100
Organization: Old Dog Consulting

Hi,

We have received two new communications from the OIF from their recent 
meeting and in response to our communications on the OIF E-NNI and on 
Ethernet traffic parameters. The latter asks a question of us, to which we 
need to respond.

There appears to be no response to either of our communications on 
draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt and on 1:n protection.

We still owe our thoughts on the OIF's interworking document so we should do 
four things:

1. Answer the Ethernet traffic parameters question
2. Poll to find out whether the OIF has any input on
   draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt, pointing out
   that the 01 revision is available
3. Poll on 1:n protection to see if we answered all of the questions
    satisfactorily
4. Send a response on OIF interworking

As usual, input is welcome on the list or privately. Deborah and I will post 
draft text when we have it.

I will post the two incoming communications at 
http://www.olddog.co.uk/incoming.htm

Thanks,
Adrian

Delivery-date: Thu, 10 Aug 2006 05:29:04 +0000
Content-class: urn:content-classes:message
Subject: RE: Montreal draft minutes posted
Date: Thu, 10 Aug 2006 01:27:08 -0400
From: "Zafar Ali \(zali\)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Jean Philippe Vasseur \(jvasseur\)" <[email-masked]>, "Anca Zamfir \(ancaz\)" <[email-masked]>

Hi Adrian,=20

Towards the end of the meeting I requested you to pool WG on
draft-ali-ccamp-mpls-graceful-shutdown-04.txt, to become a WG Doc and
you gave me an AI to remind you of this  via email. Please consider this
email as a follow-up on my action item, and an updates to the minutes.=20

Just a bit of back ground,=20

Before IETF/ Montreal, we posted an updated version of the Graceful
Shutdown draft (draft-ali-ccamp-mpls-graceful-shutdown-04.txt). In this
version we have addressed comments from Adrian, Dimitri, et al during
the WG meeting and have removed use of link-attribute sub-TLV from this
ID. The ID now makes use of (MAX-METRIC, 0 bandwidth) for communicating
graceful shutdown condition in IGP.=20
=20
In the following steps recommended for this ID in the WG meeting IETF/
65 in Dallas, TX (copied from the WG minutes):=20
=20
Zafar: What about graceful shutdown? Support for WG draft?
Kireeti: Graceful link shutdown to WG draft?
Small show of hands
No-one against
Dimitri: If the graceful link shutdown has the routing part fixed the
         support will be much greater
Kireeti: We'll do a poll on the list after the fixes.

We believe we have addressed the above mentioned condition from the WG
chairs. We will appreciate if you can ask the WG to accept this ID as a
WG doc (as part of other documents that you may have planned to pool
for).=20

Thanks
=20
Regards... Zafar=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Tuesday, August 01, 2006 12:51 PM
> To: [email-masked]
> Subject: Montreal draft minutes posted
>=20
> http://www3.ietf.org/proceedings/06jul/minutes/ccamp.htm
>=20
> Please review.
>=20
> Apologies for the delay which is all my fault.
>=20
> Thanks to the note takers and to Deborah for compiling the minutes.
>=20
> Adrian
>=20

Envelope-to: [email-masked]
Delivery-date: Mon, 07 Aug 2006 20:14:33 +0000
To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'Generalized Multiprotocol Label Switching (GMPLS) Label  Switching Router (LSR) Management Information Base' to Proposed  Standard (draft-ietf-ccamp-gmpls-lsr-mib) 
Reply-To: [email-masked]
Cc: <[email-masked]>
Message-Id: <[email-masked]>
Date: Mon, 07 Aug 2006 16:12:50 -0400

The IESG has received a request from the Common Control and Measurement Plane 
WG to consider the following documents:

- 'Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering 
   Management Information Base '
   <draft-ietf-ccamp-gmpls-te-mib-15.txt> as a Proposed Standard
- 'Definitions of Textual Conventions for Generalized Multiprotocol Label 
   Switching (GMPLS) Management '
   <draft-ietf-ccamp-gmpls-tc-mib-10.txt> as a Proposed Standard
- 'Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router 
   (LSR) Management Information Base '
   <draft-ietf-ccamp-gmpls-lsr-mib-14.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-08-21.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-15.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-14.txt

Delivery-date: Fri, 04 Aug 2006 08:02:06 +0000
To: [email-masked]
Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt
From: [email-masked]
Date: Fri, 4 Aug 2006 09:59:54 +0200

this version incorporates comments received on the list, discussion during 
ietf meeting and other improvements to facilitate reading (thanks for 
people having commented publicly or privately such as to improve quality 
of the doc)

o) section 5

   . clarify processing of router_address TLV

   . clarify processing of link_id sub-TLV

o) section 6

   . re-worked structure of the text 

   . detail relationship between OSPF area and ASON RA (section 6)

   . specific section detailing import/export rules (section 6.1)

   . split discovery and selection section for downward/upward (section 
6.2.1 and section 6.2.2, resp.)

   . for the former (downward) renamed Associated Area ID as Downstream 
Associated Area ID (more suitable and prevents confusion w/ Section 6.3 
Associated Area ID sub-TLV)

   . detail scope of loop prevention (section 6.3)

   . figures have been revisited to prevent confusion with ABR 
functionality (section 6.3)

   . new section 6.4 (resiliency) 

   . new section 6.5 (adjacency)

-d.

----- Forwarded by Dimitri PAPADIMITRIOU/BE/ALCATEL on 04/08/2006 09:44 
-----

[email-masked]
04/08/2006 00:50
Please respond to internet-drafts
 
        To:     [email-masked]
        cc:     [email-masked]
        Subject:        I-D 
ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane 
Working Group of the IETF.

                 Title                           : OSPFv2 Routing Protocol 
Extensions for ASON Routing
                 Author(s)               : D. Papadimitriou
                 Filename                : 
draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt
                 Pages                           : 0
                 Date                            : 2006-8-3
 
The Generalized MPLS (GMPLS) suite of protocols has been defined to 
   control different switching technologies as well as different 
   applications. These include support for requesting TDM connections 
   including SONET/SDH and Optical Transport Networks (OTNs). 
 
   This document provides the extensions of the OSPFv2 Link State 
   Routing Protocol to meet the routing requirements for an 
   Automatically Switched Optical Network (ASON) as defined by ITU-T.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the 
message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
                 "get draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
                 [email-masked].
In the body type:
                 "FILE 
/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt".
 
NOTE:            The mail server at ietf.org can return the document in
                 MIME-encoded form by using the "mpack" utility.  To use 
this
                 feature, insert the command "ENCODING mime" before the 
"FILE"
                 command.  To decode the response(s), you will need 
"munpack" or
                 a MIME-compliant mail reader.  Different MIME-compliant 
mail readers
                 exhibit different behavior, especially when dealing with
                 "multipart" MIME messages (i.e. documents which have been 
split
                 up into multiple messages), so check your local 
documentation on
                 how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://[email-masked]/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

Delivery-date: Thu, 03 Aug 2006 22:52:02 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt 
Date: Thu, 03 Aug 2006 18:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: OSPFv2 Routing Protocol Extensions for ASON Routing
	Author(s)	: D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt
	Pages		: 0
	Date		: 2006-8-3
	
The Generalized MPLS (GMPLS) suite of protocols has been defined to 
   control different switching technologies as well as different 
   applications. These include support for requesting TDM connections 
   including SONET/SDH and Optical Transport Networks (OTNs). 
    
   This document provides the extensions of the OSPFv2 Link State 
   Routing Protocol to meet the routing requirements for an 
   Automatically Switched Optical Network (ASON) as defined by ITU-T.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 01 Aug 2006 16:53:08 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Montreal draft minutes posted
Date: Tue, 1 Aug 2006 17:50:47 +0100
Organization: Old Dog Consulting

http://www3.ietf.org/proceedings/06jul/minutes/ccamp.htm

Please review.

Apologies for the delay which is all my fault.

Thanks to the note takers and to Deborah for compiling the minutes.

Adrian