Subject: GMPLS MIBs
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Tim Hall" <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, "Cheenu Srinivasan" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "Edward Harrison" <[email-masked]>
Date: Fri, 29 Aug 2003 22:16:13 +0100

All I have just posted an update to the GMPLS MIB modules.
The model followed is to extend the MPLS MIB modules.

At the moment the drafts are VERY rough, but we wanted to publish them so that the WG can
see the direction we are taking and comment accordingly. In particular:
- no attempt at compilation has yet been made
- the introductory text and examples lags behind the actual ASN.1
- there is a list of work items at the end of the LSR and TE documents.

We would welcome all thoughts great and small (although there is little point in telling
us about nits at this stage).

The drafts are:

draft-ietf-ccamp-gmpls-tc-mib-01.txt  containing textual conventions

draft-ietf-ccamp-gmpls-lsr-mib-01.txt containing extensions to the
MPLS LSR MIB module and defining a GMPLS Label Table

draft-ietf-ccamp-gmpls-te-mib-01.txt containing extensions to the
MPLS TE MIB.

Our plans are to consolidate these drafts considerably in the next month, hopefully
completing all of the work items.

Thanks,
Adrian

Delivery-date: Fri, 29 Aug 2003 19:19:18 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-01.txt
Date: Fri, 29 Aug 2003 15:14:59 -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		: Definitions of Textual Conventions for Generalized 
                          Multi-Protocol Label Switching (GMPLS) Management
	Author(s)	: T. Nadeau et al.
	Filename	: draft-ietf-ccamp-gmpls-tc-mib-01.txt
	Pages		: 8
	Date		: 2003-8-29
	
This document defines a Management Information Base (MIB) module
which contains Textual Conventions to represent commonly used
Generalized Multi-Protocol Label Switching (GMPLS) management
information. The intent is that these TEXTUAL CONVENTIONS (TCs) will
be imported and used in GMPLS related MIB modules that would
otherwise define their own representations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-tc-mib-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-tc-mib-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-tc-mib-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-tc-mib-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: Fri, 29 Aug 2003 16:12:07 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-01.txt
Date: Fri, 29 Aug 2003 11:30:56 -0400

--MIMEStream=_0+274705_2989368210246_3856897809

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 Multiprotocol Label Switching (GMPLS) 
                          Label Switch Router Management Information Base
	Author(s)	: T. Nadeau et al.
	Filename	: draft-ietf-ccamp-gmpls-lsr-mib-01.txt
	Pages		: 31
	Date		: 2003-8-29
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects to configure and/or
monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
Switching Router (LSRs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

--MIMEStream=_0+274705_2989368210246_3856897809
Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+19839_0379379382648_47572732309"

--MIMEStream=_1+19839_0379379382648_47572732309
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-lsr-mib-01.txt

--MIMEStream=_1+19839_0379379382648_47572732309
Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"

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

--MIMEStream=_1+19839_0379379382648_47572732309--
--MIMEStream=_0+274705_2989368210246_3856897809--

Delivery-date: Fri, 29 Aug 2003 16:10:20 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-01.txt
Date: Fri, 29 Aug 2003 11:31:01 -0400

--MIMEStream=_0+282145_06432103712882_4854742671

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 Multiprotocol Label Switching (GMPLS) 
                          Traffic Engineering Management Information Base
	Author(s)	: T. Nadeau et al.
	Filename	: draft-ietf-ccamp-gmpls-te-mib-01.txt
	Pages		: 42
	Date		: 2003-8-29
	
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet community.  In particular, it describes managed objects
for Generalized Multiprotocol Label Switching (GMPLS) based traffic
engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

--MIMEStream=_0+282145_06432103712882_4854742671
Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+276009_92189351116811_8008680272"

--MIMEStream=_1+276009_92189351116811_8008680272
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-te-mib-01.txt

--MIMEStream=_1+276009_92189351116811_8008680272
Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"

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

--MIMEStream=_1+276009_92189351116811_8008680272--
--MIMEStream=_0+282145_06432103712882_4854742671--

Delivery-date: Fri, 29 Aug 2003 15:34:12 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-01.txt
Date: Fri, 29 Aug 2003 11:30:52 -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		: Definitions of Textual Conventions for Generalized 
                          Multi-Protocol Label Switching (GMPLS) Management
	Author(s)	: T. Nadeau et al.
	Filename	: draft-ietf-ccamp-gmpls-tc-mib-01.txt
	Pages		: 8
	Date		: 2003-8-29
	
This document defines a Management Information Base (MIB) module
which contains Textual Conventions to represent commonly used
Generalized Multi-Protocol Label Switching (GMPLS) management
information. The intent is that these TEXTUAL CONVENTIONS (TCs) will
be imported and used in GMPLS related MIB modules that would
otherwise define their own representations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-tc-mib-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-tc-mib-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-tc-mib-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-tc-mib-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: Fri, 29 Aug 2003 15:33:50 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-01.txt
Date: Fri, 29 Aug 2003 11:31:01 -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 Multiprotocol Label Switching (GMPLS) 
                          Traffic Engineering Management Information Base
	Author(s)	: T. Nadeau et al.
	Filename	: draft-ietf-ccamp-gmpls-te-mib-01.txt
	Pages		: 42
	Date		: 2003-8-29
	
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet community.  In particular, it describes managed objects
for Generalized Multiprotocol Label Switching (GMPLS) based traffic
engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-te-mib-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-te-mib-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-te-mib-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-te-mib-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: Fri, 29 Aug 2003 15:33:38 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-01.txt
Date: Fri, 29 Aug 2003 11:30:56 -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 Multiprotocol Label Switching (GMPLS) 
                          Label Switch Router Management Information Base
	Author(s)	: T. Nadeau et al.
	Filename	: draft-ietf-ccamp-gmpls-lsr-mib-01.txt
	Pages		: 31
	Date		: 2003-8-29
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects to configure and/or
monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
Switching Router (LSRs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-lsr-mib-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-lsr-mib-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-lsr-mib-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-lsr-mib-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: Thu, 28 Aug 2003 20:57:54 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Cc: "Ccamp-wg (E-mail)" <[email-masked]>, "Alex Zinin (E-mail)" <[email-masked]>
Subject: Pls remove doc: http://www.ietf.org/internet-drafts/draft-ietf-cc amp-gmpls-sonet-sdh-extensions-03.txt
Date: Thu, 28 Aug 2003 22:53:36 +0200

This document expired Last December. pls make it indeed expire

The doc describes signalling for a technology for which no-one
in the WG has been able or willing to give ptrs to documents
that describe the technology being signalled. 
Since we do not have ptrs to such documents, it seems nonsense
to try and standardize the signalling for it.

The WG was polled many times to provide ptrs to such documentation.
I believe the WG chairs are OK with this too.

So that means:
 - remove doc from ID-repository
 - remove doc from CCAMP wg charter page.

Thanks,
Bert 

Delivery-date: Wed, 27 Aug 2003 09:33:46 +0000
From: Nurit Sprecher <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, Nurit Sprecher <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
Date: Wed, 27 Aug 2003 12:28:07 +0200

Hi Kireeti,
Thanks for responding me.
You say: "If the BE LSPs require zero bandwidth, then I don't see a reason
to prevent them being set up".
My question relates to section 4, on the implications on graceful restart.
 I am talking about a case of a planned restart, where a restarting node
follows the OSPF graceful restart procedures. The control plane is
restarting and the node is unable to react to Path requests.  Therefore, the
Path request will not be 'acknowledged' and a PathErr message will be
returned. 

How can we discourage the establishment of new BE LSPs via the restarting
router to avoid the setup failure?

Thanks in advance, Nurit.

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Monday, August 25, 2003 6:29 PM
To: Nurit Sprecher
Cc: [email-masked]'
Subject: Re: draft-ietf-ccamp-ospf-gmpls-extensions-09.txt

Hi Nurit,

> My question relates to BE (best effort) LSPs. Advertising the links as
fully
> utilized would not discourage the establishment of new BE LSPs via the
> restarting router.

What is the reasoning for this?

If the BE LSPs require zero bandwidth, then I don't see a reason to
prevent them being set up.

Kireeti.

Delivery-date: Mon, 25 Aug 2003 22:41:36 +0000
From: Michael Mandelberg <[email-masked]>
To: [email-masked]
Subject: Repost: Label Set question
Date: Mon, 25 Aug 2003 18:35:21 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C36B59.2AFE0DE0
Content-Type: text/plain;
	charset="windows-1255"

-----Original Message-----
From: Michael Mandelberg 
Sent: Monday, August 04, 2003 8:51 PM
To: [email-masked]
Subject: Label Set question

How does the label set work with waveband labels? For the list form, are the
subobjects waveband ids, or are the start and stop values listed as well?
For the range form, again is it just ids? If not, then how is ordering
defined to deterimine whether another band laebl is within the range?  In
other words, how do the start and stop labels figure into the ordering
function?
 
Thanks
 
Michael Mandelberg

------_=_NextPart_001_01C36B59.2AFE0DE0
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">

<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR>
<META content=3D"Microsoft Word 9" name=3DOriginator><LINK=20
href=3D"cid:[email-masked]" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt =
72.0pt 90.0pt; mso-header-margin: 35.4pt; mso-footer-margin: 35.4pt; =
mso-paper-source: 0; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
P.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
LI.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
DIV.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Courier New"
}
SPAN.EmailStyle15 {
	COLOR: black; mso-style-type: personal-compose; mso-ansi-font-size: =
10.0pt; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; =
mso-bidi-font-family: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: 36.0pt">
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Michael =
Mandelberg=20
  <BR><B>Sent:</B> Monday, August 04, 2003 8:51 PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Label Set =
question<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D656514501-05082003><FONT color=3D#000000><FONT =
size=3D2>How does=20
  the label set work with waveband labels? For the list form, are the =
subobjects=20
  waveband ids, or are the start and stop values listed as well? For =
the range=20
  form, again is it just ids? If not, then how is ordering defined to =
deterimine=20
  whether another band laebl is within the range?<FONT =
color=3D#0000ff><SPAN=20
  class=3D781223222-25082003>&nbsp;&nbsp;</SPAN><SPAN=20
  class=3D781223222-25082003>In&nbsp;other words, how do the start and =
stop labels=20
  figure into the ordering =
function?</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D656514501-05082003><FONT =
size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D656514501-05082003><FONT =
size=3D2>Thanks</FONT></SPAN></DIV>
  <DIV><SPAN class=3D656514501-05082003><FONT =
size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D656514501-05082003><FONT size=3D2>Michael=20
  Mandelberg</FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C36B59.2AFE0DE0--

Delivery-date: Mon, 25 Aug 2003 16:32:38 +0000
Date: Mon, 25 Aug 2003 09:29:24 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Nurit Sprecher <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: draft-ietf-ccamp-ospf-gmpls-extensions-09.txt

Hi Nurit,

> My question relates to BE (best effort) LSPs. Advertising the links as fully
> utilized would not discourage the establishment of new BE LSPs via the
> restarting router.

What is the reasoning for this?

If the BE LSPs require zero bandwidth, then I don't see a reason to
prevent them being set up.

Kireeti.

Delivery-date: Mon, 25 Aug 2003 09:14:04 +0000
From: Nurit Sprecher <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
Date: Mon, 25 Aug 2003 12:10:00 +0200

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C36AF1.0B240B40
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
I have a question regarding section 4, on the implications on graceful
restart.
=20
In a case of a planned restart, a restarting node that follows the OSPF
graceful restart procedures, should advertise its links, prior to the
restart operation, as fully utilized. Existing LSPs would not be =
affected by
this update. However, this would discourage new TE LSPs=92 =
establishment
through the restarting router.=20
=20
My question relates to BE (best effort) LSPs. Advertising the links as =
fully
utilized would not discourage the establishment of new BE LSPs via the
restarting router. How can we discourage the establishment of new BE =
LSPs?=20
=20
Thanks in advance, Nurit.=20
=20
=20
=20
  =20
=20
  =20

------_=_NextPart_001_01C36AF1.0B240B40
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Arial Unicode MS";
	mso-font-alt:Tahoma;
	mso-font-charset:128;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-1 -369098753 63 0 4129023 0;}
@font-face
	{font-family:"\@Arial Unicode MS";
	mso-font-charset:128;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-1 -369098753 63 0 4129023 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Arial Unicode MS";}
span.EmailStyle15
	{mso-style-type:personal-compose;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:black;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal style=3D'text-align:justify'><span =
class=3DEmailStyle15><font
size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
mso-ansi-font-size:12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:
"Times New Roman";mso-bidi-font-family:"Times New =
Roman"'>Hi,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'text-align:justify'><span =
class=3DEmailStyle15><font
size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
mso-ansi-font-size:12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:
"Times New Roman";mso-bidi-font-family:"Times New Roman"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal style=3D'text-align:justify'><span =
class=3DEmailStyle15><font
size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
mso-ansi-font-size:12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:
"Times New Roman";mso-bidi-font-family:"Times New Roman"'>I have a =
question regarding
section 4, on the </span></font></span><font color=3Dblack><span
style=3D'color:black'>implications on graceful =
restart.</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'text-align:justify'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span style=3D'color:black;mso-color-alt:windowtext'><o:p>=
</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-align:justify'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>In a case of
a planned restart, a restarting node that follows the OSPF graceful =
restart
procedures, should advertise its links, prior to the restart operation, =
as
fully utilized. Existing LSPs would not be affected by this update. =
However, this
would discourage new TE LSPs=92 establishment through the restarting =
router. </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'text-align:justify'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'text-align:justify'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>My question
relates to BE (best effort) LSPs. Advertising the links as fully =
utilized would
not discourage the establishment of new BE LSPs via the restarting =
router. How
can we discourage the establishment of new BE LSPs? </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'text-align:justify'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'text-align:justify'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>Thanks in
advance, Nurit. </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-align:justify'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'text-align:justify'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'text-align:justify'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'text-align:justify'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><span
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </span></span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'text-align:justify'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'text-align:justify'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><span
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </span><span =
class=3DEmailStyle15><font
color=3Dblack><span =
style=3D'mso-ansi-font-size:12.0pt;mso-ascii-font-family:"Times New =
Roman";
mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New =
Roman"'><o:p></o:p></span></font></span></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C36AF1.0B240B40--

Delivery-date: Mon, 18 Aug 2003 15:16:42 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-02.txt
Date: Mon, 18 Aug 2003 11:13:58 -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		: Requirements for Generalized MPLS (GMPLS) Signaling 
                          Usage and Extensions for Automatically Switched 
                          Optical Network (ASON)
	Author(s)	: D. Papadimitriou et al.
	Filename	: draft-ietf-ccamp-gmpls-ason-reqts-02.txt
	Pages		: 13
	Date		: 2003-8-18
	
The Generalized MPLS (GMPLS) suite of protocol 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 concentrates on the signaling aspects of the GMPLS
suite of protocols. It identifies the features to be covered by the
GMPLS signalling protocol to support the capabilities of an
Automatically Switched Optical Network (ASON). This document
provides a problem statement and additional requirements on the
GMPLS signaling protocol to support the ASON functionality.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-reqts-02.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-reqts-02.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-reqts-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-reqts-02.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, 14 Aug 2003 18:11:23 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Cc: "'Vishal Sharma'" <[email-masked]>
Subject: Time-bounded notification
Date: Thu, 14 Aug 2003 11:09:07 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C36254.7B34F930
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Everyone,

=20

Following some discussions prior to Vienna, and feedback and comments
received during Vienna and thereafter, we have realized that perhaps one
aspect of draft-rabbat-fault-notification-protocol-03.txt that we may =
not
have adequately highlighted is its focus on providing *time-bounded*
notification.

=20

This is because draft-rabbat focuses on recovery in optical transport
networks, where recovery of failed LSPs (fibers, lambdas, etc.) in a
*bounded time* is critical for the provider to be able to offer
guarantees/SLAs to its transport customers, and also to its L2 and L3
customers. The transport infrastructure often serves as a foundation for =
the
L2 and L3 networks built upon it, and so should be able to provide =
recovery
within some well-specified time, so that L2 and L3 recovery can be
appropriately performed based on what L1 provides.

=20

For this reason, notification via signaling or OSPF-based flooding, =
which
could work well at the packet layer, may not be directly applicable at =
the
transport layer. In fact, since recovery at the packet layer may not =
involve
the stringent time constraints that are applicable at the transport =
layer,
directly comparing notification solutions at the packet layer with those =
at
the transport layer is probably not accurate.

Rather, we need to examine (as done in draft-rabbat) the applicability =
of
signaling and flooding to notification *at the transport layer* under =
the
constraint of achieving time-bounded recovery.

=20

So if the WG looks at draft-rabbat with this backdrop, we believe some =
of
the arguments made there will be clearer. Of course, we welcome feedback
from the list.

=20

Thanks,

=20

-Richard and Vishal

=20

PS: The need for time-bounded recovery is not new, and has been =
recognized
in several recent IETF RFCs. Notably,

=20

RFC3272

http://www.ietf.org/rfc/rfc3272.txt=20

page 52:

--

   -  Failure notification throughout the network should be timely and
reliable.

--

Note that there is a list of requirements on this page, some of which =
are
similar to those in draft-rabbat-optical-recovery-reqs-00.txt.

=20

=20

RFC3386

http://www.ietf.org/rfc/rfc3386.txt, which is also relevant to the whole
discussion.

Page 15 discusses the following:

--

   Proposed timing bounds for different survivability mechanisms are as
follows (all bounds are exclusive of signal propagation):

=20

   1:1 path protection with pre-established capacity:  100-500 ms

   1:1 path protection with pre-planned capacity:      100-750 ms

   Local restoration:                                  50 ms

   Path restoration:                                   1-5 seconds

--

Note that RFC3386 discusses horizontal hierarchy in data networks, and =
so
the bounds above apply primarily to the packet layer. Similar numbers =
for
the transport layer will likely be significantly stricter (Any operator
inputs on this?).

=20

=20

------=_NextPart_000_0011_01C36254.7B34F930
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 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;}
span.EmailStyle17
	{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=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hello Everyone,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Following some discussions prior to Vienna, and =
feedback and
comments received during Vienna and thereafter, we have realized that =
perhaps
one aspect of draft-rabbat-fault-notification-protocol-03.txt that we =
may not have
adequately highlighted is its focus on providing *<b><span =
style=3D'font-weight:
bold'>time-bounded</span></b>* notification.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This is because draft-rabbat focuses on recovery in =
optical transport
networks, where recovery of failed LSPs (fibers, lambdas, etc.) in a =
*<b><span
style=3D'font-weight:bold'>bounded time</span></b>* is critical for the =
provider to
be able to offer guarantees/SLAs to its transport customers, and also to =
its L2
and L3 customers. The transport infrastructure often serves as a =
foundation for
the L2 and L3 networks built upon it, and so should be able to provide =
recovery
within some well-specified time, so that L2 and L3 recovery can be
appropriately performed based on what L1 provides.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>For this reason, notification via signaling or =
OSPF-based
flooding, which could work well at the packet layer, may not be directly
applicable at the transport layer. In fact, since recovery at the packet =
layer
may not involve the stringent time constraints that are applicable at =
the transport
layer, directly comparing notification solutions at the packet layer =
with those
at the transport layer is probably not accurate.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Rather, we need to examine (as done in draft-rabbat) =
the
applicability of signaling and flooding to notification *<b><span
style=3D'font-weight:bold'>at the transport layer</span></b>* under the
constraint of achieving time-bounded recovery.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>So if the WG looks at draft-rabbat with this =
backdrop, we
believe some of the arguments made there will be clearer. Of course, we =
welcome
feedback from the list.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>-Richard and Vishal</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>PS: The need for time-bounded recovery is not new, =
and has
been recognized in several recent IETF RFCs. Notably,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>RFC3272</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>http://www.ietf.org/rfc/rfc3272.txt =
</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>page 52:</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>--</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; -&nbsp; Failure notification throughout =
the
network should be timely and reliable.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>--</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Note that there is a list of requirements on this =
page, some
of which are similar to those in =
draft-rabbat-optical-recovery-reqs-00.txt.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>RFC3386</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>http://www.ietf.org/rfc/rfc3386.txt, which is also =
relevant
to the whole discussion.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Page 15 discusses the following:</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>--</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; Proposed timing bounds for different
survivability mechanisms are as follows (all bounds are exclusive of =
signal propagation):</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; 1:1 path protection with pre-established
capacity:&nbsp; 100-500 ms</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; 1:1 path protection with pre-planned
capacity:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100-750 ms</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; Local
restoration:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
50 ms</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; Path
restoration:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1-5 seconds</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>--</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Note that RFC3386 discusses horizontal hierarchy in =
data
networks, and so the bounds above apply primarily to the packet layer. =
Similar
numbers for the transport layer will likely be significantly stricter =
(Any
operator inputs on this?).</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0011_01C36254.7B34F930--

Delivery-date: Thu, 14 Aug 2003 12:25:18 +0000
content-class: urn:content-classes:message
Subject: RE: Draft Minutes of ccamp wg meeting
Date: Thu, 14 Aug 2003 07:21:51 -0500
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: "Stephen J Trowbridge" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, <[email-masked]>, "Ron Bonica" <[email-masked]>

Steve,

Ron> Papadimitriou draft-ietf-ccamp-gmpls-ason-reqts-01.txt
Ron> (snip)
Ron> * Invitation for participation in routing requirements and=20
Ron> protocol extensions

Steve> In my own notes, in place of this I have:
Steve> "Routing is a separate topic (from protocol extensions).
Steve> Encourage joint work between ASON experts and IETF routing=20
Steve> experts."
Steve>
Steve> I don't get the same sense from your sentence.
Steve>
Steve> ccamp folks should work jointly with ASON experts for=20
Steve> issues with protocol extensions.
Steve>
Steve> isis and ospf folks should work jointly with ASON experts=20
Steve> on routing.

Actually, all of the above are correct.  The final points on my final =
slide were:

o joint IETF/ITU-T working team on GMPLS-ASON routing requirements & =
protocol extensions

  - routing not intended to be in this draft, separate topic
  - others encouraged to participate (please see us after class)

People were invited to participate on the routing working team, some =
responded.  The points you added are very important, and I'm glad you =
suggested adding them to the minutes.

Thanks,
Regards,
Jerry

Delivery-date: Wed, 13 Aug 2003 22:48:23 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Ron Bonica'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Draft Minutes of ccamp wg meeting
Date: Wed, 13 Aug 2003 15:47:30 -0700

> -----Original Message-----

> > Rabbat	   draft-rabbat-optical-recovery-reqs-00.txt et al
> > --------------------------------------------------------------
> > * Summarized changes
> > * Solicited feedback
> > * Kireeti: Had requirements from te-wg, keep this as separate doc, =
start
> > thread on mailing list
> > * Draft stable, proposed adoption as WG draft
> > * Need more discussion on WG list
> >
> > * soumiya-lmp-fault (not on agenda from Bonica)

Not correct. Update names of drafts:
draft-rabbat-fault-notification-protocol and
draft-soumiya-lmp-fault-notification-ext ARE mentioned in Ron's agenda =
as
"et al".=20

> > -----------------------------------------------
> > * How we reduce message overhead slide
> > * Alex Zinin - Q: Is flooding done reliably? A: Yes. Need to include
> > acknowledgement messages when assessing complexity.
> > * Adrian: arrows on lhs (signaling) indicate a pair of messages for
> > signaling.
> > * Kireeti: Was discussion comparing signaling message vs sending
> flooding
> > messages. Signaling is often faster (contrary to stmt that it is
slower).
> > Flooding has a hold down timer aspect, but signaling is faster. =
Issue
> with
> > using LSPs for flooding since they are link local - seems
> > redundant with IGP
> > (OSPF, IS-IS). Usurps LMP for different purpose. Important point is =
that
> > flooding is slower, but fewer messages as compared with signaling.
> Should
> > discuss further on list. Concerned about resolving problem of =
flooding
> > already solved in GP.
> > * Aboul-Magd: Same comment as Kireeti. Need to synchronize signaling =
and
> > routing. Don't understand why there is a need for this.
> > * Jonathon Lang: Concern that message indicates a fiber cut and
> > not messages

Please fix to Jonathan Sadler

> > for each affected LSP. A: Protection algorithms expect knowledge
> > that nodes
> > know this mapping at a protection point. Issue is that nodes may not
> know
> > this mapping when multiple levels of indirection exist. Presenter
> > requested
> > feedback on the list.
> > * Bonica: Take further discussion to the list.
> >

Delivery-date: Wed, 13 Aug 2003 22:19:38 +0000
Date: Wed, 13 Aug 2003 18:08:37 -0400
From: Ron Bonica <[email-masked]>
Subject: IETF 57 CCAMP Minutes
To: [email-masked], [email-masked]

Chairs  	   Doc status - Kireeti presented slides (could not keep notes on
all)
----------------------------------------------------------------------------
-----
GMPLS signaling for SONET/SDH - RF Ed Q
GMPLS Non-std SONET SDH features - killed
GMPLS RSVP support for overlay model - authors to respond to list comment
ASON requirments for signaling - one more update prior to straw poll WG last
call
Exclude routes ext to RSVP-TE - Adrian add appendices to describe usage
Routing ext to support GMPLS - Kireeti did update, planned mtg prior to WG
last call
			           - Number of docs stacked up based on this doc
OSPF ext in support of GMPLS - awaiting above
ASON routing rqmts - Design team created, members, milestones and schedule
to be posted to list
LMP - security section needs work
SONET/SDH
??
GMPLS recovery - Design team says ready for last call
GMPLS MIBs waiting on MPLS MIBs (Adrian - 99% complete)
GMPLS architecture - waiting on normative refs
GMPLS trace in RFC ed Q
Framework for GMPLS-based control of SONET/SDH - Informational

Several individual contribs and WG docs not covered. Would like to progress
the above mature docs.

Alanqar	   ITU SG15 Liaisons
--------------------------------
* Links to liasion statements in slides
* Focus is ASON signaling protocol and routing extensions
* Thanks extended to chair and invited experts
* Snapshot of approved and under development stds

* Signaling updates
	- G.7713 terminology alignment with G.8080
	- support for crankback
	- Call/connection separation
* Comments on G.7713 solicited
* No need to develop alternative solution

* Routing updates G.7715.1
	- Goal is consent in Oct 2003 Geneva
	- OSPF ext for ASON
	- Potential use of PNNI

* Addressing: signaling, control and management usage important
	- separate address spaces for control and management

* Auto discover G.7714.1
	- Further investigation initiated
	- Focus on type A (trail overhead)

* Arch for discover & control plane G.disc_arch
	- New scope/title for G.7716

* Management framework - new doc created in Chicago G.frame
	- Goal of consent by May 2004

No questions

Kireeti - ccamp needs to formal liaisons

Papadimitriou draft-ietf-ccamp-gmpls-ason-reqts-01.txt
------------------------------------------------------
* Presented by Jerry Ash
* background, overview, issues presented
* History has created need for better communication
* Need to continue/ensure joint IETF/ITU-T working team
* Intention of draft is not to repeat G.8080, but to address additional
GMPLS signaling requirements to support ASON.
* Six broad areas of requirements
	 - Support for soft permanent connection capability
      - Support for call and connection separation
      - Support for call segments
      - Support for extended restart capabilities during control plane
        failures
      - Support for extended label usage
      - Support for crankback capability
      - Support for additional error cases
* Ensure that IETF & ITU-T work jointly on requirements & protocol
extensions, and evaluate signaling extensions included in G.7713.2.

* Another iteration and then WG last call
* Progress signaling extensions
* Routing is a seperate topic (from protocol extensions).
  Encourage joint work between ASON experts and IETF routing experts.
* No questions nor discussion
* ccamp folks should work jointly with ASON experts for issues with protocol
extensions.
* isis and ospf folks should work jointly with ASON experts on routi
* Kireeti will float draft of liaison next week for comment

Aboul-Magd	   draft-aboulmagd-ccamp-transport-lmp-01.txt
------------------------------------------------------
* Could change title to "ASON discovery framework"
* Is a terminology "decoder ring" mapping ASON <-> GMPLS LMP terminology
	- includes port and component link types
* G.8080 has transport (data) and control plane discovery with separate
addresses (draft says name space and not address?)
* Proposed considering draft as WG document
	- A number of people had read this draft
	- not a broad consensus in support of this proposal
* Lyndon Ong - Good doc, need to resolve decoder ring comments.
* Jonathon Saddler - WG23 doc from ITU-T Chicago discusses some of
these issues
* Malcom Betts - Question on control/data plane addresses in ITU documentati
on. IP address in header, NHOP, PHOP have transport address.  Intent is to
clarify usage, if already done then no need to repeat.

Papadimitriou Protection and Recovery update
--------------------------------------------
* Presented by Dimitri
* Effort positioning, status and timing over past 1.5 years
* Scope: LSP protection, (pre-planned) LSP re-routing, dynamic LSP
re-routing
* Not covered: local recovery, M:N end-to-end LSP prot., crankback (ref. to
draft-iwata-mpls-crankback-06.txt)
* Summarized comments received
* Proposed acceptance as WG document
	- consensus was that this is ready
	- Kireeti - take to the list
* Discuss the extra traffic concept in a list thread
	- Dimitri will propose text to clarify this

Farrel	   draft-iwata-mpls-crankback-06.txt
------------------------------------------------
* Adrian Farrel presented
* Has been around for several years and this version is a major re-spin
	- May be more complex than single node/interface
	- Objective is to fail back to some intermediate point (e.g., region
boundary or loose route identified node)
	- Requirement from ASON ITU-T
	- New co-author, Arun Satyanarayana
* Summarize major changes in slides
	- long list of TLVs, but no adivce on which to include and when
* Wanted to start thread on list re: remaining issues - some very thorny
	- session attribute bits (all would be used by this draft)
	- too many TLVs, need to confirm all are actually required
	- right place to handle unnumbered bundles
	- Is this the right approach, or should RRO be used?
* Feedback solicited, resolve open issues
* Add pointer from ASON signaling since it is long (different from slide
presented)
* Kireeti: close on issues, bounce use of final 3 bits off MPLS WG
	- decide on approach (TLVs vs RRO) and with new charter decide on WG status
* Dimitri - What is the basic set of TLVs needed and then address larger
scope.
* Adrian - What is needed is implementation dependent. Need input from other
service providers.
* Kireeti: relate this to multi-area, multi-AS documents since a primary
application is setup failures in multi-region.
* Adrian: Need more explicity requirements from te-wg on crankback
requirements.

Kim	         draft-kim-ccamp-cc-protection-03.txt
---------------------------------------------------
* Presented by Young Hwa Kim
* Summarized survivability of control channels and neworks(from G.807)
	- assoc, non-assoc, quasi-assoc, in or out of fiber, SCN/ASTN
implementation
* Stated problem as no provision of protection features in current GMPLS
control plane
* Summarized requirements and functions for resilience of control plane
	- e.g., primary and secondary on separate fibers (shown in figure)
* Next steps: proposed refine/complete requirements, 	protocol
specification, WG document in 2003/2004

* Aboul-Magd: Are control channels visible to LMP? Why are current control
plane methods not sufficient? What are the deficiences?
* Kireeti: Control plane is an IP network, not trying to redesign IP
resiliency. Are some issues: is graceful restart sufficient? Need to
convince WG that there is a problem to resolve. Do this on the mailing list.
* Kim: Gigabit Ethernet has no protection, but SONET/SDH and Lamba network
does.
*  Malcom Betts - Control plane relies on IP network resiliency. G.8080 has
a number of resiliency considerations listed.

Rabbat	   draft-rabbat-optical-recovery-reqs-00.txt et al
--------------------------------------------------------------
* Summarized changes
* Solicited feedback
* Kireeti: Had requirements from te-wg, keep this as separate doc, start
thread on mailing list
* Draft stable, proposed adoption as WG draft
* Need more discussion on WG list

* soumiya-lmp-fault (not on agenda from Bonica)
-----------------------------------------------
* How we reduce message overhead slide
* Alex Zinin - Q: Is flooding done reliably? A: Yes. Need to include
acknowledgement messages when assessing complexity.
* Adrian: arrows on lhs (signaling) indicate a pair of messages for
signaling.
* Kireeti: Was discussion comparing signaling message vs sending flooding
messages. Signaling is often faster (contrary to stmt that it is slower).
Flooding has a hold down timer aspect, but signaling is faster. Issue with
using LSPs for flooding since they are link local - seems redundant with IGP
(OSPF, IS-IS). Usurps LMP for different purpose. Important point is that
flooding is slower, but fewer messages as compared with signaling.  Should
discuss further on list. Concerned about resolving problem of flooding
already solved in GP.
* Aboul-Magd: Same comment as Kireeti. Need to synchronize signaling and
routing. Don't understand why there is a need for this.
* Jonathon Saddler: Concern that message indicates a fiber cut and not
messages
for each affected LSP. A: Protection algorithms expect knowledge that nodes
know this mapping at a protection point. Issue is that nodes may not know
this mapping when multiple levels of indirection exist. Presenter requested
feedback on the list.
* Bonica: Take further discussion to the list.

Shiomoto	   draft-pil-ccamp-extra-lsp-00.txt
-----------------------------------------------
* Presented by Shimoto
* Brief overview of draft for shared mesh restoration
	- protecting LSP resource is reserved, but not cross-connected
	- extra class LSP can use this unused restoration capacity, which is
preemptable when needed for restoration (expected to be rare occurence)
	- problems: advertise available resources, LSP indications and preemption
in signaling, prevent unintended connections, also protect confidentiality
* Discuss comments from mailing list
	- can do using existing priority mechanisms where extra class has lower
holding priority than restoration LSP
	- complexity
	- soft preemption (not addressed in this draft)
* Solicit comments/feedback
* Proposed accepting this for ccamp wg
* Dimitri: Question re: soft preemption as document or charter? A: Propose
adding to charter.
* JP Vasseur: Elaborate on soft preemption. A: Need to describe concept in
this draft. Q: Are you aware of draft on soft preemption? A: No. Q: What is
to be done with existing mechanisms?
* Kireeti: Can be achieved with current mechanisms. Discuss on list.
Proposed action was for Dimitri/JP Vasseur to describe on list how this can
be done using existing mechanisms and Shiomoto to identify what is missing.

Papadimitriou draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
-----------------------------------------------------------
* Presented by Deborah Brungard
* Address requirements in GMPLS ASON presented earlier
* Backward/forward compatible with GMPLS
* Agnostic to network UNI implementation
* Call/connection separation objects simply forwarded and not processed
* Described proposed mechanism for call/connection separation in detail
* Summarized other additional ASON functionalities
* Next version - add crankback signaling and call segments
* Solicting feedback
* Lyndon Ong: Requesting interpretation of "backward compatibility" 7713.2
interpretation is to carry an object if is not understood.
* Kireeti: Need liaison to ITU-T with comments on 7713, 7713.2, and ITU-T
liaisons and then decide how to progress this document.

Ali draft-zamfir-explicit-resource-control-bundle-01.txt
--------------------------------------------------------
* Presented by Zafar Ali
* Explicit Resrouce Control and Recording
	- Unbundled or bundled TE link type
	- Focus is case where component interface cannot be inferred from label
value
* Current spec supports unbundled case for LSP splicing uni- and
bi-directional
* Can support bundled case by specifying component ID for LSP splicing
* Cannot support bundled case for LSP splicing when forward and backward
component IDs are different in bi-directional
* Propose optional interface identifier ERO subobject to address this case
* RRO with label recording
	- could use to signal label values used within the bundle
	- cannot currently identify component interface used withing bundle
	- proposed solution is interface identifier RRO subobject, similar to above
* Propose accepting this as WG doc
* Kireeti: Missing element in taxonomy (matrix) of these approaches not
sufficient for WG adoption. Understand RRO case. What is motivation for ERO?
A: Could have case where component links are different where upstream and
downstream differ. Bundle draft says that up- and down-stream can differ. Q:
Why don't the local nodes assign this (and communicate selection in RRO). A:
Consideration is on egress specification of component ID. Don't understand
resistance.
* Kireeti: Post rationale to the list, beyond missing support in
taxonomy/martix for both RRO and ERO cases. If agreement, then can proceed.
* Swallow: Provider feedback is to keep up- and down-stream on same fiber
(pair).
* Dimitri: Can provide examples for RRO, but believes there will be few for
ERO. Please expand compatibility statement in the last section.

Choi	         draft-choi-gmpls-resource-mapping-00.txt
-------------------------------------------------------
*  Resource Mapping for GMPLS with Heterogeneous Interfaces
* Problem: Label format for optical interface defined, but specific mapping
rule is not
	- Identify fiber, waveband, and lambda labels
* Issue -1
	- Need aggregation for sharing in protection/restoration
	- Support mechanism similar to label stacking in electrical domain for
optical interfaces
* Issue -2
	- Logical resoure aggregation at switching interface - mapping, aggregation
	(examples given)
	- Miscellaneous other issues (unnumbered links, bundling, SRLG mapping,
signaling, routing)
* Is proposal acceptable to ccamp WG
* Kireeti: Some routing and signaling defined in hierarchy draft. Here,
FA-LSP adverstises aggregate into IGP. Asked presenter to state why this is
needed on the mailing list.

Fu		   draft-fu-ccamp-traceroute-00.txt
-----------------------------------------------
* Presented by Xiaoming Fu
* A Proposal for Generic Traceroute Over Tunnels
* A few issues with current GTTP draft
	- each hop supports GTTP
	- UDP issues: ports could be blocked by some ISPs, TTL=1, msg size>MTU
	- Reverse trace may not traverse same tunnel
* Summarized potential solutions described in draft based on NSIS
	- Based on two-layer NTLP and NSLP NSIS protocol model
	- Can reuse TCP and SCTP to deliver trace messages (address firewall issue)
	- NSIS discovery finds next (NSLP?) hop and uses traditional traceroute
between NSIS-enabled nodes
* Should issues & concepts be considered in traceroute/GTTP design
* Bonica (as individual contributor): Q: Does probe sent to destination
visit intermediate nodes forward or backward? A: Still investigating. Q:
Would have to use alert? A: No, signaling can used without routing alert.
Should discovery of next hop be separate from signaling. Q: Is trace control
or data plane? A: NSIS direction is discovering data path. Q: Will
intermediate routers pass w/o change? A: Yes, traditional traceroute does
this.

Chairs	   Wrap up
----------------------
* See you in Minneapolis.
* All presenters send slides to bonica and kireeti.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"An eye for an eye only ends up making
the whole world blind."
            -- Gandhi

Delivery-date: Wed, 13 Aug 2003 21:19:16 +0000
Date: Wed, 13 Aug 2003 15:17:11 -0600
From: Stephen J Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Ron Bonica <[email-masked]>
CC: [email-masked]
Subject: Re: FW: Draft Minutes of ccamp wg meeting

Ron,

>>Papadimitriou draft-ietf-ccamp-gmpls-ason-reqts-01.txt
(snip)
>>* Invitation for participation in routing requirements and protocol
>>extensions
In my own notes, in place of this I have:
"Routing is a seperate topic (from protocol extensions).
Encourage joint work between ASON experts and IETF routing experts."

I don't get the same sense from your sentence.

ccamp folks should work jointly with ASON experts for issues with protocol extensions.

isis and ospf folks should work jointly with ASON experts on routing.

Regards,
Steve

Delivery-date: Wed, 13 Aug 2003 12:15:52 +0000
content-class: urn:content-classes:message
Subject: RE: Draft Minutes of ccamp wg meeting
Date: Wed, 13 Aug 2003 07:15:35 -0500
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: "Ron Bonica" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, <[email-masked]>

Ron,

Two clarifications:

> Papadimitriou draft-ietf-ccamp-gmpls-ason-reqts-01.txt
> ------------------------------------------------------
> * Presented by Jerry Ash
...
> * Much discussion on this draft since work has already been done in =
G.8080
> * Intent is to have extensions
Please replace the above 2 lines with:
Intention of draft is not to repeat G.8080, but to address additional =
GMPLS signaling requirements to support ASON.

...
> * Enssure GMPLS extensions interoperable with G.7713.2
Please replace the above line with:
Ensure that IETF & ITU-T work jointly on requirements & protocol =
extensions, and evaluate signaling extensions included in G.7713.2.

Thanks,
Jerry

Delivery-date: Wed, 13 Aug 2003 12:14:07 +0000
Date: Wed, 13 Aug 2003 14:12:27 +0200
From: [email-masked]
To: Ron Bonica <[email-masked]>
CC: [email-masked]
Subject: Re: FW: Draft Minutes of ccamp wg meeting

hi ron,

would you please replace:
* Scope: protection, (pre-planned) rerouting, ??

by
* Scope: LSP protection, (pre-planned) LSP re-routing, dynamic
   LSP re-routing

and
* Not covered: local recovery, end-to-end prot., crankback

by
* Not covered: local recovery, M:N end-to-end LSP prot., crankback
   (ref. to draft-iwata-mpls-crankback-06.txt)

thanks,
- dimitri.

Ron Bonica wrote:

> Folks,
> 
> If nobody objects by COB Wednesday, I will post the following minutes of the
> CCAMP WG
> 
>                                      Ron
> 
> 
> 
>>Chairs  	   Doc status - Kireeti presented slides (could not
>>keep notes on
>>all)
>>------------------------------------------------------------------
>>----------
>>-----
>>GMPLS signaling for SONET/SDH - RF Ed Q
>>GMPLS Non-std SONET SDH features - killed
>>GMPLS RSVP support for overlay model - authors to respond to list comment
>>ASON requirments for signaling - one more update prior to straw
>>poll WG last
>>call
>>Exclude routes ext to RSVP-TE - Adrian add appendices to describe usage
>>Routing ext to support GMPLS - Kireeti did update, planned mtg prior to WG
>>last call
>>			           - Number of docs stacked up
>>based on this doc
>>OSPF ext in support of GMPLS - awaiting above
>>ASON routing rqmts - Design team created, members, milestones and schedule
>>to be posted to list
>>LMP - security section needs work
>>SONET/SDH
>>??
>>GMPLS recovery - Design team says ready for last call
>>GMPLS MIBs waiting on MPLS MIBs (Adrian - 99% complete)
>>GMPLS architecture - waiting on normative refs
>>GMPLS trace in RFC ed Q
>>Framework for GMPLS-based control of SONET/SDH - Informational
>>
>>Several individual contribs and WG docs not covered. Would like
>>to progress
>>the above mature docs.
>>
>>Alanqar	   ITU SG15 Liaisons
>>--------------------------------
>>* Links to liasion statements in slides
>>* Focus is ASON signaling protocol and routing extensions
>>* Thanks extended to chair and invited experts
>>* Snapshot of approved and under development stds
>>
>>* Signaling updates
>>	- G.7713 terminology alignment with G.8080
>>	- support for crankback
>>	- Call/connection separation
>>* Comments on G.7713 solicited
>>* No need to develop alternative solution
>>
>>* Routing updates G.7715.1
>>	- Goal is consent in Oct 2003 Geneva
>>	- OSPF ext for ASON
>>	- Potential use of PNNI
>>
>>* Addressing: signaling, control and management usage important
>>	- separate address spaces for control and management
>>
>>* Auto discover G.7714.1
>>	- Further investigation initiated
>>	- Focus on type A (trail overhead)
>>
>>* Arch for discover & control plane G.disc_arch
>>	- New scope/title for G.7716
>>
>>* Management framework - new doc created in Chicago G.frame
>>	- Goal of consent by May 2004
>>
>>No questions
>>
>>Kireeti - ccamp needs to formal liaisons
>>
>>Papadimitriou draft-ietf-ccamp-gmpls-ason-reqts-01.txt
>>------------------------------------------------------
>>* Presented by Jerry Ash
>>* background, overview, issues presented
>>* History has created need for better communication
>>* Need to continue/ensure joint IETF/ITU-T working team
>>* Much discussion on this draft since work has already been done in G.8080
>>* Intent is to have extensions
>>* Six broad areas of requirements
>>	 - Support for soft permanent connection capability
>>      - Support for call and connection separation
>>      - Support for call segments
>>      - Support for extended restart capabilities during control plane
>>        failures
>>      - Support for extended label usage
>>      - Support for crankback capability
>>      - Support for additional error cases
>>* Enssure GMPLS extensions interoperable with G.7713.2
>>
>>* Another iteration and then WG last call
>>* Progress signaling extensions
>>* Invitation for participation in routing requirements and protocol
>>extensions
>>
>>* No questions nor discussion
>>* Kireeti will float draft of liaison next week for comment
>>
>>Aboul-Magd	   draft-aboulmagd-ccamp-transport-lmp-01.txt
>>------------------------------------------------------
>>* Could change title to "ASON discovery framework"
>>* Is a terminology "decoder ring" mapping ASON <-> GMPLS LMP terminology
>>	- includes port and component link types
>>* G.8080 has transport (data) and control plane discovery with separate
>>addresses (draft says name space and not address?)
>>* Proposed considering draft as WG document
>>	- A number of people had read this draft
>>	- not a broad consensus in support of this proposal
>>* Lyndon Ong - Good doc, need to resolve decoder ring comments.
>>* Jonathon Lang (Tellabs) - WG23 doc from ITU-T Chicago discusses some of
>>these issues
>>* Malcom Betts - Question on control/data plane addresses in ITU
>>documentati
>>on. IP address in header, NHOP, PHOP have transport address.  Intent is to
>>clarify usage, if already done then no need to repeat.
>>
>>Papadimitriou Protection and Recovery update
>>--------------------------------------------
>>* Presented by Dimitri
>>* Effort positioning, status and timing over past 1.5 years
>>* Scope: protection, (pre-planned) rerouting, ??
>>* Not covered: local recovery, end-to-end prot., crankback
>>* Summarized comments received
>>* Proposed acceptance as WG document
>>	- consensus was that this is ready
>>	- Kireeti - take to the list
>>* Discuss the extra traffic concept in a list thread
>>	- Dimitri will propose text to clarify this
>>
>>Farrel	   draft-iwata-mpls-crankback-06.txt
>>------------------------------------------------
>>* Adrian Farrel presented
>>* Has been around for several years and this version is a major re-spin
>>	- May be more complex than single node/interface
>>	- Objective is to fail back to some intermediate point (e.g., region
>>boundary or loose route identified node)
>>	- Requirement from ASON ITU-T
>>	- New co-author, John Drake
>>* Summarize major changes in slides
>>	- long list of TLVs, but no adivce on which to include and when
>>* Wanted to start thread on list re: remaining issues - some very thorny
>>	- session attribute bits (all would be used by this draft)
>>	- too many TLVs, need to confirm all are actually required
>>	- right place to handle unnumbered bundles
>>	- Is this the right approach, or should RRO be used?
>>* Feedback solicited, resolve open issues
>>* Add pointer from ASON signaling since it is long (different from slide
>>presented)
>>* Kireeti: close on issues, bounce use of final 3 bits off MPLS WG
>>	- decide on approach (TLVs vs RRO) and with new charter
>>decide on WG status
>>* Dimitri - What is the basic set of TLVs needed and then address larger
>>scope.
>>* Adrian - What is needed is implementation dependent. Need input
>>from other
>>service providers.
>>* Kireeti: relate this to multi-area, multi-AS documents since a primary
>>application is setup failures in multi-region.
>>* Adrian: Need more explicity requirements from te-wg on crankback
>>requirements.
>>
>>Kim	         draft-kim-ccamp-cc-protection-03.txt
>>---------------------------------------------------
>>* Presented by Young Hwa Kim
>>* Summarized survivability of control channels and neworks(from G.807)
>>	- assoc, non-assoc, quasi-assoc, in or out of fiber, SCN/ASTN
>>implementation
>>* Stated problem as no provision of protection features in current GMPLS
>>control plane
>>* Summarized requirements and functions for resilience of control plane
>>	- e.g., primary and secondary on separate fibers (shown in figure)
>>* Next steps: proposed refine/complete requirements, 	protocol
>>specification, WG document in 2003/2004
>>
>>* Aboul-Magd: Are control channels visible to LMP? Why are current control
>>plane methods not sufficient? What are the deficiences?
>>* Kireeti: Control plane is an IP network, not trying to redesign IP
>>resiliency. Are some issues: is graceful restart sufficient? Need to
>>convince WG that there is a problem to resolve. Do this on the
>>mailing list.
>>* Kim: Gigabit Ethernet has no protection, but SONET/SDH and Lamba network
>>does.
>>*  Malcom Betts - Control plane relies on IP network resiliency.
>>G.8080 has
>>a number of resiliency considerations listed.
>>
>>Rabbat	   draft-rabbat-optical-recovery-reqs-00.txt et al
>>--------------------------------------------------------------
>>* Summarized changes
>>* Solicited feedback
>>* Kireeti: Had requirements from te-wg, keep this as separate doc, start
>>thread on mailing list
>>* Draft stable, proposed adoption as WG draft
>>* Need more discussion on WG list
>>
>>* soumiya-lmp-fault (not on agenda from Bonica)
>>-----------------------------------------------
>>* How we reduce message overhead slide
>>* Alex Zinin - Q: Is flooding done reliably? A: Yes. Need to include
>>acknowledgement messages when assessing complexity.
>>* Adrian: arrows on lhs (signaling) indicate a pair of messages for
>>signaling.
>>* Kireeti: Was discussion comparing signaling message vs sending flooding
>>messages. Signaling is often faster (contrary to stmt that it is slower).
>>Flooding has a hold down timer aspect, but signaling is faster. Issue with
>>using LSPs for flooding since they are link local - seems
>>redundant with IGP
>>(OSPF, IS-IS). Usurps LMP for different purpose. Important point is that
>>flooding is slower, but fewer messages as compared with signaling.  Should
>>discuss further on list. Concerned about resolving problem of flooding
>>already solved in GP.
>>* Aboul-Magd: Same comment as Kireeti. Need to synchronize signaling and
>>routing. Don't understand why there is a need for this.
>>* Jonathon Lang: Concern that message indicates a fiber cut and
>>not messages
>>for each affected LSP. A: Protection algorithms expect knowledge
>>that nodes
>>know this mapping at a protection point. Issue is that nodes may not know
>>this mapping when multiple levels of indirection exist. Presenter
>>requested
>>feedback on the list.
>>* Bonica: Take further discussion to the list.
>>
>>Shiomoto	   draft-pil-ccamp-extra-lsp-00.txt
>>-----------------------------------------------
>>* Presented by Shimoto
>>* Brief overview of draft for shared mesh restoration
>>	- protecting LSP resource is reserved, but not cross-connected
>>	- extra class LSP can use this unused restoration capacity, which is
>>preemptable when needed for restoration (expected to be rare occurence)
>>	- problems: advertise available resources, LSP indications
>>and preemption
>>in signaling, prevent unintended connections, also protect confidentiality
>>* Discuss comments from mailing list
>>	- can do using existing priority mechanisms where extra
>>class has lower
>>holding priority than restoration LSP
>>	- complexity
>>	- soft preemption (not addressed in this draft)
>>* Solicit comments/feedback
>>* Proposed accepting this for ccamp wg
>>* Dimitri: Question re: soft preemption as document or charter? A: Propose
>>adding to charter.
>>* JP Vasseur: Elaborate on soft preemption. A: Need to describe concept in
>>this draft. Q: Are you aware of draft on soft preemption? A: No.
>>Q: What is
>>to be done with existing mechanisms?
>>* Kireeti: Can be achieved with current mechanisms. Discuss on list.
>>Proposed action was for Dimitri/JP Vasseur to describe on list
>>how this can
>>be done using existing mechanisms and Shiomoto to identify what
>>is missing.
>>
>>Papadimitriou draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
>>-----------------------------------------------------------
>>* Presented by Deborah Brungard
>>* Address requirements in GMPLS ASON presented earlier
>>* Backward/forward compatible with GMPLS
>>* Agnostic to network UNI implementation
>>* Call/connection separation objects simply forwarded and not processed
>>* Described proposed mechanism for call/connection separation in detail
>>* Summarized other additional ASON functionalities
>>* Next version - add crankback signaling and call segments
>>* Solicting feedback
>>* Lyndon Ong: Requesting interpretation of "backward compatibility" 7713.2
>>interpretation is to carry an object if is not understood.
>>* Kireeti: Need liaison to ITU-T with comments on 7713, 7713.2, and ITU-T
>>liaisons and then decide how to progress this document.
>>
>>Ali draft-zamfir-explicit-resource-control-bundle-01.txt
>>--------------------------------------------------------
>>* Presented by Zafar Ali
>>* Explicit Resrouce Control and Recording
>>	- Unbundled or bundled TE link type
>>	- Focus is case where component interface cannot be
>>inferred from label
>>value
>>* Current spec supports unbundled case for LSP splicing uni- and
>>bi-directional
>>* Can support bundled case by specifying component ID for LSP splicing
>>* Cannot support bundled case for LSP splicing when forward and backward
>>component IDs are different in bi-directional
>>* Propose optional interface identifier ERO subobject to address this case
>>* RRO with label recording
>>	- could use to signal label values used within the bundle
>>	- cannot currently identify component interface used withing bundle
>>	- proposed solution is interface identifier RRO subobject,
>>similar to above
>>* Propose accepting this as WG doc
>>* Kireeti: Missing element in taxonomy (matrix) of these approaches not
>>sufficient for WG adoption. Understand RRO case. What is
>>motivation for ERO?
>>A: Could have case where component links are different where upstream and
>>downstream differ. Bundle draft says that up- and down-stream can
>>differ. Q:
>>Why don't the local nodes assign this (and communicate selection
>>in RRO). A:
>>Consideration is on egress specification of component ID. Don't understand
>>resistance.
>>* Kireeti: Post rationale to the list, beyond missing support in
>>taxonomy/martix for both RRO and ERO cases. If agreement, then
>>can proceed.
>>* Swallow: Provider feedback is to keep up- and down-stream on same fiber
>>(pair).
>>* Dimitri: Can provide examples for RRO, but believes there will
>>be few for
>>ERO. Please expand compatibility statement in the last section.
>>
>>Choi	         draft-choi-gmpls-resource-mapping-00.txt
>>-------------------------------------------------------
>>*  Resource Mapping for GMPLS with Heterogeneous Interfaces
>>* Problem: Label format for optical interface defined, but
>>specific mapping
>>rule is not
>>	- Identify fiber, waveband, and lambda labels
>>* Issue -1
>>	- Need aggregation for sharing in protection/restoration
>>	- Support mechanism similar to label stacking in electrical
>>domain for
>>optical interfaces
>>* Issue -2
>>	- Logical resoure aggregation at switching interface -
>>mapping, aggregation
>>	(examples given)
>>	- Miscellaneous other issues (unnumbered links, bundling,
>>SRLG mapping,
>>signaling, routing)
>>* Is proposal acceptable to ccamp WG
>>* Kireeti: Some routing and signaling defined in hierarchy draft. Here,
>>FA-LSP adverstises aggregate into IGP. Asked presenter to state
>>why this is
>>needed on the mailing list.
>>
>>Fu		   draft-fu-ccamp-traceroute-00.txt
>>-----------------------------------------------
>>* Presented by Xiaoming Fu
>>* A Proposal for Generic Traceroute Over Tunnels
>>* A few issues with current GTTP draft
>>	- each hop supports GTTP
>>	- UDP issues: ports could be blocked by some ISPs, TTL=1,
>>msg size>MTU
>>	- Reverse trace may not traverse same tunnel
>>* Summarized potential solutions described in draft based on NSIS
>>	- Based on two-layer NTLP and NSLP NSIS protocol model
>>	- Can reuse TCP and SCTP to deliver trace messages (address
>>firewall issue)
>>	- NSIS discovery finds next (NSLP?) hop and uses
>>traditional traceroute
>>between NSIS-enabled nodes
>>* Should issues & concepts be considered in traceroute/GTTP design
>>* Bonica (as individual contributor): Q: Does probe sent to destination
>>visit intermediate nodes forward or backward? A: Still investigating. Q:
>>Would have to use alert? A: No, signaling can used without routing alert.
>>Should discovery of next hop be separate from signaling. Q: Is
>>trace control
>>or data plane? A: NSIS direction is discovering data path. Q: Will
>>intermediate routers pass w/o change? A: Yes, traditional traceroute does
>>this.
>>
>>Chairs	   Wrap up
>>----------------------
>>* See you in Minneapolis.
>>* All presenters send slides to bonica and kireeti.
>>
>>
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Wed, 13 Aug 2003 10:47:53 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ron Bonica" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Draft Minutes of ccamp wg meeting
Date: Wed, 13 Aug 2003 11:45:47 +0100

Ron,

> > Farrel    draft-iwata-mpls-crankback-06.txt
> > ------------------------------------------------
> > - New co-author, John Drake

New co-author is Arun Satyanarayana.
John, however, made a very useful suggestion.

Thanks,
Adrian

Delivery-date: Wed, 13 Aug 2003 04:52:49 +0000
Content-Class: urn:content-classes:message
Subject: RE: Draft Minutes of ccamp wg meeting
Date: Tue, 12 Aug 2003 21:51:26 -0700
From: "Jonathan Lang" <[email-masked]>
To: "Ron Bonica" <[email-masked]>, <[email-masked]>

Ron,
  My name is mentioned a couple places with comments from the meeting,
but I didn't attend the meeting.    Based on the comments (and same
first name), I think it might have been Jonathan Sadler.

Thanks,
Jonathan

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]]=20
> Sent: Tuesday, August 12, 2003 8:14 PM
> To: [email-masked]
> Subject: FW: Draft Minutes of ccamp wg meeting
>=20
>=20
> Folks,
>=20
> If nobody objects by COB Wednesday, I will post the following=20
> minutes of the CCAMP WG
>=20
>                                      Ron
>=20
>=20
> >
> > Chairs  	   Doc status - Kireeti presented slides (could not
> > keep notes on
> > all)
> > ------------------------------------------------------------------
> > ----------
> > -----
> > GMPLS signaling for SONET/SDH - RF Ed Q
> > GMPLS Non-std SONET SDH features - killed
> > GMPLS RSVP support for overlay model - authors to respond to list=20
> > comment ASON requirments for signaling - one more update prior to=20
> > straw poll WG last call
> > Exclude routes ext to RSVP-TE - Adrian add appendices to=20
> describe usage
> > Routing ext to support GMPLS - Kireeti did update, planned=20
> mtg prior to WG
> > last call
> > 			           - Number of docs stacked up
> > based on this doc
> > OSPF ext in support of GMPLS - awaiting above
> > ASON routing rqmts - Design team created, members,=20
> milestones and schedule
> > to be posted to list
> > LMP - security section needs work
> > SONET/SDH
> > ??
> > GMPLS recovery - Design team says ready for last call
> > GMPLS MIBs waiting on MPLS MIBs (Adrian - 99% complete)
> > GMPLS architecture - waiting on normative refs
> > GMPLS trace in RFC ed Q
> > Framework for GMPLS-based control of SONET/SDH - Informational
> >
> > Several individual contribs and WG docs not covered. Would like to=20
> > progress the above mature docs.
> >
> > Alanqar	   ITU SG15 Liaisons
> > --------------------------------
> > * Links to liasion statements in slides
> > * Focus is ASON signaling protocol and routing extensions
> > * Thanks extended to chair and invited experts
> > * Snapshot of approved and under development stds
> >
> > * Signaling updates
> > 	- G.7713 terminology alignment with G.8080
> > 	- support for crankback
> > 	- Call/connection separation
> > * Comments on G.7713 solicited
> > * No need to develop alternative solution
> >
> > * Routing updates G.7715.1
> > 	- Goal is consent in Oct 2003 Geneva
> > 	- OSPF ext for ASON
> > 	- Potential use of PNNI
> >
> > * Addressing: signaling, control and management usage important
> > 	- separate address spaces for control and management
> >
> > * Auto discover G.7714.1
> > 	- Further investigation initiated
> > 	- Focus on type A (trail overhead)
> >
> > * Arch for discover & control plane G.disc_arch
> > 	- New scope/title for G.7716
> >
> > * Management framework - new doc created in Chicago G.frame
> > 	- Goal of consent by May 2004
> >
> > No questions
> >
> > Kireeti - ccamp needs to formal liaisons
> >
> > Papadimitriou draft-ietf-ccamp-gmpls-ason-reqts-01.txt
> > ------------------------------------------------------
> > * Presented by Jerry Ash
> > * background, overview, issues presented
> > * History has created need for better communication
> > * Need to continue/ensure joint IETF/ITU-T working team
> > * Much discussion on this draft since work has already been done in=20
> > G.8080
> > * Intent is to have extensions
> > * Six broad areas of requirements
> > 	 - Support for soft permanent connection capability
> >       - Support for call and connection separation
> >       - Support for call segments
> >       - Support for extended restart capabilities during=20
> control plane
> >         failures
> >       - Support for extended label usage
> >       - Support for crankback capability
> >       - Support for additional error cases
> > * Enssure GMPLS extensions interoperable with G.7713.2
> >
> > * Another iteration and then WG last call
> > * Progress signaling extensions
> > * Invitation for participation in routing requirements and protocol=20
> > extensions
> >
> > * No questions nor discussion
> > * Kireeti will float draft of liaison next week for comment
> >
> > Aboul-Magd	   draft-aboulmagd-ccamp-transport-lmp-01.txt
> > ------------------------------------------------------
> > * Could change title to "ASON discovery framework"
> > * Is a terminology "decoder ring" mapping ASON <-> GMPLS=20
> LMP terminology
> > 	- includes port and component link types
> > * G.8080 has transport (data) and control plane discovery with=20
> > separate addresses (draft says name space and not address?)
> > * Proposed considering draft as WG document
> > 	- A number of people had read this draft
> > 	- not a broad consensus in support of this proposal
> > * Lyndon Ong - Good doc, need to resolve decoder ring comments.
> > * Jonathon Lang (Tellabs) - WG23 doc from ITU-T Chicago=20
> discusses some=20
> > of these issues
> > * Malcom Betts - Question on control/data plane addresses in ITU=20
> > documentati on. IP address in header, NHOP, PHOP have transport=20
> > address.  Intent is to clarify usage, if already done then=20
> no need to=20
> > repeat.
> >
> > Papadimitriou Protection and Recovery update
> > --------------------------------------------
> > * Presented by Dimitri
> > * Effort positioning, status and timing over past 1.5 years
> > * Scope: protection, (pre-planned) rerouting, ??
> > * Not covered: local recovery, end-to-end prot., crankback
> > * Summarized comments received
> > * Proposed acceptance as WG document
> > 	- consensus was that this is ready
> > 	- Kireeti - take to the list
> > * Discuss the extra traffic concept in a list thread
> > 	- Dimitri will propose text to clarify this
> >
> > Farrel	   draft-iwata-mpls-crankback-06.txt
> > ------------------------------------------------
> > * Adrian Farrel presented
> > * Has been around for several years and this version is a=20
> major re-spin
> > 	- May be more complex than single node/interface
> > 	- Objective is to fail back to some intermediate point=20
> (e.g., region=20
> > boundary or loose route identified node)
> > 	- Requirement from ASON ITU-T
> > 	- New co-author, John Drake
> > * Summarize major changes in slides
> > 	- long list of TLVs, but no adivce on which to include and when
> > * Wanted to start thread on list re: remaining issues -=20
> some very thorny
> > 	- session attribute bits (all would be used by this draft)
> > 	- too many TLVs, need to confirm all are actually required
> > 	- right place to handle unnumbered bundles
> > 	- Is this the right approach, or should RRO be used?
> > * Feedback solicited, resolve open issues
> > * Add pointer from ASON signaling since it is long (different from=20
> > slide
> > presented)
> > * Kireeti: close on issues, bounce use of final 3 bits off MPLS WG
> > 	- decide on approach (TLVs vs RRO) and with new charter
> > decide on WG status
> > * Dimitri - What is the basic set of TLVs needed and then=20
> address larger
> > scope.
> > * Adrian - What is needed is implementation dependent. Need input
> > from other
> > service providers.
> > * Kireeti: relate this to multi-area, multi-AS documents=20
> since a primary
> > application is setup failures in multi-region.
> > * Adrian: Need more explicity requirements from te-wg on crankback
> > requirements.
> >
> > Kim	         draft-kim-ccamp-cc-protection-03.txt
> > ---------------------------------------------------
> > * Presented by Young Hwa Kim
> > * Summarized survivability of control channels and=20
> neworks(from G.807)
> > 	- assoc, non-assoc, quasi-assoc, in or out of fiber, SCN/ASTN=20
> > implementation
> > * Stated problem as no provision of protection features in current=20
> > GMPLS control plane
> > * Summarized requirements and functions for resilience of=20
> control plane
> > 	- e.g., primary and secondary on separate fibers (shown=20
> in figure)
> > * Next steps: proposed refine/complete requirements, 	protocol
> > specification, WG document in 2003/2004
> >
> > * Aboul-Magd: Are control channels visible to LMP? Why are current=20
> > control plane methods not sufficient? What are the deficiences?
> > * Kireeti: Control plane is an IP network, not trying to=20
> redesign IP=20
> > resiliency. Are some issues: is graceful restart=20
> sufficient? Need to=20
> > convince WG that there is a problem to resolve. Do this on=20
> the mailing=20
> > list.
> > * Kim: Gigabit Ethernet has no protection, but SONET/SDH and Lamba=20
> > network does.
> > *  Malcom Betts - Control plane relies on IP network resiliency.=20
> > G.8080 has a number of resiliency considerations listed.
> >
> > Rabbat	   draft-rabbat-optical-recovery-reqs-00.txt et al
> > --------------------------------------------------------------
> > * Summarized changes
> > * Solicited feedback
> > * Kireeti: Had requirements from te-wg, keep this as separate doc,=20
> > start thread on mailing list
> > * Draft stable, proposed adoption as WG draft
> > * Need more discussion on WG list
> >
> > * soumiya-lmp-fault (not on agenda from Bonica)
> > -----------------------------------------------
> > * How we reduce message overhead slide
> > * Alex Zinin - Q: Is flooding done reliably? A: Yes. Need=20
> to include=20
> > acknowledgement messages when assessing complexity.
> > * Adrian: arrows on lhs (signaling) indicate a pair of messages for=20
> > signaling.
> > * Kireeti: Was discussion comparing signaling message vs sending=20
> > flooding messages. Signaling is often faster (contrary to=20
> stmt that it=20
> > is slower). Flooding has a hold down timer aspect, but signaling is=20
> > faster. Issue with using LSPs for flooding since they are=20
> link local -=20
> > seems redundant with IGP (OSPF, IS-IS). Usurps LMP for different=20
> > purpose. Important point is that flooding is slower, but fewer=20
> > messages as compared with signaling.  Should discuss=20
> further on list.=20
> > Concerned about resolving problem of flooding already solved in GP.
> > * Aboul-Magd: Same comment as Kireeti. Need to synchronize=20
> signaling and
> > routing. Don't understand why there is a need for this.
> > * Jonathon Lang: Concern that message indicates a fiber cut and
> > not messages
> > for each affected LSP. A: Protection algorithms expect knowledge
> > that nodes
> > know this mapping at a protection point. Issue is that=20
> nodes may not know
> > this mapping when multiple levels of indirection exist. Presenter
> > requested
> > feedback on the list.
> > * Bonica: Take further discussion to the list.
> >
> > Shiomoto	   draft-pil-ccamp-extra-lsp-00.txt
> > -----------------------------------------------
> > * Presented by Shimoto
> > * Brief overview of draft for shared mesh restoration
> > 	- protecting LSP resource is reserved, but not cross-connected
> > 	- extra class LSP can use this unused restoration=20
> capacity, which is=20
> > preemptable when needed for restoration (expected to be=20
> rare occurence)
> > 	- problems: advertise available resources, LSP indications and=20
> > preemption in signaling, prevent unintended connections,=20
> also protect=20
> > confidentiality
> > * Discuss comments from mailing list
> > 	- can do using existing priority mechanisms where extra=20
> class has=20
> > lower holding priority than restoration LSP
> > 	- complexity
> > 	- soft preemption (not addressed in this draft)
> > * Solicit comments/feedback
> > * Proposed accepting this for ccamp wg
> > * Dimitri: Question re: soft preemption as document or=20
> charter? A: Propose
> > adding to charter.
> > * JP Vasseur: Elaborate on soft preemption. A: Need to=20
> describe concept in
> > this draft. Q: Are you aware of draft on soft preemption? A: No.
> > Q: What is
> > to be done with existing mechanisms?
> > * Kireeti: Can be achieved with current mechanisms. Discuss on list.
> > Proposed action was for Dimitri/JP Vasseur to describe on list
> > how this can
> > be done using existing mechanisms and Shiomoto to identify what
> > is missing.
> >
> > Papadimitriou draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
> > -----------------------------------------------------------
> > * Presented by Deborah Brungard
> > * Address requirements in GMPLS ASON presented earlier
> > * Backward/forward compatible with GMPLS
> > * Agnostic to network UNI implementation
> > * Call/connection separation objects simply forwarded and not=20
> > processed
> > * Described proposed mechanism for call/connection=20
> separation in detail
> > * Summarized other additional ASON functionalities
> > * Next version - add crankback signaling and call segments
> > * Solicting feedback
> > * Lyndon Ong: Requesting interpretation of "backward=20
> compatibility" 7713.2
> > interpretation is to carry an object if is not understood.
> > * Kireeti: Need liaison to ITU-T with comments on 7713,=20
> 7713.2, and ITU-T
> > liaisons and then decide how to progress this document.
> >
> > Ali draft-zamfir-explicit-resource-control-bundle-01.txt
> > --------------------------------------------------------
> > * Presented by Zafar Ali
> > * Explicit Resrouce Control and Recording
> > 	- Unbundled or bundled TE link type
> > 	- Focus is case where component interface cannot be
> > inferred from label
> > value
> > * Current spec supports unbundled case for LSP splicing uni- and=20
> > bi-directional
> > * Can support bundled case by specifying component ID for=20
> LSP splicing
> > * Cannot support bundled case for LSP splicing when forward and=20
> > backward component IDs are different in bi-directional
> > * Propose optional interface identifier ERO subobject to=20
> address this=20
> > case
> > * RRO with label recording
> > 	- could use to signal label values used within the bundle
> > 	- cannot currently identify component interface used=20
> withing bundle
> > 	- proposed solution is interface identifier RRO subobject,
> > similar to above
> > * Propose accepting this as WG doc
> > * Kireeti: Missing element in taxonomy (matrix) of these=20
> approaches not
> > sufficient for WG adoption. Understand RRO case. What is
> > motivation for ERO?
> > A: Could have case where component links are different=20
> where upstream and
> > downstream differ. Bundle draft says that up- and down-stream can
> > differ. Q:
> > Why don't the local nodes assign this (and communicate selection
> > in RRO). A:
> > Consideration is on egress specification of component ID.=20
> Don't understand
> > resistance.
> > * Kireeti: Post rationale to the list, beyond missing support in
> > taxonomy/martix for both RRO and ERO cases. If agreement, then
> > can proceed.
> > * Swallow: Provider feedback is to keep up- and down-stream=20
> on same fiber
> > (pair).
> > * Dimitri: Can provide examples for RRO, but believes there will
> > be few for
> > ERO. Please expand compatibility statement in the last section.
> >
> > Choi	         draft-choi-gmpls-resource-mapping-00.txt
> > -------------------------------------------------------
> > *  Resource Mapping for GMPLS with Heterogeneous Interfaces
> > * Problem: Label format for optical interface defined, but specific=20
> > mapping rule is not
> > 	- Identify fiber, waveband, and lambda labels
> > * Issue -1
> > 	- Need aggregation for sharing in protection/restoration
> > 	- Support mechanism similar to label stacking in electrical
> > domain for
> > optical interfaces
> > * Issue -2
> > 	- Logical resoure aggregation at switching interface -
> > mapping, aggregation
> > 	(examples given)
> > 	- Miscellaneous other issues (unnumbered links, bundling,
> > SRLG mapping,
> > signaling, routing)
> > * Is proposal acceptable to ccamp WG
> > * Kireeti: Some routing and signaling defined in hierarchy=20
> draft. Here,
> > FA-LSP adverstises aggregate into IGP. Asked presenter to state
> > why this is
> > needed on the mailing list.
> >
> > Fu		   draft-fu-ccamp-traceroute-00.txt
> > -----------------------------------------------
> > * Presented by Xiaoming Fu
> > * A Proposal for Generic Traceroute Over Tunnels
> > * A few issues with current GTTP draft
> > 	- each hop supports GTTP
> > 	- UDP issues: ports could be blocked by some ISPs, TTL=3D1, msg=20
> > size>MTU
> > 	- Reverse trace may not traverse same tunnel
> > * Summarized potential solutions described in draft based on NSIS
> > 	- Based on two-layer NTLP and NSLP NSIS protocol model
> > 	- Can reuse TCP and SCTP to deliver trace messages=20
> (address firewall=20
> > issue)
> > 	- NSIS discovery finds next (NSLP?) hop and uses
> > traditional traceroute
> > between NSIS-enabled nodes
> > * Should issues & concepts be considered in traceroute/GTTP design
> > * Bonica (as individual contributor): Q: Does probe sent to=20
> > destination visit intermediate nodes forward or backward? A: Still=20
> > investigating. Q: Would have to use alert? A: No, signaling=20
> can used=20
> > without routing alert. Should discovery of next hop be=20
> separate from=20
> > signaling. Q: Is trace control or data plane? A: NSIS direction is=20
> > discovering data path. Q: Will intermediate routers pass=20
> w/o change?=20
> > A: Yes, traditional traceroute does this.
> >
> > Chairs	   Wrap up
> > ----------------------
> > * See you in Minneapolis.
> > * All presenters send slides to bonica and kireeti.
> >
> >
>=20
>=20
>=20

Delivery-date: Wed, 13 Aug 2003 03:19:27 +0000
Date: Tue, 12 Aug 2003 23:13:45 -0400
From: Ron Bonica <[email-masked]>
Subject: FW: Draft Minutes of ccamp wg meeting
To: [email-masked]

Folks,

If nobody objects by COB Wednesday, I will post the following minutes of the
CCAMP WG

                                     Ron

>
> Chairs  	   Doc status - Kireeti presented slides (could not
> keep notes on
> all)
> ------------------------------------------------------------------
> ----------
> -----
> GMPLS signaling for SONET/SDH - RF Ed Q
> GMPLS Non-std SONET SDH features - killed
> GMPLS RSVP support for overlay model - authors to respond to list comment
> ASON requirments for signaling - one more update prior to straw
> poll WG last
> call
> Exclude routes ext to RSVP-TE - Adrian add appendices to describe usage
> Routing ext to support GMPLS - Kireeti did update, planned mtg prior to WG
> last call
> 			           - Number of docs stacked up
> based on this doc
> OSPF ext in support of GMPLS - awaiting above
> ASON routing rqmts - Design team created, members, milestones and schedule
> to be posted to list
> LMP - security section needs work
> SONET/SDH
> ??
> GMPLS recovery - Design team says ready for last call
> GMPLS MIBs waiting on MPLS MIBs (Adrian - 99% complete)
> GMPLS architecture - waiting on normative refs
> GMPLS trace in RFC ed Q
> Framework for GMPLS-based control of SONET/SDH - Informational
>
> Several individual contribs and WG docs not covered. Would like
> to progress
> the above mature docs.
>
> Alanqar	   ITU SG15 Liaisons
> --------------------------------
> * Links to liasion statements in slides
> * Focus is ASON signaling protocol and routing extensions
> * Thanks extended to chair and invited experts
> * Snapshot of approved and under development stds
>
> * Signaling updates
> 	- G.7713 terminology alignment with G.8080
> 	- support for crankback
> 	- Call/connection separation
> * Comments on G.7713 solicited
> * No need to develop alternative solution
>
> * Routing updates G.7715.1
> 	- Goal is consent in Oct 2003 Geneva
> 	- OSPF ext for ASON
> 	- Potential use of PNNI
>
> * Addressing: signaling, control and management usage important
> 	- separate address spaces for control and management
>
> * Auto discover G.7714.1
> 	- Further investigation initiated
> 	- Focus on type A (trail overhead)
>
> * Arch for discover & control plane G.disc_arch
> 	- New scope/title for G.7716
>
> * Management framework - new doc created in Chicago G.frame
> 	- Goal of consent by May 2004
>
> No questions
>
> Kireeti - ccamp needs to formal liaisons
>
> Papadimitriou draft-ietf-ccamp-gmpls-ason-reqts-01.txt
> ------------------------------------------------------
> * Presented by Jerry Ash
> * background, overview, issues presented
> * History has created need for better communication
> * Need to continue/ensure joint IETF/ITU-T working team
> * Much discussion on this draft since work has already been done in G.8080
> * Intent is to have extensions
> * Six broad areas of requirements
> 	 - Support for soft permanent connection capability
>       - Support for call and connection separation
>       - Support for call segments
>       - Support for extended restart capabilities during control plane
>         failures
>       - Support for extended label usage
>       - Support for crankback capability
>       - Support for additional error cases
> * Enssure GMPLS extensions interoperable with G.7713.2
>
> * Another iteration and then WG last call
> * Progress signaling extensions
> * Invitation for participation in routing requirements and protocol
> extensions
>
> * No questions nor discussion
> * Kireeti will float draft of liaison next week for comment
>
> Aboul-Magd	   draft-aboulmagd-ccamp-transport-lmp-01.txt
> ------------------------------------------------------
> * Could change title to "ASON discovery framework"
> * Is a terminology "decoder ring" mapping ASON <-> GMPLS LMP terminology
> 	- includes port and component link types
> * G.8080 has transport (data) and control plane discovery with separate
> addresses (draft says name space and not address?)
> * Proposed considering draft as WG document
> 	- A number of people had read this draft
> 	- not a broad consensus in support of this proposal
> * Lyndon Ong - Good doc, need to resolve decoder ring comments.
> * Jonathon Lang (Tellabs) - WG23 doc from ITU-T Chicago discusses some of
> these issues
> * Malcom Betts - Question on control/data plane addresses in ITU
> documentati
> on. IP address in header, NHOP, PHOP have transport address.  Intent is to
> clarify usage, if already done then no need to repeat.
>
> Papadimitriou Protection and Recovery update
> --------------------------------------------
> * Presented by Dimitri
> * Effort positioning, status and timing over past 1.5 years
> * Scope: protection, (pre-planned) rerouting, ??
> * Not covered: local recovery, end-to-end prot., crankback
> * Summarized comments received
> * Proposed acceptance as WG document
> 	- consensus was that this is ready
> 	- Kireeti - take to the list
> * Discuss the extra traffic concept in a list thread
> 	- Dimitri will propose text to clarify this
>
> Farrel	   draft-iwata-mpls-crankback-06.txt
> ------------------------------------------------
> * Adrian Farrel presented
> * Has been around for several years and this version is a major re-spin
> 	- May be more complex than single node/interface
> 	- Objective is to fail back to some intermediate point (e.g., region
> boundary or loose route identified node)
> 	- Requirement from ASON ITU-T
> 	- New co-author, John Drake
> * Summarize major changes in slides
> 	- long list of TLVs, but no adivce on which to include and when
> * Wanted to start thread on list re: remaining issues - some very thorny
> 	- session attribute bits (all would be used by this draft)
> 	- too many TLVs, need to confirm all are actually required
> 	- right place to handle unnumbered bundles
> 	- Is this the right approach, or should RRO be used?
> * Feedback solicited, resolve open issues
> * Add pointer from ASON signaling since it is long (different from slide
> presented)
> * Kireeti: close on issues, bounce use of final 3 bits off MPLS WG
> 	- decide on approach (TLVs vs RRO) and with new charter
> decide on WG status
> * Dimitri - What is the basic set of TLVs needed and then address larger
> scope.
> * Adrian - What is needed is implementation dependent. Need input
> from other
> service providers.
> * Kireeti: relate this to multi-area, multi-AS documents since a primary
> application is setup failures in multi-region.
> * Adrian: Need more explicity requirements from te-wg on crankback
> requirements.
>
> Kim	         draft-kim-ccamp-cc-protection-03.txt
> ---------------------------------------------------
> * Presented by Young Hwa Kim
> * Summarized survivability of control channels and neworks(from G.807)
> 	- assoc, non-assoc, quasi-assoc, in or out of fiber, SCN/ASTN
> implementation
> * Stated problem as no provision of protection features in current GMPLS
> control plane
> * Summarized requirements and functions for resilience of control plane
> 	- e.g., primary and secondary on separate fibers (shown in figure)
> * Next steps: proposed refine/complete requirements, 	protocol
> specification, WG document in 2003/2004
>
> * Aboul-Magd: Are control channels visible to LMP? Why are current control
> plane methods not sufficient? What are the deficiences?
> * Kireeti: Control plane is an IP network, not trying to redesign IP
> resiliency. Are some issues: is graceful restart sufficient? Need to
> convince WG that there is a problem to resolve. Do this on the
> mailing list.
> * Kim: Gigabit Ethernet has no protection, but SONET/SDH and Lamba network
> does.
> *  Malcom Betts - Control plane relies on IP network resiliency.
> G.8080 has
> a number of resiliency considerations listed.
>
> Rabbat	   draft-rabbat-optical-recovery-reqs-00.txt et al
> --------------------------------------------------------------
> * Summarized changes
> * Solicited feedback
> * Kireeti: Had requirements from te-wg, keep this as separate doc, start
> thread on mailing list
> * Draft stable, proposed adoption as WG draft
> * Need more discussion on WG list
>
> * soumiya-lmp-fault (not on agenda from Bonica)
> -----------------------------------------------
> * How we reduce message overhead slide
> * Alex Zinin - Q: Is flooding done reliably? A: Yes. Need to include
> acknowledgement messages when assessing complexity.
> * Adrian: arrows on lhs (signaling) indicate a pair of messages for
> signaling.
> * Kireeti: Was discussion comparing signaling message vs sending flooding
> messages. Signaling is often faster (contrary to stmt that it is slower).
> Flooding has a hold down timer aspect, but signaling is faster. Issue with
> using LSPs for flooding since they are link local - seems
> redundant with IGP
> (OSPF, IS-IS). Usurps LMP for different purpose. Important point is that
> flooding is slower, but fewer messages as compared with signaling.  Should
> discuss further on list. Concerned about resolving problem of flooding
> already solved in GP.
> * Aboul-Magd: Same comment as Kireeti. Need to synchronize signaling and
> routing. Don't understand why there is a need for this.
> * Jonathon Lang: Concern that message indicates a fiber cut and
> not messages
> for each affected LSP. A: Protection algorithms expect knowledge
> that nodes
> know this mapping at a protection point. Issue is that nodes may not know
> this mapping when multiple levels of indirection exist. Presenter
> requested
> feedback on the list.
> * Bonica: Take further discussion to the list.
>
> Shiomoto	   draft-pil-ccamp-extra-lsp-00.txt
> -----------------------------------------------
> * Presented by Shimoto
> * Brief overview of draft for shared mesh restoration
> 	- protecting LSP resource is reserved, but not cross-connected
> 	- extra class LSP can use this unused restoration capacity, which is
> preemptable when needed for restoration (expected to be rare occurence)
> 	- problems: advertise available resources, LSP indications
> and preemption
> in signaling, prevent unintended connections, also protect confidentiality
> * Discuss comments from mailing list
> 	- can do using existing priority mechanisms where extra
> class has lower
> holding priority than restoration LSP
> 	- complexity
> 	- soft preemption (not addressed in this draft)
> * Solicit comments/feedback
> * Proposed accepting this for ccamp wg
> * Dimitri: Question re: soft preemption as document or charter? A: Propose
> adding to charter.
> * JP Vasseur: Elaborate on soft preemption. A: Need to describe concept in
> this draft. Q: Are you aware of draft on soft preemption? A: No.
> Q: What is
> to be done with existing mechanisms?
> * Kireeti: Can be achieved with current mechanisms. Discuss on list.
> Proposed action was for Dimitri/JP Vasseur to describe on list
> how this can
> be done using existing mechanisms and Shiomoto to identify what
> is missing.
>
> Papadimitriou draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
> -----------------------------------------------------------
> * Presented by Deborah Brungard
> * Address requirements in GMPLS ASON presented earlier
> * Backward/forward compatible with GMPLS
> * Agnostic to network UNI implementation
> * Call/connection separation objects simply forwarded and not processed
> * Described proposed mechanism for call/connection separation in detail
> * Summarized other additional ASON functionalities
> * Next version - add crankback signaling and call segments
> * Solicting feedback
> * Lyndon Ong: Requesting interpretation of "backward compatibility" 7713.2
> interpretation is to carry an object if is not understood.
> * Kireeti: Need liaison to ITU-T with comments on 7713, 7713.2, and ITU-T
> liaisons and then decide how to progress this document.
>
> Ali draft-zamfir-explicit-resource-control-bundle-01.txt
> --------------------------------------------------------
> * Presented by Zafar Ali
> * Explicit Resrouce Control and Recording
> 	- Unbundled or bundled TE link type
> 	- Focus is case where component interface cannot be
> inferred from label
> value
> * Current spec supports unbundled case for LSP splicing uni- and
> bi-directional
> * Can support bundled case by specifying component ID for LSP splicing
> * Cannot support bundled case for LSP splicing when forward and backward
> component IDs are different in bi-directional
> * Propose optional interface identifier ERO subobject to address this case
> * RRO with label recording
> 	- could use to signal label values used within the bundle
> 	- cannot currently identify component interface used withing bundle
> 	- proposed solution is interface identifier RRO subobject,
> similar to above
> * Propose accepting this as WG doc
> * Kireeti: Missing element in taxonomy (matrix) of these approaches not
> sufficient for WG adoption. Understand RRO case. What is
> motivation for ERO?
> A: Could have case where component links are different where upstream and
> downstream differ. Bundle draft says that up- and down-stream can
> differ. Q:
> Why don't the local nodes assign this (and communicate selection
> in RRO). A:
> Consideration is on egress specification of component ID. Don't understand
> resistance.
> * Kireeti: Post rationale to the list, beyond missing support in
> taxonomy/martix for both RRO and ERO cases. If agreement, then
> can proceed.
> * Swallow: Provider feedback is to keep up- and down-stream on same fiber
> (pair).
> * Dimitri: Can provide examples for RRO, but believes there will
> be few for
> ERO. Please expand compatibility statement in the last section.
>
> Choi	         draft-choi-gmpls-resource-mapping-00.txt
> -------------------------------------------------------
> *  Resource Mapping for GMPLS with Heterogeneous Interfaces
> * Problem: Label format for optical interface defined, but
> specific mapping
> rule is not
> 	- Identify fiber, waveband, and lambda labels
> * Issue -1
> 	- Need aggregation for sharing in protection/restoration
> 	- Support mechanism similar to label stacking in electrical
> domain for
> optical interfaces
> * Issue -2
> 	- Logical resoure aggregation at switching interface -
> mapping, aggregation
> 	(examples given)
> 	- Miscellaneous other issues (unnumbered links, bundling,
> SRLG mapping,
> signaling, routing)
> * Is proposal acceptable to ccamp WG
> * Kireeti: Some routing and signaling defined in hierarchy draft. Here,
> FA-LSP adverstises aggregate into IGP. Asked presenter to state
> why this is
> needed on the mailing list.
>
> Fu		   draft-fu-ccamp-traceroute-00.txt
> -----------------------------------------------
> * Presented by Xiaoming Fu
> * A Proposal for Generic Traceroute Over Tunnels
> * A few issues with current GTTP draft
> 	- each hop supports GTTP
> 	- UDP issues: ports could be blocked by some ISPs, TTL=1,
> msg size>MTU
> 	- Reverse trace may not traverse same tunnel
> * Summarized potential solutions described in draft based on NSIS
> 	- Based on two-layer NTLP and NSLP NSIS protocol model
> 	- Can reuse TCP and SCTP to deliver trace messages (address
> firewall issue)
> 	- NSIS discovery finds next (NSLP?) hop and uses
> traditional traceroute
> between NSIS-enabled nodes
> * Should issues & concepts be considered in traceroute/GTTP design
> * Bonica (as individual contributor): Q: Does probe sent to destination
> visit intermediate nodes forward or backward? A: Still investigating. Q:
> Would have to use alert? A: No, signaling can used without routing alert.
> Should discovery of next hop be separate from signaling. Q: Is
> trace control
> or data plane? A: NSIS direction is discovering data path. Q: Will
> intermediate routers pass w/o change? A: Yes, traditional traceroute does
> this.
>
> Chairs	   Wrap up
> ----------------------
> * See you in Minneapolis.
> * All presenters send slides to bonica and kireeti.
>
>

Delivery-date: Sat, 09 Aug 2003 16:24:10 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Michael Mandelberg" <[email-masked]>, <[email-masked]>
Subject: Re: Direction of LSP in ERO
Date: Sat, 9 Aug 2003 17:19:25 +0100

Yes.
The interpretation of ERO hops is 'strictly' limited to the scope of the hop. Later hops
will have no idea what happened in earlier hops. Early hops SHOULD NOT browse ahead in the
ERO.
Adrian
----- Original Message ----- 
From: "Michael Mandelberg" <[email-masked]>
To: <[email-masked]>
Sent: Friday, August 08, 2003 2:53 AM
Subject: Direction of LSP in ERO

> Is it allowed for the different hops in the ERO to have different structure.
> For example, coud one hop specify both an upstream and a dowstream label
> while another specifies just a downstream label?
>
> Thanks
>
> Michael Mandelberg
>
>

Delivery-date: Fri, 08 Aug 2003 16:22:30 +0000
Content-Class: urn:content-classes:message
Subject: RE: Clarification request on rate fields in LMP
Date: Fri, 8 Aug 2003 09:20:36 -0700
From: "Jonathan Lang" <[email-masked]>
To: "Bradford, Richard" <[email-masked]>
Cc: <[email-masked]>

Richard,
The Reservable bandwidth fields should correlate with the reservable
bandwidth fields of GMPLS routing/signaling (without the notion of
priority).  I.e., the reservable bandwidth field is defined in gmpls
routing as follows: " Reservable Bandwidth per priority, which specifies
the bandwidth of an LSP that could be supported by the interface at a
given priority number."

Thanks,
Jonathan

> -----Original Message-----
> From: Bradford, Richard [mailto:[email-masked]]=20
> Sent: Wednesday, August 06, 2003 1:14 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Clarification request on rate fields in LMP
>=20
>=20
> Some different interpretations for the various rates in LMP=20
> messages have come to my attention. These involve the Minimum=20
> Reservable Bandwidth and Maximum Reservable Bandwidth in a=20
> LinkSummary message. One interpretation is that the=20
> Reservable Bandwidths at least should represent only the=20
> payload portion of the bandwidth. An alternate interpretation=20
> is that all these fields should include all overhead.
>=20
> Let's take the case of a STM-4 Interface, which supports=20
> signalling of individual VC-4 circuits.
>=20
>=20
> Position 1: Raw bandwidth should be used so the values should be:
>  Minimum Reservable Bandwidth =3D OC-3/STM-1   (155.52 Mbps)
>  Maximum Reservable Bandwidth =3D OC-12/STM-4  (622.08 Mbps)
>=20
> Position 2: Since for SDH the TDM circuits will be signalled=20
> either as individual VC-4s or as a single VC-4-4c, therefore=20
> the values should be:
>=20
>  Minimum Reservable Bandwidth =3D VC-4 (149.760 Mbps) =20
>  Maximum Reservable Bandwidth =3D VC-4-4c (599.040 Mbps)
>=20
> Other interpretations?
>=20
> The following are the values from generalized-signaling
>=20
>         Signal Type   (Bit-rate)              Value (Bytes/Sec)
>                                             (IEEE Floating point)
>       --------------  ---------------       ---------------------
>                  DS0  (0.064 Mbps)              0x45FA0000
>                  DS1  (1.544 Mbps)              0x483C7A00
>                   E1  (2.048 Mbps)              0x487A0000
>                  DS2  (6.312 Mbps)              0x4940A080
>                   E2  (8.448 Mbps)              0x4980E800
>             Ethernet  (10.00 Mbps)              0x49989680
>                   E3  (34.368 Mbps)             0x4A831A80
>                  DS3  (44.736 Mbps)             0x4AAAA780
>                STS-1  (51.84 Mbps)              0x4AC5C100
>                   E4  (139.264 Mbps)            0x4B84D000
>           OC-3/STM-1  (155.52 Mbps)             0x4B9450C0
>          OC-12/STM-4  (622.08 Mbps)             0x4C9450C0
>         OC-48/STM-16  (2488.32 Mbps)            0x4D9450C0
>        OC-192/STM-64  (9953.28 Mbps)            0x4E9450C0
>       OC-768/STM-256  (39813.12 Mbps)           0x4F9450C0
>=20

Delivery-date: Fri, 08 Aug 2003 01:58:56 +0000
From: Michael Mandelberg <[email-masked]>
To: [email-masked]
Subject: Direction of LSP in ERO
Date: Thu, 7 Aug 2003 21:53:51 -0400 

Is it allowed for the different hops in the ERO to have different structure.
For example, coud one hop specify both an upstream and a dowstream label
while another specifies just a downstream label?

Thanks

Michael Mandelberg

Delivery-date: Thu, 07 Aug 2003 02:48:22 +0000
From: Michael Mandelberg <[email-masked]>
To: 'ramasamy ramanathan' <[email-masked]>, [email-masked]
Subject: RE: clarification.
Date: Wed, 6 Aug 2003 22:44:32 -0400 

There is the Acceptable Label Set. It can be included in the Path Err if the
Upstream Label is unacceptable.

Michael Mandelberg

-----Original Message-----
From: ramasamy ramanathan [mailto:[email-masked]]
Sent: Wednesday, August 06, 2003 9:11 PM
To: [email-masked]
Subject: clarification.

hi all,

Could anyone help me out with the following question?

For bi-directonal LSP, we specify upstream label in PATH message. For the
FORWARD direction we can specify label set or suggested label, so that
narrowing the nexthop label allocation range. thereby reducing the
probabaility of failure. For REVERSE path we don't have anything, while
sending the PATH message, we allocate a label and send it out without taking
the input from the nexthop. so the probablitiy of nextnode sending the error
message to this upstream label is more right? is there any mechanism to
avoid this?

thanks
rams.

Delivery-date: Thu, 07 Aug 2003 01:58:45 +0000
From: "ramasamy ramanathan" <[email-masked]>
To: <[email-masked]>
Subject: clarification.
Date: Wed, 6 Aug 2003 19:11:10 -0700

hi all,

Could anyone help me out with the following question?

For bi-directonal LSP, we specify upstream label in PATH message. For the
FORWARD direction we can specify label set or suggested label, so that
narrowing the nexthop label allocation range. thereby reducing the
probabaility of failure. For REVERSE path we don't have anything, while
sending the PATH message, we allocate a label and send it out without taking
the input from the nexthop. so the probablitiy of nextnode sending the error
message to this upstream label is more right? is there any mechanism to
avoid this?

thanks
rams.

Delivery-date: Wed, 06 Aug 2003 20:16:32 +0000
Date: Wed, 06 Aug 2003 16:13:36 -0400
To: [email-masked]
From: "Bradford, Richard" <[email-masked]>
Subject: Clarification request on rate fields in LMP
Cc: [email-masked]

--=====================_198897128==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Some different interpretations for the various rates in LMP messages have 
come to my attention. These involve the Minimum Reservable Bandwidth and 
Maximum Reservable Bandwidth in a LinkSummary message.
One interpretation is that the Reservable Bandwidths at least should 
represent only the payload portion of the bandwidth. An alternate 
interpretation is that all these fields should include all overhead.

Let's take the case of a STM-4 Interface, which supports signalling of 
individual VC-4 circuits.

Position 1: Raw bandwidth should be used so the values should be:
  Minimum Reservable Bandwidth = OC-3/STM-1   (155.52 Mbps)
  Maximum Reservable Bandwidth = OC-12/STM-4  (622.08 Mbps)

Position 2: Since for SDH the TDM circuits will be signalled either as 
individual VC-4s or as a single VC-4-4c, therefore the values should be:

  Minimum Reservable Bandwidth = VC-4 (149.760 Mbps)
  Maximum Reservable Bandwidth = VC-4-4c (599.040 Mbps)

Other interpretations?

The following are the values from generalized-signaling
>         Signal Type   (Bit-rate)              Value (Bytes/Sec)
>                                             (IEEE Floating point)
>       --------------  ---------------       ---------------------
>                  DS0  (0.064 Mbps)              0x45FA0000
>                  DS1  (1.544 Mbps)              0x483C7A00
>                   E1  (2.048 Mbps)              0x487A0000
>                  DS2  (6.312 Mbps)              0x4940A080
>                   E2  (8.448 Mbps)              0x4980E800
>             Ethernet  (10.00 Mbps)              0x49989680
>                   E3  (34.368 Mbps)             0x4A831A80
>                  DS3  (44.736 Mbps)             0x4AAAA780
>                STS-1  (51.84 Mbps)              0x4AC5C100
>                   E4  (139.264 Mbps)            0x4B84D000
>           OC-3/STM-1  (155.52 Mbps)             0x4B9450C0
>          OC-12/STM-4  (622.08 Mbps)             0x4C9450C0
>         OC-48/STM-16  (2488.32 Mbps)            0x4D9450C0
>        OC-192/STM-64  (9953.28 Mbps)            0x4E9450C0
>       OC-768/STM-256  (39813.12 Mbps)           0x4F9450C0

--=====================_198897128==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font face="Courier New, Courier" size=3>Some different interpretations
for the various rates in LMP messages have come to my attention. These
involve </font><font face="Courier New, Courier" size=2>the Minimum
Reservable Bandwidth and Maximum Reservable Bandwidth in a LinkSummary
message.<br>
One interpretation is that the Reservable Bandwidths at least should
represent only the payload portion of the bandwidth. An alternate
interpretation is that all these fields should include all 
overhead.<br>
<br>
Let's take the case of a STM-4 Interface, which supports signalling of
individual VC-4 circuits.<br>
<br>
<br>
Position 1: Raw bandwidth should be used so the values should be:<br>
&nbsp;Minimum Reservable Bandwidth = OC-3/STM-1&nbsp;&nbsp; (155.52
Mbps)<br>
&nbsp;Maximum Reservable Bandwidth = OC-12/STM-4&nbsp; (622.08 
Mbps)<br>
<br>
Position 2: Since for SDH the TDM circuits will be signalled either as
individual VC-4s or as a single VC-4-4c, therefore the values should
be:<br>
<br>
&nbsp;Minimum Reservable Bandwidth = VC-4 (149.760 Mbps)&nbsp; <br>
&nbsp;Maximum Reservable Bandwidth = VC-4-4c (599.040 Mbps)<br>
<br>
Other interpretations?<br>
<br>
The following are the values from generalized-signaling<br>
<blockquote type=cite cite>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Signal Type&nbsp;&nbsp;
(Bit-rate)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Value (Bytes/Sec)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(IEEE Floating point)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --------------&nbsp;
---------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
---------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DS0&nbsp; (0.064
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x45FA0000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DS1&nbsp; (1.544
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x483C7A00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
E1&nbsp; (2.048
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x487A0000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DS2&nbsp; (6.312
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x4940A080<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
E2&nbsp; (8.448
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x4980E800<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Ethernet&nbsp; (10.00
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x49989680<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
E3&nbsp; (34.368
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x4A831A80<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DS3&nbsp; (44.736
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x4AAAA780<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
STS-1&nbsp; (51.84
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x4AC5C100<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
E4&nbsp; (139.264
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x4B84D000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OC-3/STM-1&nbsp;
(155.52
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x4B9450C0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OC-12/STM-4&nbsp;
(622.08
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x4C9450C0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OC-48/STM-16&nbsp; (2488.32
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x4D9450C0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OC-192/STM-64&nbsp; (9953.28
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x4E9450C0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OC-768/STM-256&nbsp; (39813.12
Mbps)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0x4F9450C0</font></blockquote><br>

<font face="Courier, Courier"></font></html>

--=====================_198897128==_.ALT--

Delivery-date: Tue, 05 Aug 2003 01:56:17 +0000
From: Michael Mandelberg <[email-masked]>
To: [email-masked]
Subject: Label Set question
Date: Mon, 4 Aug 2003 21:51:22 -0400 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C35AF4.128F3100
Content-Type: text/plain;
	charset="windows-1255"

How does the label set work with waveband labels? For the list form, are the
subobjects waveband ids, or are the start and stop values listed as well?
For the range form, again is it just ids? If not, then how is ordering
defined to deterimine whether another band laebl is within the range?
 
Thanks
 
Michael Mandelberg

------_=_NextPart_001_01C35AF4.128F3100
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">

<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<META content=3D"Microsoft Word 9" name=3DOriginator><LINK=20
href=3D"cid:[email-masked]" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt =
72.0pt 90.0pt; mso-header-margin: 35.4pt; mso-footer-margin: 35.4pt; =
mso-paper-source: 0; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
P.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
LI.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
DIV.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Courier New"
}
SPAN.EmailStyle15 {
	COLOR: black; mso-style-type: personal-compose; mso-ansi-font-size: =
10.0pt; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; =
mso-bidi-font-family: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: 36.0pt">
<DIV><SPAN class=3D656514501-05082003><FONT color=3D#000000 =
size=3D2>How does the=20
label set work with waveband labels? For the list form, are the =
subobjects=20
waveband ids, or are the start and stop values listed as well? For the =
range=20
form, again is it just ids? If not, then how is ordering defined to =
deterimine=20
whether another band laebl is within the range?</FONT></SPAN></DIV>
<DIV><SPAN class=3D656514501-05082003><FONT =
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D656514501-05082003><FONT =
size=3D2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=3D656514501-05082003><FONT =
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D656514501-05082003><FONT size=3D2>Michael=20
Mandelberg</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C35AF4.128F3100--

Delivery-date: Mon, 04 Aug 2003 08:27:29 +0000
content-class: urn:content-classes:message
Subject: RE: Support of Graceful Restart for RSVP-TE
Date: Mon, 4 Aug 2003 10:23:50 +0200
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
To: "Nurit Sprecher" <[email-masked]>, <[email-masked]>, "[email-masked]" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C35A61.BBCC8BD6
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

See RFC 3473 section 9
=20
JL
-----Message d'origine-----
De : Nurit Sprecher [mailto:[email-masked]]
Envoy? : dimanche 3 ao?t 2003 13:10
? : [email-masked]'; [email-masked]'
Cc : Nurit Sprecher
Objet : Support of Graceful Restart for RSVP-TE

Hi all,=20
Is there any standard/draft describing the procedure to graceful restart =
of RSVP-TE in order to minimize the negative effects on MPLS traffic =
caused by LSR's control plane restart?=20
I can see that there was such a draft written by Pan. What is the status =
of the draft? Expired? Any progression with it?=20
Thanks in advance, Nurit.

------_=_NextPart_001_01C35A61.BBCC8BD6
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">

<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<META content=3D"Microsoft Word 9" name=3DOriginator><LINK=20
href=3D"cid:[email-masked]" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt =
72.0pt 90.0pt; mso-header-margin: 35.4pt; mso-footer-margin: 35.4pt; =
mso-paper-source: 0; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
P.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
LI.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
DIV.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Courier New"
}
SPAN.EmailStyle15 {
	COLOR: black; mso-style-type: personal-compose; mso-ansi-font-size: =
10.0pt; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; =
mso-bidi-font-family: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: 36.0pt">
<DIV><SPAN class=3D492352108-04082003><FONT color=3D#0000ff size=3D2>See =
RFC 3473=20
section 9</FONT></SPAN></DIV>
<DIV><SPAN class=3D492352108-04082003><FONT color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D492352108-04082003><FONT color=3D#0000ff=20
size=3D2>JL</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Message d'origine-----<BR><B>De&nbsp;:</B> Nurit =
Sprecher=20
  =
[mailto:[email-masked]]<BR><B>Envoy&eacute;&nbsp;:<=
/B> dimanche=20
  3 ao&ucirc;t 2003 13:10<BR><B>&Agrave;&nbsp;:</B> =
[email-masked]';=20
  [email-masked]'<BR><B>Cc&nbsp;:</B> Nurit =
Sprecher<BR><B>Objet&nbsp;:</B>=20
  Support of Graceful Restart for RSVP-TE<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle15><FONT face=3DArial =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt">Hi=20
  all, <o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle15><FONT face=3DArial =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt">Is=20
  there any standard/draft describing the procedure to graceful restart =
of=20
  RSVP-TE in order to </SPAN></FONT></SPAN><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black">minimize the negative effects on MPLS traffic =
caused by=20
  LSR's control plane restart? </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: black">I can see that there was such =
a draft=20
  written by Pan. What is the status of the draft? Expired? Any =
progression with=20
  it? </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: black">Thanks in advance,=20
  Nurit.</SPAN></FONT><SPAN class=3DEmailStyle15><FONT face=3DArial =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></SPAN></P></DIV></BLOCKQUOTE></BODY></H=
TML>

------_=_NextPart_001_01C35A61.BBCC8BD6--