Subject: disman MIB Followup on gmpls-alarm-spec-

From: Lou Berger <[email-masked]>
Date: Fri, 30 Jan 2004 10:01:14 -0500

Tom, (Randy)

         Thank you for providing this input.  What we're looking for is a 
reference that provides enumerated values for alarms.  The ITU specs that 
we found all provide text strings, which is what we're trying to avoid.  It 
seems that the disman MIB provides exactly what we're looking for.

Please let us know if our intended use of the values defined in the MIB 
makes sense from your (disman WG's) perspective, or if you recommend an 
alternate approach.

Thank you,
Lou

PS The text in the new rev (submitted today) of the draft reads:
[from: http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt]
3.1.3. Error Codes and Values

    The Error Codes and Values used in ALARM_SPEC objects are the same as
    those used in ERROR_SPEC objects.  New Error Code values for use with
    both ERROR_SPEC and ALARM_SPEC objects may be assigned to support
    alarm types defined by other standards.

    In this document we define one new Error Code.  The Error Code uses
    the value TBA (by IANA) and is referred to as "Alarms".  The values
    used in the Error Values field are the same as the values used for
    IANAItuProbableCause in the Alarm MIB [ALARM-MIB].

The error values field is carried in an object with the format:
[from: rfc3473]
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Length             | Class-Num (6) | C-Type (3)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     IPv4 Error Node Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flags     |   Error Code  |          Error Value          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                              TLVs                             ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

At 10:20 AM 11/19/2003, Tom Petch wrote:
>FYI
>
>
>As a member of the disman WG, I have followed the development of the alarm 
>mib,
>currently draft-ietf-disman-alarm-mib-15.txt, over some years and this has
>included formal liaison with SG4 and some contact with SG15 over such 
>issues as
>who owns the code points and who can define them.  SG4 have expressed
>satisfaction with the way in which the liaison with disman WG has worked 
>(as on
>the IETF web site).
>
>But
>
>1) not knowing the working procedures of the ITU, I don't know if the 
>agreement
>with disman extends to other IETF WG - the wording suggests not to me.
>
>2) the alarm mib is currently under debate between authors and WG chair with a
>list of some 80 issues being resolved; the most difficult to resolve 
>appear IMO
>to be the ones relating to the existence of the ITU alarm table as an
>augmentation of the basic disman alarm table (and perhaps IMHO the lack of
>suitable features in SMIv2).  The alarm mib is complex, not one I would expect
>people to be able to dip into and readily extract a part thereof.
>
>3) I have lost track of the start of this thread and just what it was that 
>this,
>ccamp, WG
>wanted to include in what (and my Acrobat viewer renders the text of the 
>bullet
>points in AlarmSpec as black blobs of varying size:-(!  But whatever it is, I
>suggest you contact the
>disman chair, randy presuhn, to clarify the niceties of any interaction 
>with the
>output of disman, whatever form that finally takes.  It may be that M.3100
>related material should be in a common MIB module and not included in the 
>alarm
>mib because of issues of future updates and cross references from multiple 
>WGs..
>
>I think this is known as cross-functional review:-)
>
>Tom Petch
>
>
>-----Original Message-----
>From: Wijnen, Bert (Bert) <[email-masked]>
>To: Brungard, Deborah A, ALABS <[email-masked]>; Wijnen, Bert (Bert)
><[email-masked]>; Adrian Farrel <[email-masked]>; Lou Berger
><[email-masked]>
>Cc: [email-masked] <[email-masked]>
>Date: 18 November 2003 23:10
>Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>
>
> >the disman mib has enumerations I believe!
> >
> >Thanks,
> >Bert
> >
> >> -----Original Message-----
> >> From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
> >> Sent: dinsdag 18 november 2003 23:06
> >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger
> >> Cc: [email-masked]
> >> Subject: RE: Taking to the
> >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> >>
> >>
> >> Thanks Bert.
> >>
> >> M.3100 provides the generic information model, X.733 and
> >> X.736 define OSI generics pointing to X.721, and X.721
> >> provides abstract syntax. We were looking for an enumeration
> >> to use vs. needing to support abstract syntax strings in
> >> signaling. Any suggestions are welcome.
> >> Deborah
> >>
> >> -----Original Message-----
> >> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> >> Sent: Tuesday, November 11, 2003 11:46 AM
> >> To: Adrian Farrel; Lou Berger
> >> Cc: [email-masked]
> >> Subject: RE: Taking to the
> >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> >>
> >>
> >> Things to potentially look at:
> >>
> >>   draft-ietf-disman-alarm-mib-15.txt
> >>
> >>   [M.3100]    ITU Recommendation M.3100, "Generic Network Information
> >>               Model", 1995
> >>
> >>   [X.733]     ITU Recommendation X.733, "Information Technology - Open
> >>               Systems Interconnection - System Management: Alarm
> >>               Reporting Function", 1992
> >>
> >>   [X.736]     ITU Recommendation X.736, "Information Technology - Open
> >>               Systems Interconnection - System Management: Security
> >>               Alarm Reporting Function", 1992
> >>
> >> Thanks,
> >> Bert
> >>
> >> > -----Original Message-----
> >> > From: Adrian Farrel [mailto:[email-masked]]
> >> > Sent: dinsdag 11 november 2003 17:28
> >> > To: Lou Berger
> >> > Cc: [email-masked]
> >> > Subject: Re: Taking to the
> >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> >> >
> >> >
> >> > Lou,
> >> >
> >> > I believe the alarm reference was M.3100.
> >> >
> >> > Can someone confirm?
> >> >
> >> > Adrian
> >> >
> >> >
> >> > > In the morning's meeting the AD's asked to bring the
> >> proposed Alarm
> >> > > communication extension to "the list".  For today's
> >> > presentation see:
> >> > > http://www.labn.net/docs/AlarmSpec00.pdf
> >> > >
> >> > > I believe the issues to be discussed are:
> >> > > 1) Is there general interest in this work?
> >> > > 2) Should the usage of new TLVs in Error_Spec be permitted?
> >> > >          (We think there's some value, particularly with string
> >> > >           and timestamp)
> >> > > 3) Are there good references for alarm code points?
> >> > >
> >> > > Thank,
> >> > > Lou (and co-authors)
> >> >
> >> >
> >>
> >

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 31 Jan 2004 01:11:38 +0100

TO me this looks fine

Thanks,
Bert 

> From: Lou Berger [mailto:[email-masked]]
> Sent: vrijdag 30 januari 2004 16:01
> To: Tom Petch; Randy Presuhn
> Cc: Wijnen, Bert (Bert); [email-masked]
> Subject: disman MIB Followup on gmpls-alarm-spec-
> 
> 
> Tom, (Randy)
> 
> [from: 
> http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt]

Delivery-date: Sat, 31 Jan 2004 00:13:57 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "'Lou Berger'" <[email-masked]>, Tom Petch <[email-masked]>, Randy Presuhn <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Subject: RE: disman MIB Followup on gmpls-alarm-spec-
Date: Sat, 31 Jan 2004 01:11:38 +0100

TO me this looks fine

Thanks,
Bert 

> From: Lou Berger [mailto:[email-masked]]
> Sent: vrijdag 30 januari 2004 16:01
> To: Tom Petch; Randy Presuhn
> Cc: Wijnen, Bert (Bert); [email-masked]
> Subject: disman MIB Followup on gmpls-alarm-spec-
> 
> 
> Tom, (Randy)
> 
> [from: 
> http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt]

Delivery-date: Fri, 30 Jan 2004 15:04:20 +0000
Date: Fri, 30 Jan 2004 10:01:14 -0500
To: "Tom Petch" <[email-masked]>, "Randy Presuhn" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: disman MIB Followup on gmpls-alarm-spec-
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, <[email-masked]>

Tom, (Randy)

Thank you,
Lou

> >> > > 3) Are there good references for alarm code points?

Delivery-date: Thu, 29 Jan 2004 18:54:51 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt
Date: Wed, 28 Jan 2004 11:05:56 -0500

--NextPart

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

	Title		: Generalized MPLS (GMPLS) RSVP-TE Signalling in support
			  of Automatically Switched Optical Network (ASON)
	Author(s)	: J. Drake
	Filename	: draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt
	Pages		: 41
	Date		: 2004-1-27
	
This document specifies how Generalized MPLS (GMPLS) RSVP-TE
signaling may be used and extended to satisfy the requirements of
the Automatically Switched Optical Network (ASON) architecture
specified by the ITU-T. The requirements are in a companion document
'Requirements for Generalized MPLS (GMPLS) Usage and Extensions for
Automatically Switched Optical Network (ASON).'

In particular, this document details the mechanisms for setting up
Soft Permanent Connections (SPC), the necessary extensions in
delivering full and logical call/connection separation support, the
extended restart capabilities during control plane failures,
extended label usage and crankback signalling capability.

The mechanisms proposed in the present document are applicable to
any environment (including multi-area) and for any type of
interface: packet, layer-2, time-division multiplexed, lambda or
fiber switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-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-rsvp-te-ason-01.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-rsvp-te-ason-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, 29 Jan 2004 16:07:52 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
Date: Wed, 28 Jan 2004 11:06:01 -0500

--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		: Recovery (Protection and Restoration) Terminology for GMPLS
	Author(s)	: E. Mannie, D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
	Pages		: 20
	Date		: 2004-1-27
	
This document defines a common terminology for Generalized Multi-
Protocol Label Switching (GMPLS) based recovery mechanisms (i.e.
protection and restoration) that are under consideration by the
CCAMP Working Group. The proposed terminology is intended to be
independent of the underlying transport technologies covered by
GMPLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.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-recovery-terminology-03.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-recovery-terminology-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 29 Jan 2004 00:09:07 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Requests for agenda slots
Date: Thu, 29 Jan 2004 00:03:41 -0000

OK folks,
Time to start requesting agenda slots.

Please mail to me and Kireeti. Make the Subject line start with AGENDA:

Please state the name and version number of the draft.
Please suggest how long you need to describe progress and plans, and hear questions.

Recall - you are not presenting your drafts!

Authors of new drafts would be well advised to ensure that their draft clearly falls
within the charter. The best way to do this is to write a summary section that highlights
the line items in the charter that your draft addresses.. Have a look at
draft-ietf-ccamp-crankback-00.txt if you need a model.

Authors/editors of working group drafts can expect to be prodded by me for contributions.

Thanks,
Adrian

Delivery-date: Wed, 28 Jan 2004 16:09:19 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
Date: Wed, 28 Jan 2004 11:06:01 -0500

--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		: Recovery (Protection and Restoration) Terminology for GMPLS
	Author(s)	: E. Mannie, D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
	Pages		: 20
	Date		: 2004-1-27
	
This document defines a common terminology for Generalized Multi-
Protocol Label Switching (GMPLS) based recovery mechanisms (i.e.
protection and restoration) that are under consideration by the
CCAMP Working Group. The proposed terminology is intended to be
independent of the underlying transport technologies covered by
GMPLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.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-recovery-terminology-03.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-recovery-terminology-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 28 Jan 2004 16:09:03 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt
Date: Wed, 28 Jan 2004 11:05:56 -0500

--NextPart

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

	Title		: Generalized MPLS (GMPLS) RSVP-TE Signalling in support
			  of Automatically Switched Optical Network (ASON)
	Author(s)	: J. Drake
	Filename	: draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt
	Pages		: 41
	Date		: 2004-1-27
	
This document specifies how Generalized MPLS (GMPLS) RSVP-TE
signaling may be used and extended to satisfy the requirements of
the Automatically Switched Optical Network (ASON) architecture
specified by the ITU-T. The requirements are in a companion document
'Requirements for Generalized MPLS (GMPLS) Usage and Extensions for
Automatically Switched Optical Network (ASON).'

In particular, this document details the mechanisms for setting up
Soft Permanent Connections (SPC), the necessary extensions in
delivering full and logical call/connection separation support, the
extended restart capabilities during control plane failures,
extended label usage and crankback signalling capability.

The mechanisms proposed in the present document are applicable to
any environment (including multi-area) and for any type of
interface: packet, layer-2, time-division multiplexed, lambda or
fiber switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-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-rsvp-te-ason-01.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 27 Jan 2004 23:15:08 +0000
Date: Tue, 27 Jan 2004 18:13:48 -0500 (EST)
From: IESG Secretary <[email-masked]>
To: [email-masked]
cc: [email-masked], <[email-masked]>, <[email-masked]>
Subject: IESG on IANA allocations for ietf-ccamp-gmpls-sonet-sdh

The IESG has reviewed the situation with RSVP C-Type allocations
performed for ietf-ccamp-gmpls-sonet-sdh by IANA (see [1] for more
information). The IESG recommends that IANA allocates C-Type value 4
in the FLOWSPEC and SENDER_TSPEC ranges for this document, and marks
value 3 in these ranges as "deprecated".

Note well: this does not set a precedent for IESG support of changing
IANA allocations based on implementation circumstances.

The IESG also requests that CCAMP WG takes on the effort of reviewing
the situation and takes measures to prevent similar problems from
happening in the future.

[1] IESG, "Short Last Call: IANA allocations for
        ietf-ccamp-gmpls-sonet-sdh", 19 Jan 2004, e-mail message,

http://www1.ietf.org/mail-archive/ietf-announce/Current/msg28014.html

Delivery-date: Tue, 27 Jan 2004 20:42:23 +0000
Date: Tue, 27 Jan 2004 12:40:39 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Ben Mack-Crane <[email-masked]>
CC: [email-masked]
Subject: Re: Regarding IANA allocations for ietf-ccamp-gmpls-sonet-sdh

Ben,

  [cc'ing the ccamp list]

  Yup. I checked the TSPEC right after I hit the send button.
  I'm following up with IANA already.

-- 
Alex

Tuesday, January 27, 2004, 12:35:03 PM, Ben Mack-Crane wrote:
> Alex,

> I just checked the IANA website and found the following:

>       9  FLOWSPEC                             [RFC2205]

>          Class Types or C-Types:

>            1   Reserved                       [RFC2205]
>            2   Int-serv Flowspec              [RFC2210]
>            3   Deprecated                     [IESG]
>            4   SONET/SDH FLOWSPEC             [RFC-ietf-ccamp-gmpls-sonet-sdh-08.txt]

> ...

>     12  SENDER_TSPEC                          [RFC2205]

>         Class Types or C-Types:

>           2   Int-serv                        [RFC2210]
>           3   SONET/SDH SENDER_TSPEC          [RFC-ietf-ccamp-gmpls-sonet-sdh-08.txt]

> It looks like the FLOWSPEC is changed but the TSPEC is not.  So there 
> may be a bit of fixing yet to do.

> Regards,
> Ben

> Alex Zinin wrote:

>>Folks-
>>
>> I haven't been successful in getting the secretariat to send the IESG
>> message on the subj to the right recipients, so I am forwarding the
>> original of the IESG statement that we agreed on Thursday last week.
>> I believe IANA guys already made necessary corrections in the
>> registry.
>>
>> On a related topic, we're working with the WG chairs on the long-term
>> solutions to the problem. Ideas should be documented in an I-D soon.
>>
>> Cheers.

Delivery-date: Tue, 27 Jan 2004 20:17:15 +0000
Date: Tue, 27 Jan 2004 12:13:58 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: Regarding IANA allocations for ietf-ccamp-gmpls-sonet-sdh

Folks-

 I haven't been successful in getting the secretariat to send the IESG
 message on the subj to the right recipients, so I am forwarding the
 original of the IESG statement that we agreed on Thursday last week.
 I believe IANA guys already made necessary corrections in the
 registry.

 On a related topic, we're working with the WG chairs on the long-term
 solutions to the problem. Ideas should be documented in an I-D soon.

 Cheers.
 
-- 
Alex Zinin

> From: [email-masked]
> To: [email-masked]
> Cc: [email-masked]
> Subject: IESG on IANA allocations for ietf-ccamp-gmpls-sonet-sdh
> 
> The IESG has reviewed the situation with RSVP C-Type allocations
> performed for ietf-ccamp-gmpls-sonet-sdh by IANA (see [1] for more
> information). The IESG recommends that IANA allocates C-Type value 4
> in the FLOWSPEC and SENDER_TSPEC ranges for this document, and marks
> value 3 in these ranges as "deprecated".
> 
> Note well: this does not set a precedent for IESG support of changing
> IANA allocations based on implementation circumstances.
> 
> The IESG also requests that CCAMP WG takes on the effort of reviewing
> the situation and takes measures to prevent similar problems from
> happening in the future.
> 
> [1] IESG, "Short Last Call: IANA allocations for
>     ietf-ccamp-gmpls-sonet-sdh", 19 Jan 2004, e-mail message,
>     http://www1.ietf.org/mail-archive/ietf-announce/Current/msg28014.html

Delivery-date: Sat, 24 Jan 2004 15:23:56 +0000
Date: Sat, 24 Jan 2004 10:21:28 -0500
To: "Adrian Farrel" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Fw: I-D ACTION:draft-berger-gmpls-egress-control-01.txt
Cc: <[email-masked]>

Adrian,

oh well, I asked for notification to be sent to the list.

I was thinking of this as an individual draft, but you are probably right 
that it should go through WG review as it clarifies a protocol produced by 
the group.  Moving it forward as a BCP probably is the right call...

Thanks for forwarding the announcement.

Lou

At 05:43 PM 1/23/2004, Adrian Farrel wrote:

>All,
>
>I didn't see notification of this to the list, but it sure is relevant.
>
>Would appreciate review input from everyone, but especially those who were 
>not clear about
>how/whether GMPLS supported egress port/label control.
>
>Also, can you think about whether this draft should be run through the WG.
>
>Thanks,
>Adrian
>
>----- Original Message -----
>From: <[email-masked]>
>To: <IETF-Announce:>
>Sent: Friday, January 23, 2004 8:59 PM
>Subject: I-D ACTION:draft-berger-gmpls-egress-control-01.txt
>
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> >
> >
> > Title : GMPLS Signaling Procedure For Egress Control
> > Author(s) : L. Berger
> > Filename : draft-berger-gmpls-egress-control-01.txt
> > Pages : 5
> > Date : 2004-1-23
> >
> > This note clarifies the procedures for the control of a label used on
> > an egress output/downstream interface.  Such control is also know and
> > 'Egress Control'.  Support for Egress Control is implicit in
> > Generalized Multi-Protocol Label Switching (GMPLS) Signaling
> > [RFC3471] and [RFC3473].  This note does not modify GMPLS signaling
> > mechanisms and procedures and should be viewed as an informative
> > clarification of [RFC3473].
> >
> > A URL for this Internet-Draft is:
> > 
> <http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt>http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-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-berger-gmpls-egress-control-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
> > or 
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>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-berger-gmpls-egress-control-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.
> >
>

Delivery-date: Fri, 23 Jan 2004 22:47:17 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: I-D ACTION:draft-berger-gmpls-egress-control-01.txt
Date: Fri, 23 Jan 2004 22:43:32 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0F66_01C3E202.54330E70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

I didn't see notification of this to the list, but it sure is relevant.

Would appreciate review input from everyone, but especially those who were not clear about
how/whether GMPLS supported egress port/label control.

Also, can you think about whether this draft should be run through the WG.

Thanks,
Adrian

----- Original Message ----- 
From: <[email-masked]>
To: <IETF-Announce:>
Sent: Friday, January 23, 2004 8:59 PM
Subject: I-D ACTION:draft-berger-gmpls-egress-control-01.txt

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> Title : GMPLS Signaling Procedure For Egress Control
> Author(s) : L. Berger
> Filename : draft-berger-gmpls-egress-control-01.txt
> Pages : 5
> Date : 2004-1-23
>
> This note clarifies the procedures for the control of a label used on
> an egress output/downstream interface.  Such control is also know and
> 'Egress Control'.  Support for Egress Control is implicit in
> Generalized Multi-Protocol Label Switching (GMPLS) Signaling
> [RFC3471] and [RFC3473].  This note does not modify GMPLS signaling
> mechanisms and procedures and should be viewed as an informative
> clarification of [RFC3473].
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-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-berger-gmpls-egress-control-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-berger-gmpls-egress-control-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_000_0F66_01C3E202.54330E70
Content-Type: application/octet-stream;
	name="ATT03937.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT03937.dat"

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

ENCODING mime
FILE /internet-drafts/draft-berger-gmpls-egress-control-01.txt

------=_NextPart_000_0F66_01C3E202.54330E70
Content-Type: text/plain;
	name="draft-berger-gmpls-egress-control-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-berger-gmpls-egress-control-01.txt"

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

------=_NextPart_000_0F66_01C3E202.54330E70--

Delivery-date: Thu, 22 Jan 2004 12:30:10 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ronald Bonica" <[email-masked]>
Subject: Re: GTTP Draft
Date: Thu, 22 Jan 2004 12:26:17 -0000

All,

Recall that a tunnel trace protocol is now in our charter.
If the WG considers that GTTP is suitable, we should adopt it and drive it to conclusion.
If the WG thinks that GTTP is not suitable (or that there is no need for a tunnel trace
protocol) voices should be raised.

Cheers,
Adrian
----- Original Message ----- 
From: "Ronald Bonica" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 22, 2004 3:04 AM
Subject: GTTP Draft

> Folks,
>
> I have updated the generic tunnel tracing draft. It is available at
> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt. Please
> review and comment.
>
>                                                Ron
>
> Abstract
> This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP
> supports enhanced route-tracing applications. Network operators use enhanced
> route-tracing applications to trace the path between any two points in an IP
> network. Enhanced route-tracing applications can trace through a network's
> forwarding plane, its control plane or both. Furthermore, enhanced
> route-tracing applications can reveal details concerning tunnels that
> support the traced path. Tunnel details can be revealed regardless of
> tunneling technology. For example, enhanced route-tracing applications can
> trace through an MPLS LSP as well as they can trace through an IP-in-IP
> tunnel.
>
> ===========================================
> Ronald P. Bonica       Ph: 703 886 1681
> vBNS Engineering       page: 1 888 268 8021
> Ashburn, Va.
> ===========================================
> "There is more to life than simply
>                   increasing its speed."
>                       -- Mahatma Gandhi
>
>
>
>

Delivery-date: Thu, 22 Jan 2004 03:12:56 +0000
Date: Wed, 21 Jan 2004 22:04:03 -0500
From: Ronald Bonica <[email-masked]>
Subject: GTTP Draft
To: [email-masked]

Folks,

I have updated the generic tunnel tracing draft. It is available at
http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt. Please
review and comment.

                                               Ron

Abstract
This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP
supports enhanced route-tracing applications. Network operators use enhanced
route-tracing applications to trace the path between any two points in an IP
network. Enhanced route-tracing applications can trace through a network's
forwarding plane, its control plane or both. Furthermore, enhanced
route-tracing applications can reveal details concerning tunnels that
support the traced path. Tunnel details can be revealed regardless of
tunneling technology. For example, enhanced route-tracing applications can
trace through an MPLS LSP as well as they can trace through an IP-in-IP
tunnel.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"There is more to life than simply
                  increasing its speed."
                      -- Mahatma Gandhi

Delivery-date: Wed, 21 Jan 2004 13:47:25 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Submission deadlines for Seoul
Date: Wed, 21 Jan 2004 13:45:32 -0000

All,

Please be aware of the following deadlines.

February 9, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00
ET
February 16, Monday - Pre-Registration and Pre-payment cut-off at 12:00 noon ET

Also, be warned!
We plan to require submission of slides in advance of the meeting so that the attendees
can follow along at their own speed.
There will be something like a 24 hour deadline on this so you won't have to write slides
until you know you are on the agenda.

Cheers,
Adrian

Delivery-date: Tue, 20 Jan 2004 19:35:16 +0000
Date: Tue, 20 Jan 2004 11:32:26 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Liaison response posted

Hi,

The Liaison response that the CCAMP WG sent to the ITU-T re G.7713.2
has been posted to the IETF "Liaison Statements" page at
http://ietf.org/IESG/liaison.html .

Kireeti.
-------

Envelope-to: [email-masked]
Delivery-date: Tue, 20 Jan 2004 18:01:46 +0000
Message-Id: <[email-masked]>
From: The IESG <[email-masked]>
cc: [email-masked]
Subject: Short Last Call: IANA allocations for ietf-ccamp-gmpls-sonet-sdh
Date: Mon, 19 Jan 2004 18:37:35 -0500

The IESG is considering the situation with IANA allocation of the RSVP
FLOWSPEC and SENDER_TSPEC C-Types for ietf-ccamp-gmpls-sonet-sdh that
has been recently approved by the IESG for publication as an RFC.

While the long-term measures to prevent similar situations in future
are being discussed, the issue at hand needs to be quickly resolved.
The proposed solution is to change the assignment of the above C-Types
from value 3 (currently assigned by IANA) to 4, and mark value 3 as
"reserved".

The IESG would like to solicit comments on the proposed solution from
the community. More details are given below. Please send your comments
by January 22nd, 2004.

Description of the situation with IANA assignments for
ietf-ccamp-gmpls-sonet-sdh:

1. After the approval of the document by the IESG, an IANA action has
   been performed for the document, in which IANA correctly picked the
   next available C-Type value (3) in the FLOWSPEC and SENDER_TSPEC
   ranges and assigned it to the document.

2. However, the CCAMP WG has been informed that value 3 is being used
   by implementations of an another (expired) Internet draft that
   also picked next available value in the same ranges. Because the
   draft never progressed, these values have never been formally
   allocated by IANA within the RSVP registry.

3. Because implementations of the expired Internet draft have been
   deployed, assigning value 3 to ietf-ccamp-gmpls-sonet-sdh would
   create interoperability problems.

4. An implementation survey performed in the CCAMP WG showed that
   most early implementations of ietf-ccamp-gmpls-sonet-sdh use
   value 4, and those few that use the IANA-assigned value 3 would
   be willing to change it to 4 to avoid interoperability problems.

Delivery-date: Tue, 20 Jan 2004 12:43:46 +0000
From: "alessio d'achille" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: revised version of the draft
Date: Tue, 20 Jan 2004 13:43:25 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_00D8_01C3DF5B.611526E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi folks,=20

Wer have just submitted a revised version of our draft: =
<draft-dachille-inter-area-path-protection-01.txt>, since the previous =
version included few errors; you will find the new version soon, and we =
ask you to send your feedback to us about this new version and not about =
the previous one.

As Vishal said in a previous e-mail, we would be particularly interested =
in feedback from some of the principal WG members who are involved in =
the inter-AS/inter-area activity.

Best regards,=20

Alessio D'Achille=20

on behalf of Vishal Sharma, Marco Listanti, Fabio Ricciato, and Ugo =
monaco

------=_NextPart_000_00D8_01C3DF5B.611526E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi folks, </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Wer have just submitted a revised =
version of our=20
draft: &lt;draft-dachille-inter-area-path-protection-01.txt&gt;, since =
the=20
previous version included few errors; you will find the new version =
soon, and we=20
ask you to send your feedback to us about this new version and not about =
the=20
previous one.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>As Vishal said in a previous e-mail, =
we&nbsp;would=20
be particularly interested in feedback from some of the <FONT =
color=3D#0000ff=20
face=3DArial size=3D2><SPAN class=3D798550518-19012004><FONT =
color=3D#000000>principal=20
WG members who are involved in the inter-AS/inter-area=20
activity</FONT>.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Best regards, </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Alessio D'Achille </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>on behalf of Vishal Sharma, Marco =
Listanti, Fabio=20
Ricciato, and Ugo monaco</FONT></DIV></BODY></HTML>

------=_NextPart_000_00D8_01C3DF5B.611526E0--

Envelope-to: [email-masked]
Delivery-date: Tue, 20 Jan 2004 00:11:09 +0000
Date: Mon, 19 Jan 2004 23:37:52 +0000
From: [email-masked]
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from [The IESG <[email-masked]>]
Message-Id: <[email-masked]>

>From [email-masked] Mon Jan 19 23:37:40 2004
To: IETF-Announce: ;
From: The IESG <[email-masked]>
cc: [email-masked]
Subject: Short Last Call: IANA allocations for
         ietf-ccamp-gmpls-sonet-sdh
Date: Mon, 19 Jan 2004 18:37:35 -0500
Sender: [email-masked]

The IESG is considering the situation with IANA allocation of the RSVP
FLOWSPEC and SENDER_TSPEC C-Types for ietf-ccamp-gmpls-sonet-sdh that
has been recently approved by the IESG for publication as an RFC.

While the long-term measures to prevent similar situations in future
are being discussed, the issue at hand needs to be quickly resolved.
The proposed solution is to change the assignment of the above C-Types
from value 3 (currently assigned by IANA) to 4, and mark value 3 as
"reserved".

The IESG would like to solicit comments on the proposed solution from
the community. More details are given below. Please send your comments
by January 22nd, 2004.

Description of the situation with IANA assignments for
ietf-ccamp-gmpls-sonet-sdh:

1. After the approval of the document by the IESG, an IANA action has
   been performed for the document, in which IANA correctly picked the
   next available C-Type value (3) in the FLOWSPEC and SENDER_TSPEC
   ranges and assigned it to the document.

2. However, the CCAMP WG has been informed that value 3 is being used
   by implementations of an another (expired) Internet draft that
   also picked next available value in the same ranges. Because the
   draft never progressed, these values have never been formally
   allocated by IANA within the RSVP registry.

3. Because implementations of the expired Internet draft have been
   deployed, assigning value 3 to ietf-ccamp-gmpls-sonet-sdh would
   create interoperability problems.

4. An implementation survey performed in the CCAMP WG showed that
   most early implementations of ietf-ccamp-gmpls-sonet-sdh use
   value 4, and those few that use the IANA-assigned value 3 would
   be willing to change it to 4 to avoid interoperability problems.

Delivery-date: Mon, 19 Jan 2004 18:32:29 +0000
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>, "TE" <[email-masked]>
Cc: "alessio d'achille" <[email-masked]>
Subject: Inter-region TE
Date: Mon, 19 Jan 2004 10:29:58 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_002C_01C3DE77.2FD8D5C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Folks,

I just wanted to add that this work ties in to the recent
inter-AS/inter-area TE
work that has been a focus of the TE and CCAMP WGs.

As Alessio mentioned, this work takes a unified view of areas and AS's, and
is applicable to both inter-AS and inter-area scenarios.

Therefore, we would be particularly interested in feedback from some of the
principal WG members who are involved in the inter-AS/inter-area activity.

Regards,
-Vishal
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf
Of alessio d'achille
  Sent: Monday, January 19, 2004 7:19 AM
  To: [email-masked]
  Cc: [email-masked]
  Subject: A new draft is available

  Hi all,

  we have just submitted to the IETF a new draft about inter-area path
protection; in this document we addressed the problem of establishing two
disjoint LSPs between two nodes which belongs to different areas (with the
term "areas" we refer to an
  - OSPF area or
  - Autonomous System or
  - Optical island      )

  The draft is now available in the IETF draft directory and its name is :

  <draft-dachille-inter-area-path-protection-00.txt>

  A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protectio
n-00.txt

  Best regards to all,

  Alessio D'Achille (one of the authors of this draft),
  on behalf of

  Vishal Sharma (co-author), Fabio Ricciato (author), Marco Listanti
(Author) and Ugo Monaco (Author).

  P.S. We have noticed that there is an error in the authors' referencs in
the very first page in the version of the draft in the IETF draft directory
(in fact, in the very first page, "Ed." figures next to Vishal Sharma, but
he is a co-author, and "Ed." should be next to Alessio D'Achille, Fabio
Ricciato, Marco Listanti and Ugo Monaco)

------=_NextPart_000_002C_01C3DE77.2FD8D5C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>Folks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D798550518-19012004>I just=20
wanted to add that this work ties in&nbsp;to the recent =
inter-AS/inter-area=20
TE</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>work&nbsp;that has been&nbsp;a&nbsp;focus =
of&nbsp;the=20
TE and CCAMP WGs.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D798550518-19012004>As=20
Alessio mentioned, this work takes a unified view of areas and AS's,=20
and</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D798550518-19012004>is=20
applicable to both inter-AS and inter-area =
scenarios.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>Therefore, we would be particularly =
interested in=20
feedback from some of the</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>principal WG members who are involved in the=20
inter-AS/inter-area activity.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>-Vishal</SPAN></FONT></DIV></DIV></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of </B>alessio=20
  d'achille<BR><B>Sent:</B> Monday, January 19, 2004 7:19 =
AM<BR><B>To:</B>=20
  [email-masked]<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> =
A new=20
  draft is available<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Hi all, </FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>we have =
just submitted to=20
  the IETF a new draft about inter-area path protection; in this =
document we=20
  addressed the problem of establishing two disjoint LSPs between two =
nodes=20
  which belongs to different areas (with the term "areas" we refer to=20
  an</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- OSPF =
area=20
  or</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- =
Autonomous System=20
  or</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- Optical =

  island&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; )</FONT></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>The draft is now available in the =
IETF draft=20
  directory and its name is :</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>&lt;draft-dachille-inter-area-path-protection-00.txt&gt;</FONT><=
/DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>A URL for this Internet-Draft is: =
</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff><FONT face=3DArial size=3D2><FONT =
face=3DArial size=3D2><U><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-dachille-inter-area-pat=
h-protection-00.txt">http://www.ietf.org/internet-drafts/draft-dachille-i=
nter-area-path-protection-00.txt</A></U></FONT></FONT></FONT></DIV>
  <DIV><FONT color=3D#0000ff><FONT face=3DArial size=3D2><FONT =
face=3DArial=20
  size=3D2></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Best =
regards to=20
  all,</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Alessio =
D'Achille (one of=20
  the authors of this draft), </FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>on behalf of</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Vishal Sharma (co-author), Fabio =
Ricciato=20
  (author), Marco Listanti (Author) and Ugo Monaco =
(Author).</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>P.S. We have noticed that there is an =
error in=20
  the authors' referencs in the very first page in the version of the =
draft in=20
  the IETF draft directory (in fact, in the very first page, "Ed." =
figures next=20
  to Vishal Sharma, but he is a co-author, and "Ed." should be next to =
Alessio=20
  D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-inter-area"></A></FONT>=
</FONT>&nbsp;</DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_002C_01C3DE77.2FD8D5C0--

Delivery-date: Mon, 19 Jan 2004 18:15:44 +0000
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "alessio d'achille" <[email-masked]>
Subject: RE: Inter-region TE
Date: Mon, 19 Jan 2004 10:12:31 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01C3DE74.C0106B60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Folks,

I just wanted to add that this work ties in to the recent
inter-AS/inter-area TE
work that has been a focus of the TE and CCAMP WGs.

As Alessio mentioned, this work takes a unified view of areas and AS's, and
is applicable to both inter-AS and inter-area scenarios.

Therefore, we would be particularly interested in feedback from some of the
principal WG members who are involved in the inter-AS/inter-area activity.

Regards,
-Vishal
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf
Of alessio d'achille
  Sent: Monday, January 19, 2004 7:19 AM
  To: [email-masked]
  Cc: [email-masked]
  Subject: A new draft is available

  Hi all,

  we have just submitted to the IETF a new draft about inter-area path
protection; in this document we addressed the problem of establishing two
disjoint LSPs between two nodes which belongs to different areas (with the
term "areas" we refer to an
  - OSPF area or
  - Autonomous System or
  - Optical island      )

  The draft is now available in the IETF draft directory and its name is :

  <draft-dachille-inter-area-path-protection-00.txt>

  A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protectio
n-00.txt

  Best regards to all,

  Alessio D'Achille (one of the authors of this draft),
  on behalf of

  Vishal Sharma (co-author), Fabio Ricciato (author), Marco Listanti
(Author) and Ugo Monaco (Author).

  P.S. We have noticed that there is an error in the authors' referencs in
the very first page in the version of the draft in the IETF draft directory
(in fact, in the very first page, "Ed." figures next to Vishal Sharma, but
he is a co-author, and "Ed." should be next to Alessio D'Achille, Fabio
Ricciato, Marco Listanti and Ugo Monaco)

------=_NextPart_000_0023_01C3DE74.C0106B60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>Folks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D798550518-19012004>I just=20
wanted to add that this work ties in&nbsp;to the recent =
inter-AS/inter-area=20
TE</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>work&nbsp;that has been&nbsp;a&nbsp;focus =
of&nbsp;the=20
TE and CCAMP WGs.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D798550518-19012004>As=20
Alessio mentioned, this work takes a unified view of areas and AS's,=20
and</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D798550518-19012004>is=20
applicable to both inter-AS and inter-area =
scenarios.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>Therefore, we would be particularly =
interested in=20
feedback from some of the</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>principal WG members who are involved in the=20
inter-AS/inter-area activity.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>-Vishal</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of </B>alessio=20
  d'achille<BR><B>Sent:</B> Monday, January 19, 2004 7:19 =
AM<BR><B>To:</B>=20
  [email-masked]<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> =
A new=20
  draft is available<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Hi all, </FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>we have =
just submitted to=20
  the IETF a new draft about inter-area path protection; in this =
document we=20
  addressed the problem of establishing two disjoint LSPs between two =
nodes=20
  which belongs to different areas (with the term "areas" we refer to=20
  an</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- OSPF =
area=20
  or</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- =
Autonomous System=20
  or</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- Optical =

  island&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; )</FONT></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>The draft is now available in the =
IETF draft=20
  directory and its name is :</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>&lt;draft-dachille-inter-area-path-protection-00.txt&gt;</FONT><=
/DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>A URL for this Internet-Draft is: =
</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff><FONT face=3DArial size=3D2><FONT =
face=3DArial size=3D2><U><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-dachille-inter-area-pat=
h-protection-00.txt">http://www.ietf.org/internet-drafts/draft-dachille-i=
nter-area-path-protection-00.txt</A></U></FONT></FONT></FONT></DIV>
  <DIV><FONT color=3D#0000ff><FONT face=3DArial size=3D2><FONT =
face=3DArial=20
  size=3D2></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Best =
regards to=20
  all,</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Alessio =
D'Achille (one of=20
  the authors of this draft), </FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>on behalf of</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Vishal Sharma (co-author), Fabio =
Ricciato=20
  (author), Marco Listanti (Author) and Ugo Monaco =
(Author).</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>P.S. We have noticed that there is an =
error in=20
  the authors' referencs in the very first page in the version of the =
draft in=20
  the IETF draft directory (in fact, in the very first page, "Ed." =
figures next=20
  to Vishal Sharma, but he is a co-author, and "Ed." should be next to =
Alessio=20
  D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-inter-area"></A></FONT>=
</FONT>&nbsp;</DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0023_01C3DE74.C0106B60--

Delivery-date: Mon, 19 Jan 2004 15:20:09 +0000
From: "alessio d'achille" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: A new draft is available
Date: Mon, 19 Jan 2004 16:18:37 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_00A7_01C3DEA7.E4A18080
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,=20

we have just submitted to the IETF a new draft about inter-area path =
protection; in this document we addressed the problem of establishing =
two disjoint LSPs between two nodes which belongs to different areas =
(with the term "areas" we refer to an
- OSPF area or
- Autonomous System or
- Optical island      )

The draft is now available in the IETF draft directory and its name is :

<draft-dachille-inter-area-path-protection-00.txt>

A URL for this Internet-Draft is:=20

http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protec=
tion-00.txt

Best regards to all,

Alessio D'Achille (one of the authors of this draft),=20
on behalf of

Vishal Sharma (co-author), Fabio Ricciato (author), Marco Listanti =
(Author) and Ugo Monaco (Author).

P.S. We have noticed that there is an error in the authors' referencs in =
the very first page in the version of the draft in the IETF draft =
directory (in fact, in the very first page, "Ed." figures next to Vishal =
Sharma, but he is a co-author, and "Ed." should be next to Alessio =
D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)

------=_NextPart_000_00A7_01C3DEA7.E4A18080
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi all, </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>we have =
just submitted to=20
the IETF a new draft about inter-area path protection; in this document =
we=20
addressed the problem of establishing two disjoint LSPs between two =
nodes which=20
belongs to different areas (with the term "areas" we refer to=20
an</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- OSPF area =

or</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- =
Autonomous System=20
or</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- Optical=20
island&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; )</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The draft is now available in the IETF =
draft=20
directory and its name is :</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&lt;draft-dachille-inter-area-path-protection-00.txt&gt;</FONT><=
/DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>A URL for this Internet-Draft is: =
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff><FONT face=3DArial size=3D2><FONT =
face=3DArial size=3D2><U><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-dachille-inter-area-pat=
h-protection-00.txt">http://www.ietf.org/internet-drafts/draft-dachille-i=
nter-area-path-protection-00.txt</A></U></FONT></FONT></FONT></DIV>
<DIV><FONT color=3D#0000ff><FONT face=3DArial size=3D2><FONT =
face=3DArial=20
size=3D2></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Best =
regards to=20
all,</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial =
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Alessio =
D'Achille (one of=20
the authors of this draft), </FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>on behalf of</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Vishal Sharma (co-author), Fabio =
Ricciato (author),=20
Marco Listanti (Author) and Ugo Monaco (Author).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>P.S. We have noticed that there is an =
error in the=20
authors' referencs in the very first page in the version of the draft in =
the=20
IETF draft directory (in fact, in the very first page, "Ed." figures =
next to=20
Vishal Sharma, but he is a co-author, and "Ed." should be next to =
Alessio=20
D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial =
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-inter-area"></A></FONT>=
</FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00A7_01C3DEA7.E4A18080--

Delivery-date: Fri, 16 Jan 2004 22:04:41 +0000
Date: Fri, 16 Jan 2004 14:02:47 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: Thomas Narten <[email-masked]>, [email-masked], [email-masked]
Subject: Re: IANA assignments

Kireeti,

>> It might be possible to change this assignment if people can make a
>> clear case that:
>>
>>  - leaving the assignment of 3 is clearly worse than changing  to 4,

> This is clear: all implementations that reported (with the exception
> of the new revision from cisco) use the value of 4.

Agreed. Taking care of this.

We also need to make sure we don't have situations like this in
future. The solution with Expert Review Thomas proposed seems to be
reasonable.

Alex

>>    and
>>  - changing to 4 doesn't cause hardship and confusion for those that
>>    have picked up the IANA-assigned value of 3.

> Both cisco (George Swallow) and OIF (Ben Mack-Crane) have stated on
> this list that reverting to 4 is acceptable *if done quickly*.  So,
> can we do this quickly?

> Kireeti.
> -------

Delivery-date: Fri, 16 Jan 2004 18:30:12 +0000
Date: Fri, 16 Jan 2004 10:28:53 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Ben Mack-Crane <[email-masked]>
cc: [email-masked]
Subject: Re: IANA assignments

On Fri, 16 Jan 2004, Ben Mack-Crane wrote:

> Adrian and all,
>
> After checking with the OIF, I understand that UNI1.0r2 has passed Straw
> Ballot but
> not Principal Ballot.  The value in question could be adjusted as an
> editorial change before
> going to Principal Ballot.  The OIF is meeting next week and UNI1.0r2 is
> likely to go
> to Principal Ballot soon.

Thanks for the update, Ben.  We'll try to resolve this quickly.

Kireeti.
-------

Delivery-date: Fri, 16 Jan 2004 18:29:57 +0000
Date: Fri, 16 Jan 2004 10:27:13 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Thomas Narten <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: IANA assignments 

On Fri, 16 Jan 2004, Thomas Narten wrote:

> It might be possible to change this assignment if people can make a
> clear case that:
>
>  - leaving the assignment of 3 is clearly worse than changing  to 4,

This is clear: all implementations that reported (with the exception
of the new revision from cisco) use the value of 4.

>    and
>  - changing to 4 doesn't cause hardship and confusion for those that
>    have picked up the IANA-assigned value of 3.

Both cisco (George Swallow) and OIF (Ben Mack-Crane) have stated on
this list that reverting to 4 is acceptable *if done quickly*.  So,
can we do this quickly?

Kireeti.
-------

Delivery-date: Fri, 16 Jan 2004 15:25:26 +0000
Date: Fri, 16 Jan 2004 09:05:25 -0600
From: Ben Mack-Crane <[email-masked]>
To: [email-masked]
CC: Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
Subject: Re: IANA assignments

--------------080207010105030209060601
Content-Type: text/plain;
	charset="us-ascii";
	format="flowed"
Content-Transfer-Encoding: 7bit

Adrian and all,

After checking with the OIF, I understand that UNI1.0r2 has passed Straw 
Ballot but
not Principal Ballot.  The value in question could be adjusted as an 
editorial change before
going to Principal Ballot.  The OIF is meeting next week and UNI1.0r2 is 
likely to go
to Principal Ballot soon.

Regards,
Ben

[email-masked] wrote:

> Adrian,
>
> Initially OIF used the value (4) in UNI1.0.  I do not know how this value
> was chosen, or who chose it, but this is probably how it came into 
> common use, since UNI
> interop was done quite a while ago.
>
> While making minor corrections and updates to conform with IETF RFCs 
> (since UNI1.0
> was based on drafts) we consulted the IANA assignments and found (3), 
> so that value
> was used as the corrected value in UNI1.0r2.
>
> So, OIF has followed the official IANA assignment.
>
> Regards,
> Ben
>
> Adrian Farrel wrote:
>
>>Erm,
>>Which order this happen Ben?
>>
>>IANA or OIF first?
>>
>>Thanks,
>>Adrian
>>----- Original Message ----- 
>>From: "Ben Mack-Crane" <[email-masked]>
>>To: <[email-masked]>
>>Cc: <[email-masked]>
>>Sent: Wednesday, January 14, 2004 4:02 PM
>>Subject: Re: IANA assignments
>>
>>
>>  
>>
>>>To add to Andy's factual response on Tellabs' implementations,
>>>I would like to support Bert's messages on following the process
>>>and also state that we are willing to update our implementation
>>>to support the "right" codepoint.
>>>
>>>Other standards organizations depend on the stability of the
>>>IANA process.  For example, the recently approved OIF UNI1.0r2 IA
>>>specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
>>>This will be a problem if the IANA assignment is changed.
>>>
>>>Regards,
>>>Ben Mack-Crane
>>>
>>>[email-masked] wrote:
>>>
>>>    
>>>
>>>>Ditto for Tellabs (the same as Kireeti's answer).
>>>>
>>>>Andy
>>>>
>>>>------------
>>>>
>>>>At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:
>>>>
>>>>      
>>>>
>>>>>On Fri, 9 Jan 2004, Kireeti Kompella wrote:
>>>>>
>>>>>For the record, here is the answer from Juniper's implementation:
>>>>>
>>>>>        
>>>>>
>>>>>>a) do you use the FLOWSPEC C-Type 3 for CoS?
>>>>>>          
>>>>>>
>>>>>We parse this, but don't really use it.
>>>>>
>>>>>        
>>>>>
>>>>>>b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>>>>>>   you use for the C-Type?
>>>>>>          
>>>>>>
>>>>>Yes. Value 4.
>>>>>
>>>>>        
>>>>>
>>>>>>c) do you use the TSPEC C-Type 3 for CoS?
>>>>>>          
>>>>>>
>>>>>We parse this, but don't really use it.
>>>>>
>>>>>        
>>>>>
>>>>>>d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>>>>>>   you use for the C-Type?
>>>>>>          
>>>>>>
>>>>>Yes. Value 4.
>>>>>
>>>>>Kireeti.
>>>>>-------
>>>>>        
>>>>>
>>>>      
>>>>
>>>-----------------------------------------
>>>============================================================
>>>The information contained in this message may be privileged 
>>>and confidential and protected from disclosure.  If the 
>>>reader of this message is not the intended recipient, or an 
>>>employee or agent responsible for delivering this message to 
>>>the intended recipient, you are hereby notified that any 
>>>reproduction, dissemination or distribution of this 
>>>communication is strictly prohibited. If you have received 
>>>this communication in error, please notify us immediately by 
>>>replying to the message and deleting it from your computer.
>>>
>>>Thank you.
>>>Tellabs
>>>============================================================
>>>
>>>
>>>
>>>
>>>    
>>>
>>
>>  
>>
>
> ------------------------------------------------------------------------
>
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure. If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
>
> Thank you.
> Tellabs
> ============================================================
>

-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================
--------------080207010105030209060601
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

<HTML>
<BODY>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Adrian and all,<br>
<br>
After checking with the OIF, I understand that UNI1.0r2 has passed Straw
Ballot but<br>
not Principal Ballot. &nbsp;The value in question could be adjusted as an editorial
change before<br>
going to Principal Ballot. &nbsp;The OIF is meeting next week and UNI1.0r2 is
likely to go<br>
to Principal Ballot soon.<br>
<br>
Regards,<br>
Ben<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> wrote:<br>
<blockquote type="cite" cite="[email-masked]">
  <title></title>
         Adrian,<br>
 <br>
 Initially OIF used the value (4) in UNI1.0. &nbsp;I do not know how this value<br>
 was chosen, or who chose it, but this is probably how it came into common 
use, since UNI<br>
 interop was done quite a while ago.<br>
 <br>
 While making minor corrections and updates to conform with IETF RFCs (since 
UNI1.0<br>
 was based on drafts) we consulted the IANA assignments and found (3), so 
that value<br>
 was used as the corrected value in UNI1.0r2.<br>
 <br>
 So, OIF has followed the official IANA assignment.<br>
 <br>
 Regards,<br>
 Ben<br>
 <br>
 Adrian Farrel wrote:<br>
 
  <blockquote type="cite" cite="mid033b01c3daed$aa9ee430$715708c3@Puppy"> 
  
    <pre wrap="">Erm,
Which order this happen Ben?

IANA or OIF first?

Thanks,
Adrian
----- Original Message ----- 
From: "Ben Mack-Crane" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
To: <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Cc: <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Sent: Wednesday, January 14, 2004 4:02 PM
Subject: Re: IANA assignments

  </pre>
   
    <blockquote type="cite">     
      <pre wrap="">To add to Andy's factual response on Tellabs' implementations,
I would like to support Bert's messages on following the process
and also state that we are willing to update our implementation
to support the "right" codepoint.

Other standards organizations depend on the stability of the
IANA process.  For example, the recently approved OIF UNI1.0r2 IA
specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
This will be a problem if the IANA assignment is changed.

Regards,
Ben Mack-Crane

<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> wrote:

    </pre>
     
      <blockquote type="cite">       
        <pre wrap="">Ditto for Tellabs (the same as Kireeti's answer).

Andy

------------

At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:

      </pre>
       
        <blockquote type="cite">         
          <pre wrap="">On Fri, 9 Jan 2004, Kireeti Kompella wrote:

For the record, here is the answer from Juniper's implementation:

        </pre>
         
          <blockquote type="cite">           
            <pre wrap="">a) do you use the FLOWSPEC C-Type 3 for CoS?
          </pre>
         </blockquote>
         
          <pre wrap="">We parse this, but don't really use it.

        </pre>
         
          <blockquote type="cite">           
            <pre wrap="">b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
   you use for the C-Type?
          </pre>
         </blockquote>
         
          <pre wrap="">Yes. Value 4.

        </pre>
         
          <blockquote type="cite">           
            <pre wrap="">c) do you use the TSPEC C-Type 3 for CoS?
          </pre>
         </blockquote>
         
          <pre wrap="">We parse this, but don't really use it.

        </pre>
         
          <blockquote type="cite">           
            <pre wrap="">d) have you implemented the SONET/SDH TSPEC?  If so, what value did
   you use for the C-Type?
          </pre>
         </blockquote>
         
          <pre wrap="">Yes. Value 4.

Kireeti.
-------
        </pre>
       </blockquote>
       
        <pre wrap="">      </pre>
     </blockquote>
     
      <pre wrap="">
-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

    </pre>
   </blockquote>
   
    <pre wrap=""><!---->
  </pre>
 </blockquote>
 <br>
 
  <hr size="1"> 
  <p><strong>============================================================<br>
The information contained in this message may be privileged <br>
and confidential and protected from disclosure.  If the <br>
reader of this message is not the intended recipient, or an <br>
employee or agent responsible for delivering this message to <br>
the intended recipient, you are hereby notified that any <br>
reproduction, dissemination or distribution of this <br>
communication is strictly prohibited. If you have received <br>
this communication in error, please notify us immediately by <br>
replying to the message and deleting it from your computer.<br>
  <br>
Thank you.<br>
Tellabs<br>
============================================================</strong></p>
 </blockquote>
<br>
</body>
</html>

<P><hr size=1></P>
<P><STRONG>============================================================<br>The information contained in this message may be privileged <br>and confidential and protected from disclosure.  If the <br>reader of this message is not the intended recipient, or an <br>employee or agent responsible for delivering this message to <br>the intended recipient, you are hereby notified that any <br>reproduction, dissemination or distribution of this <br>communication is strictly prohibited. If you have received <br>this communication in error, please notify us immediately by <br>replying to the message and deleting it from your computer.<br><br>Thank you.<br>Tellabs<br>============================================================</STRONG></P>
</BODY>
</HTML>
--------------080207010105030209060601--

Envelope-to: [email-masked]
Delivery-date: Fri, 16 Jan 2004 12:23:27 +0000
Message-Id: <[email-masked]>
To: Kireeti Kompella <[email-masked]>
cc: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: IANA assignments 
Date: Fri, 16 Jan 2004 07:16:42 -0500
From: Thomas Narten <[email-masked]>

> The priority here is simple: the *IETF* has asked IANA for assignment
> of a code point; the most reasonable value of that code point *based
> on implementations of the IETF draft/RFC* is 4.

This may well be a correct statement, prior to IANA having made the
assignment. Now that they have published 3 as the "correct" value,
things are no longer so simple.

> The OIF is *not* a standards organization; for the IETF to change
> what is the right decision based on premature actions of the OIF is
> a sign of weakness.  In any case, 'signs of weakness' should NOT be
> our guiding principle -- we should do what is right and reasonable.

This is not about weakness. A fundamental property of assignments is
that they are stable and do not change. Once IANA makes an assignment,
it needs to have very very very good reasons for backing out and
making a change.

> BTW, to put this in perspective, OIF UNI1.0 uses a code point value
> of 4.  If the value of 3 was 'approved' by the OIF for UNI1.0r2, it
> seems to me that the OIF really jumped the gun: the RFC has not been
> published and discussion of code point assignments is not complete.

Actually, the IANA assignment step and RFC publication are
different. The IANA step occurs when IANA announces its assignment
(whether via email, by posting a message, by updating their web pages,
etc.). An RFC can't be published until after IANA makes any relevant
assignments. So even though the RFC may not be out, the code point
assignment has been completed, officially.

> Perhaps the OIF can approve (as soon as we complete the discussion and
> reach the right conclusion) UNI1.0r3 with the correct value.

It would be extremely useful for someone to ask OIF about the
feasibility of this. And to comment on what other organization may
have picked up the IANA-published value at this point.

> I stand by my recommendation that IANA assign a value of 4 for the
> SDH/SONET C-Types for FLOWSPEC and TSPEC.

I think we all agree that would have been the logical assignment.
Problem is, we're past that point now and reversing an assignment is
not so simple.

Thomas

Envelope-to: [email-masked]
Delivery-date: Fri, 16 Jan 2004 12:20:12 +0000
Message-Id: <[email-masked]>
To: Kireeti Kompella <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: IANA assignments 
Date: Fri, 16 Jan 2004 07:14:50 -0500
From: Thomas Narten <[email-masked]>

> On that basis, I would strongly recommend IANA to assign 4 for both
> the C-Types of SONET/SDH TSPEC and FLOWSPEC.

Too late. IANA has already assigned 3 for that value. Given that IANA
is the authority and people may have already taken IANA's published
value (assuming it was the legit value to use) and added it to their
documents, simply changing the assignment is no longer a simple matter
anymore.

It might be possible to change this assignment if people can make a
clear case that:

 - leaving the assignment of 3 is clearly worse than changing  to 4,
   and
 - changing to 4 doesn't cause hardship and confusion for those that
   have picked up the IANA-assigned value of 3.

Thomas

Envelope-to: [email-masked]
Delivery-date: Fri, 16 Jan 2004 12:19:55 +0000
Message-Id: <[email-masked]>
To: "Naidu, Venkata" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, IETF CCAMP List <[email-masked]>, [email-masked]
Subject: Re: IANA assignments 
Date: Fri, 16 Jan 2004 07:13:44 -0500
From: Thomas Narten <[email-masked]>

>   All I am saying is, IANA can have a guideline for long lived
>   drafts, such as:
>   
>      If there is a shipped implementation with an old deprecated
>      value, that value MUST be reserved to prevent future misuse.
>      It MUST be noted in the subsequent drafts and final RFC.

Well, a more proper way to express the above (process wise) would be
to have an IANA considerations Section (for the name space at issue)
of something like:

   values in the range 0-128 are assigned via Standards Action or
   Expert Review. The purpose of Expert Review assignments is for the
   assignment of code points in cases where the document is expected
   to become published as a standards track RFC (e.g., it is a Working
   Group document), but for which experimentation is desired before
   the RFC is published.

Tune further as appropriate. Then, when a WG needs an assignment, it
asks IANA to make the assignment, IANA checks with the expert, and
assuming the request is proper, the assignment gets made.

The point is that there are ways for the WG to retain control over
assignments that IANA is managing. That is what IANA Considerations
sections are for.

Thomas

Envelope-to: [email-masked]
Delivery-date: Fri, 16 Jan 2004 12:19:43 +0000
Message-Id: <[email-masked]>
To: "Naidu, Venkata" <[email-masked]>
cc: "'Wijnen, Bert (Bert)'" <[email-masked]>, IETF CCAMP List <[email-masked]>, [email-masked]
Subject: Re: IANA assignments 
Date: Fri, 16 Jan 2004 07:12:18 -0500
From: Thomas Narten <[email-masked]>

>   Is it possible for IANA to initiate a discussion in the mailing-list
>   before publishing a value, at least, for long lived drafts ?

Not really practical. Please see RFC 2434, where it talks about
mailing lists. Bottom line: IANA doesn't have the resources or
subject-matter expertise to read mailing list discussions and make
sense out of the diverse opinions that tend to get expressed.

But one can certainly write an IANA considerations section (again see
RFC 2434) that specifies that a Designated Expert should make the
evaluation, and one of the steps of that process could be to check
with relevant WGs first, and so forth.

WGs have a lot of flexibility in defining how they want their name
spaces managed. But IANA certainly can't guess what the right thing to
do is. That's why it's so important the authors/WGs pay attention to
IANA considerations and specify them carefully.

Thomas

Delivery-date: Fri, 16 Jan 2004 01:33:05 +0000
Date: Thu, 15 Jan 2004 17:30:01 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>
CC: "'Vishal Sharma'" <[email-masked]>, [email-masked], "'CCAMP'" <[email-masked]>,  "'MPLS'" <[email-masked]>
Subject: Re: Outdated WG charters?!

Folks-

 There was a problem with the IETF WG database, which the secretariat
 should have fixed. The WG web-pages are regenerated nightly, so if
 everything is fixed, we should not see any problems tomorrow.

-- 
Alex
http://www.psg.com/~zinin/

Thursday, January 15, 2004, 7:50:22 AM, Thomas D. Nadeau wrote:

>         BTW, there are other errors I noticed with
> the PWE3 and MPLS WG pages pointing at other
> out-dated drafts.  Looks like the web server
> was restored from some (really) old backups.

>         --Tom

>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of Vishal Sharma
>> Sent: Wednesday, January 14, 2004 10:54 PM
>> To: [email-masked]
>> Cc: CCAMP; MPLS
>> Subject: Outdated WG charters?!
>> Importance: High
>> 
>> 
>> Hello,
>> 
>> It appears that the Charter updates posted by the IETF Secretariat
>> at
>> http://www.ietf.org/html.charters/wg-dir.html just this evening
>> (at least) for CCAMP and MPLS WGs are completely outdated (over
>> a year old).
>> 
>> I believe an error was made in posting these, and it would be
>> great if this could be corrected at the earliest (otherwise
>> it's very difficult to access the latest WG documents).
>> 
>> Thanks much!
>> 
>> -Vishal
>> 
>> PS: If I am the only one experiencing this problem, please let
>> me know. I've flushed all caches and buffers, so I don't think
>> the problem is at my end.
>> 

Envelope-to: [email-masked]
Delivery-date: Thu, 15 Jan 2004 16:25:55 +0000
Message-Id: <[email-masked]>
To: Kireeti Kompella <[email-masked]>
cc: [email-masked], [email-masked]
cc: [email-masked]
Subject: Re: IANA assignments 
Date: Thu, 15 Jan 2004 11:23:17 -0500
From: George Swallow <[email-masked]>

> Let me start with the second issue, as it is more relevant to CCAMP.
> The responses I got unanimously state that the codepoint value used
> for SONET/SDH TSPEC and FLOWSPEC is 4.  There is a minor wrinkle here
> that in Cisco's implementation, the initial version used 4 and a later
> revision uses 3.  Apart from that, all responses (from about 10
> independent implementations, if memory serves) indicated that they use
> the value 4.

Cisco doesn't care which value is used.  We DO want the issue resolved
SOON.

> On that basis, I would strongly recommend IANA to assign 4 for both
> the C-Types of SONET/SDH TSPEC and FLOWSPEC.
> 
> The other issue, what to do with the value of 3, is less clear.  Most
> responses indicated that they either parsed and ignored or simply
> ignored this value.  As CCAMP WG chair, I don't have a stand on
> whether this value should be set aside as reserved, or left as a hole
> in the address space, to be assigned to the next request for a code
> point for a TSPEC/FLOWSPEC C-Type.

I say leave it as a hole but have a note that says it won't get assigned
until at least 2005.  (To give folks time to field versions that don't
parse this.)

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

Delivery-date: Thu, 15 Jan 2004 15:53:49 +0000
Date: Thu, 15 Jan 2004 09:50:48 -0600
From: Ben Mack-Crane <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: IANA assignments

Kireeti,

I don't understand how OIF "jumped the gun" by using a value from the 
IANA website,
which I understand is the authoritative source for number assignments.

Regards,
Ben

Kireeti Kompella wrote:

<snip>

>If the value of 3 was 'approved' by the OIF for UNI1.0r2, it
>seems to me that the OIF really jumped the gun: the RFC has not been
>published and discussion of code point assignments is not complete.
>
<snip>

>Kireeti.
>-------

-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Thu, 15 Jan 2004 15:51:38 +0000
Reply-To: <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
To: "'Vishal Sharma'" <[email-masked]>, <[email-masked]>
Cc: "'CCAMP'" <[email-masked]>, "'MPLS'" <[email-masked]>
Subject: RE: Outdated WG charters?!
Date: Thu, 15 Jan 2004 10:50:22 -0500
Organization: Cisco Systems, inc.

	BTW, there are other errors I noticed with
the PWE3 and MPLS WG pages pointing at other
out-dated drafts.  Looks like the web server
was restored from some (really) old backups.

	--Tom

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Vishal Sharma
> Sent: Wednesday, January 14, 2004 10:54 PM
> To: [email-masked]
> Cc: CCAMP; MPLS
> Subject: Outdated WG charters?!
> Importance: High
> 
> 
> Hello,
> 
> It appears that the Charter updates posted by the IETF Secretariat
> at
> http://www.ietf.org/html.charters/wg-dir.html just this evening
> (at least) for CCAMP and MPLS WGs are completely outdated (over
> a year old).
> 
> I believe an error was made in posting these, and it would be
> great if this could be corrected at the earliest (otherwise
> it's very difficult to access the latest WG documents).
> 
> Thanks much!
> 
> -Vishal
> 
> PS: If I am the only one experiencing this problem, please let
> me know. I've flushed all caches and buffers, so I don't think
> the problem is at my end.
> 

Delivery-date: Thu, 15 Jan 2004 15:22:39 +0000
Date: Thu, 15 Jan 2004 09:17:48 -0600
From: Ben Mack-Crane <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: IANA assignments

--------------010705070204010203070609
Content-Type: text/plain;
	charset="us-ascii";
	format="flowed"
Content-Transfer-Encoding: 7bit

Adrian,

Initially OIF used the value (4) in UNI1.0.  I do not know how this value
was chosen, or who chose it, but this is probably how it came into 
common use, since UNI
interop was done quite a while ago.

While making minor corrections and updates to conform with IETF RFCs 
(since UNI1.0
was based on drafts) we consulted the IANA assignments and found (3), so 
that value
was used as the corrected value in UNI1.0r2.

So, OIF has followed the official IANA assignment.

Regards,
Ben

Adrian Farrel wrote:

>Erm,
>Which order this happen Ben?
>
>IANA or OIF first?
>
>Thanks,
>Adrian
>----- Original Message ----- 
>From: "Ben Mack-Crane" <[email-masked]>
>To: <[email-masked]>
>Cc: <[email-masked]>
>Sent: Wednesday, January 14, 2004 4:02 PM
>Subject: Re: IANA assignments
>
>
>  
>
>>To add to Andy's factual response on Tellabs' implementations,
>>I would like to support Bert's messages on following the process
>>and also state that we are willing to update our implementation
>>to support the "right" codepoint.
>>
>>Other standards organizations depend on the stability of the
>>IANA process.  For example, the recently approved OIF UNI1.0r2 IA
>>specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
>>This will be a problem if the IANA assignment is changed.
>>
>>Regards,
>>Ben Mack-Crane
>>
>>[email-masked] wrote:
>>
>>    
>>
>>>Ditto for Tellabs (the same as Kireeti's answer).
>>>
>>>Andy
>>>
>>>------------
>>>
>>>At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:
>>>
>>>      
>>>
>>>>On Fri, 9 Jan 2004, Kireeti Kompella wrote:
>>>>
>>>>For the record, here is the answer from Juniper's implementation:
>>>>
>>>>        
>>>>
>>>>>a) do you use the FLOWSPEC C-Type 3 for CoS?
>>>>>          
>>>>>
>>>>We parse this, but don't really use it.
>>>>
>>>>        
>>>>
>>>>>b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>>>>>   you use for the C-Type?
>>>>>          
>>>>>
>>>>Yes. Value 4.
>>>>
>>>>        
>>>>
>>>>>c) do you use the TSPEC C-Type 3 for CoS?
>>>>>          
>>>>>
>>>>We parse this, but don't really use it.
>>>>
>>>>        
>>>>
>>>>>d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>>>>>   you use for the C-Type?
>>>>>          
>>>>>
>>>>Yes. Value 4.
>>>>
>>>>Kireeti.
>>>>-------
>>>>        
>>>>
>>>      
>>>
>>
>>-----------------------------------------
>>============================================================
>>The information contained in this message may be privileged 
>>and confidential and protected from disclosure.  If the 
>>reader of this message is not the intended recipient, or an 
>>employee or agent responsible for delivering this message to 
>>the intended recipient, you are hereby notified that any 
>>reproduction, dissemination or distribution of this 
>>communication is strictly prohibited. If you have received 
>>this communication in error, please notify us immediately by 
>>replying to the message and deleting it from your computer.
>>
>>Thank you.
>>Tellabs
>>============================================================
>>
>>
>>
>>
>>    
>>
>
>  
>

-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================
--------------010705070204010203070609
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

<HTML>
<BODY>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Adrian,<br>
<br>
Initially OIF used the value (4) in UNI1.0. &nbsp;I do not know how this value<br>
was chosen, or who chose it, but this is probably how it came into common
use, since UNI<br>
interop was done quite a while ago.<br>
<br>
While making minor corrections and updates to conform with IETF RFCs (since
UNI1.0<br>
was based on drafts) we consulted the IANA assignments and found (3), so
that value<br>
was used as the corrected value in UNI1.0r2.<br>
<br>
So, OIF has followed the official IANA assignment.<br>
<br>
Regards,<br>
Ben<br>
<br>
Adrian Farrel wrote:<br>
<blockquote type="cite" cite="mid033b01c3daed$aa9ee430$715708c3@Puppy">
  <pre wrap="">Erm,
Which order this happen Ben?

IANA or OIF first?

Thanks,
Adrian
----- Original Message ----- 
From: "Ben Mack-Crane" <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
To: <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Cc: <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Sent: Wednesday, January 14, 2004 4:02 PM
Subject: Re: IANA assignments

  </pre>
  <blockquote type="cite">
    <pre wrap="">To add to Andy's factual response on Tellabs' implementations,
I would like to support Bert's messages on following the process
and also state that we are willing to update our implementation
to support the "right" codepoint.

Other standards organizations depend on the stability of the
IANA process.  For example, the recently approved OIF UNI1.0r2 IA
specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
This will be a problem if the IANA assignment is changed.

Regards,
Ben Mack-Crane

<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">Ditto for Tellabs (the same as Kireeti's answer).

Andy

------------

At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:

      </pre>
      <blockquote type="cite">
        <pre wrap="">On Fri, 9 Jan 2004, Kireeti Kompella wrote:

For the record, here is the answer from Juniper's implementation:

        </pre>
        <blockquote type="cite">
          <pre wrap="">a) do you use the FLOWSPEC C-Type 3 for CoS?
          </pre>
        </blockquote>
        <pre wrap="">We parse this, but don't really use it.

        </pre>
        <blockquote type="cite">
          <pre wrap="">b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
   you use for the C-Type?
          </pre>
        </blockquote>
        <pre wrap="">Yes. Value 4.

        </pre>
        <blockquote type="cite">
          <pre wrap="">c) do you use the TSPEC C-Type 3 for CoS?
          </pre>
        </blockquote>
        <pre wrap="">We parse this, but don't really use it.

        </pre>
        <blockquote type="cite">
          <pre wrap="">d) have you implemented the SONET/SDH TSPEC?  If so, what value did
   you use for the C-Type?
          </pre>
        </blockquote>
        <pre wrap="">Yes. Value 4.

Kireeti.
-------
        </pre>
      </blockquote>
      <pre wrap="">
      </pre>
    </blockquote>
    <pre wrap="">

-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
</body>
</html>

<P><hr size=1></P>
<P><STRONG>============================================================<br>The information contained in this message may be privileged <br>and confidential and protected from disclosure.  If the <br>reader of this message is not the intended recipient, or an <br>employee or agent responsible for delivering this message to <br>the intended recipient, you are hereby notified that any <br>reproduction, dissemination or distribution of this <br>communication is strictly prohibited. If you have received <br>this communication in error, please notify us immediately by <br>replying to the message and deleting it from your computer.<br><br>Thank you.<br>Tellabs<br>============================================================</STRONG></P>
</BODY>
</HTML>
--------------010705070204010203070609--

Delivery-date: Thu, 15 Jan 2004 08:15:51 +0000
Date: Thu, 15 Jan 2004 00:14:14 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: IANA assignments

On Thu, 15 Jan 2004, Wijnen, Bert (Bert) wrote:

> I hope you also realize that it was pointed out that OIF has assumed
> the assigned value of 3 (probably because IANA had assigned it and
> published it on the iana web pages... Adrian has asked the question
> if it is indeed so or not). So if IANA changes it, it may be perceived
> by outside world as a weakness. Not sure it is.. but we should check
> (or so I think... IANA pls let us know what you think about this).

I do realize that.

The priority here is simple: the *IETF* has asked IANA for assignment
of a code point; the most reasonable value of that code point *based
on implementations of the IETF draft/RFC* is 4.  The OIF is *not* a
standards organization; for the IETF to change what is the right
decision based on premature actions of the OIF is a sign of weakness.
In any case, 'signs of weakness' should NOT be our guiding principle
-- we should do what is right and reasonable.

BTW, to put this in perspective, OIF UNI1.0 uses a code point value
of 4.  If the value of 3 was 'approved' by the OIF for UNI1.0r2, it
seems to me that the OIF really jumped the gun: the RFC has not been
published and discussion of code point assignments is not complete.
Perhaps the OIF can approve (as soon as we complete the discussion and
reach the right conclusion) UNI1.0r3 with the correct value.  Note
that many participants in the CCAMP mailing list have implemented OIF
UNI1.0, and I have not heard that we should change the value to 3; in
fact, Tellabs' own implementation uses 4 today.

I stand by my recommendation that IANA assign a value of 4 for the
SDH/SONET C-Types for FLOWSPEC and TSPEC.

Kireeti.
-------

Delivery-date: Thu, 15 Jan 2004 06:20:35 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: IANA assignments
Date: Thu, 15 Jan 2004 07:18:23 +0100

> On Fri, 9 Jan 2004, Kireeti Kompella wrote:
> 
> > a) do you use the FLOWSPEC C-Type 3 for CoS?
> > b) have you implemented the SONET/SDH FLOWSPEC?  If so, 
> what value did
> >    you use for the C-Type?
> > c) do you use the TSPEC C-Type 3 for CoS?
> > d) have you implemented the SONET/SDH TSPEC?  If so, what value did
> >    you use for the C-Type?
> 
> There are two issues at hand:
>  i) what should be done about the codepoint value of 3? and
> ii) what value should be assigned for the SONET/SDH TSPEC and 
> FLOWSPEC?
> 
> Let me start with the second issue, as it is more relevant to CCAMP.
> The responses I got unanimously state that the codepoint value used
> for SONET/SDH TSPEC and FLOWSPEC is 4.  There is a minor wrinkle here
> that in Cisco's implementation, the initial version used 4 and a later
> revision uses 3.  Apart from that, all responses (from about 10
> independent implementations, if memory serves) indicated that they use
> the value 4.
> 
> On that basis, I would strongly recommend IANA to assign 4 for both
> the C-Types of SONET/SDH TSPEC and FLOWSPEC.
> 
I hope you also realize that it was pointed out that OIF has assumed 
the assigned value of 3 (probably because IANA had assigned it and 
published it on the iana web pages... Adrian has asked the question
if it is indeed so or not). So if IANA changes it, it may be perceived
by outside world as a weakness. Not sure it is.. but we should check
(or so I think... IANA pls let us know what you think about this).

Bert

Delivery-date: Thu, 15 Jan 2004 03:55:06 +0000
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>
Cc: "CCAMP" <[email-masked]>, "MPLS" <[email-masked]>
Subject: Outdated WG charters?!
Date: Wed, 14 Jan 2004 19:53:47 -0800

Hello,

It appears that the Charter updates posted by the IETF Secretariat
at
http://www.ietf.org/html.charters/wg-dir.html just this evening
(at least) for CCAMP and MPLS WGs are completely outdated (over
a year old).

I believe an error was made in posting these, and it would be
great if this could be corrected at the earliest (otherwise
it's very difficult to access the latest WG documents).

Thanks much!

-Vishal

PS: If I am the only one experiencing this problem, please let
me know. I've flushed all caches and buffers, so I don't think
the problem is at my end.

Delivery-date: Thu, 15 Jan 2004 03:15:20 +0000
Date: Wed, 14 Jan 2004 19:13:22 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: RE: IANA assignments

Hi All,

On Fri, 9 Jan 2004, Kireeti Kompella wrote:

> a) do you use the FLOWSPEC C-Type 3 for CoS?
> b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>    you use for the C-Type?
> c) do you use the TSPEC C-Type 3 for CoS?
> d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>    you use for the C-Type?

There are two issues at hand:
 i) what should be done about the codepoint value of 3? and
ii) what value should be assigned for the SONET/SDH TSPEC and FLOWSPEC?

Let me start with the second issue, as it is more relevant to CCAMP.
The responses I got unanimously state that the codepoint value used
for SONET/SDH TSPEC and FLOWSPEC is 4.  There is a minor wrinkle here
that in Cisco's implementation, the initial version used 4 and a later
revision uses 3.  Apart from that, all responses (from about 10
independent implementations, if memory serves) indicated that they use
the value 4.

On that basis, I would strongly recommend IANA to assign 4 for both
the C-Types of SONET/SDH TSPEC and FLOWSPEC.

The other issue, what to do with the value of 3, is less clear.  Most
responses indicated that they either parsed and ignored or simply
ignored this value.  As CCAMP WG chair, I don't have a stand on
whether this value should be set aside as reserved, or left as a hole
in the address space, to be assigned to the next request for a code
point for a TSPEC/FLOWSPEC C-Type.

Kireeti.
-------

Delivery-date: Wed, 14 Jan 2004 22:28:38 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ben Mack-Crane" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: IANA assignments
Date: Wed, 14 Jan 2004 22:27:53 -0000

Erm,
Which order this happen Ben?

IANA or OIF first?

Thanks,
Adrian
----- Original Message ----- 
From: "Ben Mack-Crane" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 14, 2004 4:02 PM
Subject: Re: IANA assignments

> To add to Andy's factual response on Tellabs' implementations,
> I would like to support Bert's messages on following the process
> and also state that we are willing to update our implementation
> to support the "right" codepoint.
> 
> Other standards organizations depend on the stability of the
> IANA process.  For example, the recently approved OIF UNI1.0r2 IA
> specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
> This will be a problem if the IANA assignment is changed.
> 
> Regards,
> Ben Mack-Crane
> 
> [email-masked] wrote:
> 
> > Ditto for Tellabs (the same as Kireeti's answer).
> >
> > Andy
> >
> > ------------
> >
> > At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:
> >
> >> On Fri, 9 Jan 2004, Kireeti Kompella wrote:
> >>
> >> For the record, here is the answer from Juniper's implementation:
> >>
> >> > a) do you use the FLOWSPEC C-Type 3 for CoS?
> >>
> >> We parse this, but don't really use it.
> >>
> >> > b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
> >> >    you use for the C-Type?
> >>
> >> Yes. Value 4.
> >>
> >> > c) do you use the TSPEC C-Type 3 for CoS?
> >>
> >> We parse this, but don't really use it.
> >>
> >> > d) have you implemented the SONET/SDH TSPEC?  If so, what value did
> >> >    you use for the C-Type?
> >>
> >> Yes. Value 4.
> >>
> >> Kireeti.
> >> -------
> >
> >
> 
> 
> 
> -----------------------------------------
> ============================================================
> The information contained in this message may be privileged 
> and confidential and protected from disclosure.  If the 
> reader of this message is not the intended recipient, or an 
> employee or agent responsible for delivering this message to 
> the intended recipient, you are hereby notified that any 
> reproduction, dissemination or distribution of this 
> communication is strictly prohibited. If you have received 
> this communication in error, please notify us immediately by 
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
> 
> 
> 
> 

Delivery-date: Wed, 14 Jan 2004 22:27:21 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: RFC3473
Date: Wed, 14 Jan 2004 22:26:31 -0000

Hi M,

I see the following in RFC3473...

2.3. Generalized Label Object

   The format of a Generalized Label object is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | Class-Num (16)|   C-Type (2)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Label                             |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   See [RFC3471] for a description of parameters and encoding of labels.

Looks like a C-Num and a C-Type from where I'm standing.

Cheers,
Adrian

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 14, 2004 4:35 PM
Subject: RFC3473

> Hi, I was reading the RFC 3473 and observed that Class-Num and C-Type in label were not
specified and it gives only reference to the RFC 3471 but there are no definition of
Class-Num or C-Type defined in RFC 3471.
>
> So what is Class-Num and C-Type?
>
> M
>
>
>
>

Delivery-date: Wed, 14 Jan 2004 22:24:07 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: Temporary Registy for LSP-ATTRIBUTE flags
Date: Wed, 14 Jan 2004 13:20:29 -0000

All,

I have created a temporary registry for flags in the new LSP Attribute Flags TLV and RRO
Attribute Flags RRO subobject as defined in draft-ietf-mpls-rsvpte-attributes.

Please note that this is a temporary and provisional registry. It does not replace the
IANA registration of these flags. Implementers are advised that an entry in this temporary
registry does not guarantee the use of a particular bit in the final RFC.

This registry does provide a place to register provisional bit assignments so that
experimental implementations may hope to interwork and so that new Internet Drafts may
suggest bit numbers that do not conflict.

You can reach the registry at http://www.olddog.co.uk/lsp-attrib.txt

If it would help you to have your bit-usage registered, please send me your registration
requests.

Thanks,
Adrian

Delivery-date: Wed, 14 Jan 2004 16:36:24 +0000
From: <[email-masked]>
Reply-To: [email-masked]
To: <[email-masked]>
Subject: RFC3473
Date: Wed, 14 Jan 2004 17:35:06 +0100

Hi, I was reading the RFC 3473 and observed that Class-Num and C-Type in label were not specified and it gives only reference to the RFC 3471 but there are no definition of Class-Num or C-Type defined in RFC 3471.

So what is Class-Num and C-Type?

M 

Delivery-date: Wed, 14 Jan 2004 16:09:46 +0000
Date: Wed, 14 Jan 2004 10:02:14 -0600
From: Ben Mack-Crane <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: IANA assignments

To add to Andy's factual response on Tellabs' implementations,
I would like to support Bert's messages on following the process
and also state that we are willing to update our implementation
to support the "right" codepoint.

Other standards organizations depend on the stability of the
IANA process.  For example, the recently approved OIF UNI1.0r2 IA
specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
This will be a problem if the IANA assignment is changed.

Regards,
Ben Mack-Crane

[email-masked] wrote:

> Ditto for Tellabs (the same as Kireeti's answer).
>
> Andy
>
> ------------
>
> At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:
>
>> On Fri, 9 Jan 2004, Kireeti Kompella wrote:
>>
>> For the record, here is the answer from Juniper's implementation:
>>
>> > a) do you use the FLOWSPEC C-Type 3 for CoS?
>>
>> We parse this, but don't really use it.
>>
>> > b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>> >    you use for the C-Type?
>>
>> Yes. Value 4.
>>
>> > c) do you use the TSPEC C-Type 3 for CoS?
>>
>> We parse this, but don't really use it.
>>
>> > d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>> >    you use for the C-Type?
>>
>> Yes. Value 4.
>>
>> Kireeti.
>> -------
>
>

-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Tue, 13 Jan 2004 19:40:14 +0000
Date: Tue, 13 Jan 2004 14:04:00 -0500
To: [email-masked]
From: "Andrew G. Malis" <[email-masked]>
Subject: RE: IANA assignments

Ditto for Tellabs (the same as Kireeti's answer).

Andy

------------

At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:
>On Fri, 9 Jan 2004, Kireeti Kompella wrote:
>
>For the record, here is the answer from Juniper's implementation:
>
> > a) do you use the FLOWSPEC C-Type 3 for CoS?
>
>We parse this, but don't really use it.
>
> > b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
> >    you use for the C-Type?
>
>Yes. Value 4.
>
> > c) do you use the TSPEC C-Type 3 for CoS?
>
>We parse this, but don't really use it.
>
> > d) have you implemented the SONET/SDH TSPEC?  If so, what value did
> >    you use for the C-Type?
>
>Yes. Value 4.
>
>Kireeti.
>-------

Envelope-to: [email-masked]
Delivery-date: Tue, 13 Jan 2004 18:38:42 +0000
Message-Id: <[email-masked]>
To: Kireeti Kompella <[email-masked]>
cc: [email-masked], [email-masked]
cc: [email-masked]
Subject: Re: IANA assignments 
Date: Tue, 13 Jan 2004 13:36:25 -0500
From: George Swallow <[email-masked]>

> Okay, in order to come to some conclusion here, those of you who have
> implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:
> 
> a) do you use the FLOWSPEC C-Type 3 for CoS?

No.

> b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>    you use for the C-Type?

Yes,  The initial release used 4.  We have an updated release that uses 3.

> c) do you use the TSPEC C-Type 3 for CoS?

No,

> d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>    you use for the C-Type?

Yes,  The initial release used 4.  We have an updated release that uses 3.

> Please send your answers to the mailing list or to the chairs AND ADs
> at the latest by Wed Jan 14, 2004, 5pm PST.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

Delivery-date: Tue, 13 Jan 2004 15:25:35 +0000
Content-Class: urn:content-classes:message
Subject: draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt
Date: Tue, 13 Jan 2004 07:22:58 -0800
From: "Jonathan Lang" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

All,
  The following typo has been pointed out in
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt and will be fixed during
AUTH48.

"0x0080 J2-trace: J2 Section Trace Correlation

                 Capable of transmitting SONET/SDH VT SPE/LOVC Path
                 trace over J2 Path overhead byte as defined in [T1.105]
                 and [G.707]."

should read

"0x0080 J2-trace: J2 Path Trace Correlation

                 Capable of transmitting SONET/SDH VT SPE/LOVC Path
                 trace over J2 Path overhead byte as defined in [T1.105]
                 and [G.707]."

Thanks,
Jonathan

Delivery-date: Tue, 13 Jan 2004 03:14:23 +0000
From: "Pandian, Vijay" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
Date: Mon, 12 Jan 2004 22:10:37 -0500

	Hi,

	In section 1.4, the Switching Capability-specific information is
described for all types of switching capabilities except for FSC. 

	I assume there is no Switching Capability specific information
present for FSC. Please clarify.

	Regards,

	Vijay

Delivery-date: Tue, 13 Jan 2004 03:11:04 +0000
From: "Pandian, Vijay" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
Date: Mon, 12 Jan 2004 22:05:12 -0500

Hi,

In section 1.4, the Switching Capability-specific information is not
described for all types of switching capabilities except for FSC. 

I assume there is no Switching Capability specific information present for
FSC. Please clarify.

Regards,

Vijay

Delivery-date: Mon, 12 Jan 2004 10:39:30 +0000
Date: Mon, 12 Jan 2004 11:39:29 +0100
From: [email-masked]
To: Diego Caviglia <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-mpls-lsp-hierarchy-08

diego, the document is in the RFC Editor queue (per i-d
status tracker) since nov'02 - thanks, d.

Diego Caviglia wrote:

> Hi all,
>               the ID in the subject expired in March 2002 is there any
> intention to go on with work on FA?
> 
> IMHO that was a good and very usefull work.
> 
> Regards.
> 
> Diego
> 
> 
> 
> ------------------------------------------
> Diego Caviglia
> Marconi - Optical Networks
> ASTN/GMPLS - System Design Manager
> Via A. Negrone 1/A
> 16153 Genoa - Italy
> Phone: +390106003736
> 
> "Timeo Danae et Dona Ferentes"
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Mon, 12 Jan 2004 09:27:35 +0000
Sensitivity: 
Subject: draft-ietf-mpls-lsp-hierarchy-08
To: [email-masked]
Cc: [email-masked]
From: "Diego Caviglia" <[email-masked]>
Date: Mon, 12 Jan 2004 10:25:10 +0100

Hi all,
              the ID in the subject expired in March 2002 is there any
intention to go on with work on FA?

IMHO that was a good and very usefull work.

Regards.

Diego

------------------------------------------
Diego Caviglia
Marconi - Optical Networks
ASTN/GMPLS - System Design Manager
Via A. Negrone 1/A
16153 Genoa - Italy
Phone: +390106003736

"Timeo Danae et Dona Ferentes"

Delivery-date: Sun, 11 Jan 2004 20:44:55 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: David Charlap <[email-masked]>, IETF CCAMP List <[email-masked]>
Subject: RE: IANA assignments
Date: Sun, 11 Jan 2004 21:39:18 +0100

Maybe... it might be good if people who have used
un-reserved values for implementing ID-level specifications
take a look at draft-narten-iana-experimental-allocations-05.txt
and specifically section 1.1. It is only a page long that section.

It explains why doing such things might be bad.

Thanks,
Bert 

Delivery-date: Fri, 09 Jan 2004 22:08:36 +0000
Date: Fri, 09 Jan 2004 23:08:08 +0100
From: [email-masked]
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: IANA assignments

kireeti, historically value 4 has been considered for the
TSPEC/FLOWSPEC, so this value has been used for our main
implementation (started before the official IANA value
assignment)

note: it would be of interest to reach rapidly agreement
on this since from my side any development initiated/
started after this consider the use the value assigned by
IANA

thanks,
- dimitri.

Kireeti Kompella wrote:
> On Fri, 9 Jan 2004, Kireeti Kompella wrote:
> 
> 
>>Okay, in order to come to some conclusion here, those of you who have
>>implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:
> 
> 
> <WG chair hat OFF>
> 
> For the record, here is the answer from Juniper's implementation:
> 
> 
>>a) do you use the FLOWSPEC C-Type 3 for CoS?
> 
> 
> We parse this, but don't really use it.
> 
> 
>>b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>>   you use for the C-Type?
> 
> 
> Yes. Value 4.
> 
> 
>>c) do you use the TSPEC C-Type 3 for CoS?
> 
> 
> We parse this, but don't really use it.
> 
> 
>>d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>>   you use for the C-Type?
> 
> 
> Yes. Value 4.
> 
> Kireeti.
> -------
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Fri, 09 Jan 2004 20:33:11 +0000
Date: Fri, 09 Jan 2004 15:34:03 -0500
From: David Charlap <[email-masked]>
Organization: Marconi, Vienna VA
To: IETF CCAMP List <[email-masked]>
Subject: RE: IANA assignments

Kireeti Kompella wrote:
> Okay, in order to come to some conclusion here, those of you who have
> implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:

This is for Marconi's RSVP-TE implementation.

> a) do you use the FLOWSPEC C-Type 3 for CoS?

Yes - for interoperability with other vendors that required it in the
recent past and might still require it.

> b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>    you use for the C-Type?

Not at this time.

> c) do you use the TSPEC C-Type 3 for CoS?

Yes - for interoperability.

> d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>    you use for the C-Type?

Not at this time.

> Please send your answers to the mailing list or to the chairs AND ADs
> at the latest by Wed Jan 14, 2004, 5pm PST.

Delivery-date: Fri, 09 Jan 2004 20:26:20 +0000
To: [email-masked]
Subject: Re: IANA assignments 
Date: Fri, 09 Jan 2004 15:25:12 -0500
From: Markus Jork <[email-masked]>

> Okay, in order to come to some conclusion here, those of you who have
> implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:
> 
> a) do you use the FLOWSPEC C-Type 3 for CoS?

Yes. It's implemented but not being used. We already thought about
taking the code out in future releases.

> b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>    you use for the C-Type?

yes, 4

> c) do you use the TSPEC C-Type 3 for CoS?

yes (plus same comment as in a)

> d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>    you use for the C-Type?

yes, 4

Markus

Delivery-date: Fri, 09 Jan 2004 20:00:25 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, [email-masked]
Subject: RE: IANA assignments
Date: Fri, 9 Jan 2004 11:59:28 -0800 

Hi Kireeti,

We assume 3 for CoS (but have not used it so far)
and 4 for SONET/SDH FLOWSPEC/TSPEC.

Cheers,

Lyndon (Ciena)

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Friday, January 09, 2004 10:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: IANA assignments

Okay, in order to come to some conclusion here, those of you who have
implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:

a) do you use the FLOWSPEC C-Type 3 for CoS?
b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
   you use for the C-Type?
c) do you use the TSPEC C-Type 3 for CoS?
d) have you implemented the SONET/SDH TSPEC?  If so, what value did
   you use for the C-Type?

Please send your answers to the mailing list or to the chairs AND ADs
at the latest by Wed Jan 14, 2004, 5pm PST.

Kireeti.
-------

Delivery-date: Fri, 09 Jan 2004 19:50:26 +0000
Date: Fri, 9 Jan 2004 11:49:53 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: RE: IANA assignments

On Fri, 9 Jan 2004, Kireeti Kompella wrote:

> Okay, in order to come to some conclusion here, those of you who have
> implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:
...
> Please send your answers to the mailing list or to the chairs AND ADs
> at the latest by Wed Jan 14, 2004, 5pm PST.

Please don't copy IANA on the replies -- the chairs will summarize the
results and conclusions to IANA.

Thanks,
Kireeti.
-------

Delivery-date: Fri, 09 Jan 2004 19:49:37 +0000
Date: Fri, 9 Jan 2004 11:48:49 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: RE: IANA assignments

On Fri, 9 Jan 2004, Kireeti Kompella wrote:

> Okay, in order to come to some conclusion here, those of you who have
> implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:

<WG chair hat OFF>

For the record, here is the answer from Juniper's implementation:

> a) do you use the FLOWSPEC C-Type 3 for CoS?

We parse this, but don't really use it.

> b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>    you use for the C-Type?

Yes. Value 4.

> c) do you use the TSPEC C-Type 3 for CoS?

We parse this, but don't really use it.

> d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>    you use for the C-Type?

Yes. Value 4.

Kireeti.
-------

Delivery-date: Fri, 09 Jan 2004 19:37:34 +0000
Date: Fri, 09 Jan 2004 20:37:18 +0100
From: [email-masked]
To: rick king <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt

thanks, i encourage the ccamp community to share any
feedback they think relevant to make progress with
this wg i-d and reach consensus toward a second rev.
of this document (that i hope will be ready for last
call, as expected)

thanks,
- dimitri.

rick king wrote:
> I think it's better now. Thank you for your kindly clarifying.
> 
> Rick
> 
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 09, 2004 7:34 AM
> To: rick king
> Cc: [email-masked]
> Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
> 
> 
> the RA represents a partition of the data plane and is used as the 
> representation of the data plane within the control plane, in the
> next revision will include a statement on this since this may be
> where the mis-understanding comes from, wrt to relationship with
> the RC, the text will be clarified from:
> 
>    " - A RA MAY support different routing protocols. There SHOULD NOT be
>        any dependencies on the different routing protocols used.
>      - For a RA, the cluster of RCs is referred to as a routing domain.
>        The routing information exchanged between routing domains (i.e.
>        inter-domain) is independent of both the intra-domain routing
>        protocol and the intra-domain control distribution choice(s), e.g.
>        centralized, fully distributed."
> 
> to:
> 
>     "- For a RA, the cluster of RCs is referred to as a routing (control)
>        domain. The RC MAY support more than one routing protocol. There
>        SHOULD NOT be any dependencies on the different routing protocols
>        used.
>      - The routing information exchanged between routing domains (i.e.
>        inter-domain) is independent of both the intra-domain routing
>        protocol and the intra-domain control distribution choice(s), e.g.
>        centralized, fully distributed."
> 
> well hope this clarifies,
> - dimitri.
> 
> rick king wrote:
> 
> 
>>Then what's relationship between a RA and a routing control domain?
>>
>>thanks
>>
>>Rick
>>
>>From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
>>Sent: Wednesday, January 07, 2004 6:57 AM
>>To: rick king
>>Cc: [email-masked]
>>Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
>>
>>
>>hi, thanks for commenting, see in-line:
>>
>>rick king wrote:
>>
>>
>>
>>>Some comments. Section 3.   ......The  ASON model allows for the protocols
>>>used within different control domains to be different; and for the protocol
>>>used between control domains to be different than the protocols used within
>>>control domains. ......
>>>
>>>The routing requirements contained in this draft apply to protocols used
>>>between control domains(E-NNI routing) or protocols used within control
>>>domains(I-NNI routing) or both?
>>
>>
>>-> both
>>
>>
>>
>>>...... - For a RA, the cluster of RCs is referred to as a routing
>>>domain......
>>>
>>>Does this means that RA=routing domain? Maybe routing control domain is more
>>>align with G.7715.
>>
>>
>>-> yes, it is "routing (control) domain", we will clarify in the
>>    next version
>>
>>
>>
>>>Section 4.2.1    ......   - The second approach places the Level N routing
>>>function on a separate system from the Level N+1 routing function. In this 
>>>case, a communication interface must be used between the systems containing
>>>the routing functions for different levels. This communication interface and
>>>mechanisms are outside the scope of this document. .......
>>>
>>>Is it possible that the Level N routing function and  the Level N+1 routing
>>>function are from different vendors? If the answer is yes, then I think the
>>>communication interface and mechanisms should be defined. Otherwise how can
>>>you achieve inter-operate?
>>
>>
>>-> it is expected to cover multi-vendor case (note that the other
>>    alternative is single vendor only) so that this "communication
>>    interface" is expected to be defined but it is not within the
>>    scope of this document, what's within the scope is the routing
>>    information exchanged (ie ways to achieve the communication
>>    interface between these systems is not)
>>
>>thanks,
>>- dimitri.
>>
>>
>>
>>>Thank you.
>>>
>>>rick
>>>
>>>-----Original Message----- From: [email-masked]
>>>[mailto:[email-masked]]On Behalf Of
>>>[email-masked] Sent: Tuesday, December 30, 2003 5:19 AM To:
>>>[email-masked] Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
>>>
>>>
>>>all,
>>>
>>>the following version of the "ASON routing requirements" document completes
>>>the template proposed in the v00.txt:
>>>
>>><http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt>
>>>
>>>
>>>please provide any comment you think relevant in order to progress this wg
>>>i-d
>>>
>>>thanks, - dimitri.
>>>
>>
>>
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Fri, 09 Jan 2004 18:35:56 +0000
Date: Fri, 9 Jan 2004 10:34:16 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: RE: IANA assignments

Okay, in order to come to some conclusion here, those of you who have
implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:

a) do you use the FLOWSPEC C-Type 3 for CoS?
b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
   you use for the C-Type?
c) do you use the TSPEC C-Type 3 for CoS?
d) have you implemented the SONET/SDH TSPEC?  If so, what value did
   you use for the C-Type?

Please send your answers to the mailing list or to the chairs AND ADs
at the latest by Wed Jan 14, 2004, 5pm PST.

Kireeti.
-------

Delivery-date: Fri, 09 Jan 2004 04:56:37 +0000
From: "rick king" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
Date: Fri, 9 Jan 2004 12:53:23 +0800

Delivery-date: Thu, 08 Jan 2004 23:33:53 +0000
Date: Fri, 09 Jan 2004 00:33:30 +0100
From: [email-masked]
To: rick king <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt

the RA represents a partition of the data plane and is used as the 
representation of the data plane within the control plane, in the
next revision will include a statement on this since this may be
where the mis-understanding comes from, wrt to relationship with
the RC, the text will be clarified from:

   " - A RA MAY support different routing protocols. There SHOULD NOT be
       any dependencies on the different routing protocols used.
     - For a RA, the cluster of RCs is referred to as a routing domain.
       The routing information exchanged between routing domains (i.e.
       inter-domain) is independent of both the intra-domain routing
       protocol and the intra-domain control distribution choice(s), e.g.
       centralized, fully distributed."

to:

    "- For a RA, the cluster of RCs is referred to as a routing (control)
       domain. The RC MAY support more than one routing protocol. There
       SHOULD NOT be any dependencies on the different routing protocols
       used.
     - The routing information exchanged between routing domains (i.e.
       inter-domain) is independent of both the intra-domain routing
       protocol and the intra-domain control distribution choice(s), e.g.
       centralized, fully distributed."

well hope this clarifies,
- dimitri.

rick king wrote:

> Then what's relationship between a RA and a routing control domain?
> 
> thanks
> 
> Rick
> 
> From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
> Sent: Wednesday, January 07, 2004 6:57 AM
> To: rick king
> Cc: [email-masked]
> Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
> 
> 
> hi, thanks for commenting, see in-line:
> 
> rick king wrote:
> 
> 
>>Some comments. Section 3.   ......The  ASON model allows for the protocols
>>used within different control domains to be different; and for the protocol
>>used between control domains to be different than the protocols used within
>>control domains. ......
>>
>>The routing requirements contained in this draft apply to protocols used
>>between control domains(E-NNI routing) or protocols used within control
>>domains(I-NNI routing) or both?
> 
> 
> -> both
> 
> 
>>...... - For a RA, the cluster of RCs is referred to as a routing
>>domain......
>>
>>Does this means that RA=routing domain? Maybe routing control domain is more
>>align with G.7715.
> 
> 
> -> yes, it is "routing (control) domain", we will clarify in the
>     next version
> 
> 
>>Section 4.2.1    ......   - The second approach places the Level N routing
>>function on a separate system from the Level N+1 routing function. In this 
>>case, a communication interface must be used between the systems containing
>>the routing functions for different levels. This communication interface and
>>mechanisms are outside the scope of this document. .......
>>
>>Is it possible that the Level N routing function and  the Level N+1 routing
>>function are from different vendors? If the answer is yes, then I think the
>>communication interface and mechanisms should be defined. Otherwise how can
>>you achieve inter-operate?
> 
> 
> -> it is expected to cover multi-vendor case (note that the other
>     alternative is single vendor only) so that this "communication
>     interface" is expected to be defined but it is not within the
>     scope of this document, what's within the scope is the routing
>     information exchanged (ie ways to achieve the communication
>     interface between these systems is not)
> 
> thanks,
> - dimitri.
> 
> 
>>Thank you.
>>
>>rick
>>
>>-----Original Message----- From: [email-masked]
>>[mailto:[email-masked]]On Behalf Of
>>[email-masked] Sent: Tuesday, December 30, 2003 5:19 AM To:
>>[email-masked] Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
>>
>>
>>all,
>>
>>the following version of the "ASON routing requirements" document completes
>>the template proposed in the v00.txt:
>>
>><http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt>
>>
>>
>>please provide any comment you think relevant in order to progress this wg
>>i-d
>>
>>thanks, - dimitri.
>>
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Thu, 08 Jan 2004 16:30:13 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: David Charlap <[email-masked]>, IETF CCAMP List <[email-masked]>, [email-masked]
Subject: RE: IANA assignments
Date: Thu, 8 Jan 2004 17:13:03 +0100 

> [email-masked] wrote:
> > to what *change* do you refer here, when you say
> > 
> > " If not, at least, isn't it a good idea to let the WG know
> > the rational reason behind changing the proposed value in the
> > draft ?"
> > 
> > The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA
> > and value 3 has never been reserved -
> 
> The value 3 was specified for the old RSVP-TE draft.
> 
> Yes, there was no value specified in the GMPLS-SONET/SDH draft.
> 
> So how did IANA assign a value?  And why did they choose to assign a 
> value to this draft, when they aren't assigning values to other 
> important drafts (like DiffServ-TE)?
> 
They do NOT assign a value to just a DRAFT 
They assign a value to a DRAFT AFTER it has been approved by IESG
and put into RFC-Editor and IANA queues for final processing.

That NEVER happend to the old RSVP draft, and so that old draft
NEVER HAD a VALID assignment.

Bert
> -- David

Delivery-date: Thu, 08 Jan 2004 16:21:24 +0000
Date: Thu, 08 Jan 2004 17:21:54 +0100
From: [email-masked]
To: David Charlap <[email-masked]>
Cc: IETF CCAMP List <[email-masked]>, [email-masked]
Subject: Re: IANA assignments

the "draft" is in the RFC Editor queue and blocked due to
a reference to [GMPLS-ARCH] otherwise it should have been
out now with an RFC number.

David Charlap wrote:

> [email-masked] wrote:
> 
>> to what *change* do you refer here, when you say
>>
>> " If not, at least, isn't it a good idea to let the WG know
>> the rational reason behind changing the proposed value in the
>> draft ?"
>>
>> The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA
>> and value 3 has never been reserved -
> 
> 
> The value 3 was specified for the old RSVP-TE draft.
> 
> Yes, there was no value specified in the GMPLS-SONET/SDH draft.
> 
> So how did IANA assign a value?  And why did they choose to assign a 
> value to this draft, when they aren't assigning values to other 
> important drafts (like DiffServ-TE)?
> 
> -- David
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Thu, 08 Jan 2004 16:02:36 +0000
Date: Thu, 08 Jan 2004 11:03:44 -0500
From: David Charlap <[email-masked]>
Organization: Marconi, Vienna VA
To: IETF CCAMP List <[email-masked]>, [email-masked]
Subject: Re: IANA assignments

[email-masked] wrote:
> to what *change* do you refer here, when you say
> 
> " If not, at least, isn't it a good idea to let the WG know
> the rational reason behind changing the proposed value in the
> draft ?"
> 
> The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA
> and value 3 has never been reserved -

The value 3 was specified for the old RSVP-TE draft.

Yes, there was no value specified in the GMPLS-SONET/SDH draft.

So how did IANA assign a value?  And why did they choose to assign a 
value to this draft, when they aren't assigning values to other 
important drafts (like DiffServ-TE)?

-- David

Delivery-date: Thu, 08 Jan 2004 16:02:20 +0000
From: "Naidu, Venkata" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Wijnen, Bert (Bert)'" <[email-masked]>, IETF CCAMP List <[email-masked]>, [email-masked]
Subject: RE: IANA assignments
Date: Thu, 8 Jan 2004 11:00:47 -0500 

Dimitri,

-> to what *change* do you refer here, when you say
-> 
-> " If not, at least, isn't it a good idea to let the WG know
-> the rational reason behind changing the proposed value in the
-> draft ?"
-> 
-> The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA
-> and value 3 has never been reserved -

  I am referring to old expired long lived RSVP-TE drafts which
  used C-Type 3 and we all implemented and shipped with 3.
  When we decide to remove C-Type, isn't it good to reserve
  at the change/deprecating time ?
  (draft-ietf-mpls-rsvp-lsp-tunnel-07.txt was published in Aug 2000 
  and draft-ietf-mpls-rsvp-lsp-tunnel-08.txt was published in 
  Feb 2001)

  All I am saying is, IANA can have a guideline for long lived
  drafts, such as:
  
     If there is a shipped implementation with an old deprecated
     value, that value MUST be reserved to prevent future misuse.
     It MUST be noted in the subsequent drafts and final RFC.

Venkata.

Delivery-date: Thu, 08 Jan 2004 15:35:41 +0000
Date: Thu, 08 Jan 2004 16:36:00 +0100
From: [email-masked]
To: "Naidu, Venkata" <[email-masked]>
Cc: "'Wijnen, Bert (Bert)'" <[email-masked]>, IETF CCAMP List <[email-masked]>, [email-masked]
Subject: Re: IANA assignments

to what *change* do you refer here, when you say

" If not, at least, isn't it a good idea to let the WG know
the rational reason behind changing the proposed value in the
draft ?"

The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA
and value 3 has never been reserved -

Naidu, Venkata wrote:

> Bert,
> 
> -> NOPE, cause it would not have been assigned based on the fact that
> -> it is in some ID.
> -> 
> -> > IMO this is an IANA process issue, but we've been here before 
> -> > (at least some of us), and never really resolved anything.
> -> > (A simple solution would be to reserve values for long lived drafts
> -> > and formally assign on RFC publication or return the values if/when
> -> > the draft dies.)
> -> >
> -> NOPE. The simple solution is that you request a value in 
> -> experimental 
> -> space while the ID is progressing and being discussed. Only at final
> -> ID approval and RFC-publication will a value in the STDS track space
> -> be assigned.
> 
>   Is it possible for IANA to initiate a discussion in the mailing-list
>   before publishing a value, at least, for long lived drafts ? So that
>   we come to a consensus before assigning a value. If not, at least,
>   isn't it a good idea to let the WG know the rational reason behind 
>   changing the proposed value in the draft ?
> 
> Venkata.
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Thu, 08 Jan 2004 15:28:11 +0000
From: "Naidu, Venkata" <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, IETF CCAMP List <[email-masked]>
Cc: [email-masked]
Subject: RE: IANA assignments
Date: Thu, 8 Jan 2004 10:27:01 -0500 

Bert,

-> NOPE, cause it would not have been assigned based on the fact that
-> it is in some ID.
-> 
-> > IMO this is an IANA process issue, but we've been here before 
-> > (at least some of us), and never really resolved anything.
-> > (A simple solution would be to reserve values for long lived drafts
-> > and formally assign on RFC publication or return the values if/when
-> > the draft dies.)
-> >
-> NOPE. The simple solution is that you request a value in 
-> experimental 
-> space while the ID is progressing and being discussed. Only at final
-> ID approval and RFC-publication will a value in the STDS track space
-> be assigned.

  Is it possible for IANA to initiate a discussion in the mailing-list
  before publishing a value, at least, for long lived drafts ? So that
  we come to a consensus before assigning a value. If not, at least,
  isn't it a good idea to let the WG know the rational reason behind 
  changing the proposed value in the draft ?

Venkata.

Delivery-date: Thu, 08 Jan 2004 15:17:04 +0000
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: Lou Berger <[email-masked]>, David Charlap <[email-masked]>, IETF CCAMP List <[email-masked]>, [email-masked]
Subject: Re: IANA assignments 
Reply-To: [email-masked]
Date: Thu, 08 Jan 2004 10:15:26 -0500
From: Eric Rosen <[email-masked]>

Bert> The simple solution is that  you request a value in experimental space
Bert> while  the ID is  progressing and  being discussed.  Only at  final ID
Bert> approval and RFC-publication  will a value in the  STDS track space be
Bert> assigned. 

This will result in a situation  where the value from the experimental space
becomes the de facto standard.  That seems a bit silly. 

Delivery-date: Thu, 08 Jan 2004 13:44:33 +0000
Date: Thu, 08 Jan 2004 08:42:49 -0500
To: "Wijnen, Bert (Bert)" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: IANA assignments
Cc: "David Charlap" <[email-masked]>, "IETF CCAMP List" <[email-masked]>, <[email-masked]>, [email-masked]

humm, I think we're debating two points.  One we agree on the other I'm not 
sure about.

Point 1: (re)assignment of values removed from or used in dead drafts.

I'm all for this and agree that these values should be reused.

Point 2: temporary assignment of *real* values for long lived drafts.

I think we disagree here, but am not sure.  There needs to be a way to 
tentatively assign values to ensure interoperable implementations of 
drafts.  Sure when the draft doesn't make it to RFC, point 1 applies and 
the values are free for reuse.

As there is no IANA process that supports this, the implementation 
community resorts to agreeing on values.   Changing these values at RFC 
publication time serves no purpose other than disrupting the vendor and 
service provider communities.

In this case, the draft has been stable for 2+ years.  There have been 
*many* implementations, many interop tests, and even deployments.  There 
are also derivative works (OIF and ITU).  All use the same value here.  It 
serves no one in the community to change the value at this time.   All it 
does is destabilize an otherwise stable technology.

In short, IANA should formally assign the values that have been used for 
the past few years.

I would love for IANA/IESG to come up with a formal procedure to deal with 
this real interoperability issue.

Lou

At 06:43 AM 1/8/2004, Wijnen, Bert (Bert) wrote:

> > Bert,
> >          Got to say I agree with David on this.  There is a
> > long standing issue with IANA assignments for long lived drafts.
> > We hit this with MPLS, GMPLS and now this document.
> >
> > The way this was resolved in the past was to make a formal request to IANA
> > that included specific values and then for implementations to use these
> > values until the formal assignment was made.
>
>NOPE,. NOPE and NOPE. I (and IANA, and our IANA rules/guidelines) are
>OK with a WG asking for a specific value (in a ID), but that does NOT
>mean that early implementors can or should use that value.
>Because it CAN and WILL be taken away for otehr assignments when the
>ID does not make it to RFC.
>
> > I think that the request for assignment of a specific value (3) got
> > dropped in this case.
> > If that had been made, all would be good.
> >
>NOPE, cause it would not have been assigned based on the fact that
>it is in some ID.
>
> > IMO this is an IANA process issue, but we've been here before
> > (at least some of us), and never really resolved anything.
> > (A simple solution would be to reserve values for long lived drafts
> > and formally assign on RFC publication or return the values if/when
> > the draft dies.)
> >
>NOPE. The simple solution is that you request a value in experimental
>space while the ID is progressing and being discussed. Only at final
>ID approval and RFC-publication will a value in the STDS track space
>be assigned.
>
>Bert
> > Lou
> >
> > > > From: David Charlap
> [<<mailto:[email-masked]>mailto:[email-masked]>mailto:[email-masked]] 
>
> > > > Sent: dinsdag 6 januari 2004 18:34
> > > > To: IETF CCAMP List
> > > > Subject: IANA assignments
> > > >
> > > >
> > > > Today, I was going through the IANA assignements for RSVP
> > > >
> > >
> > 
> (<<http://www.iana.org/assignments/rsvp-parameters>http://www.iana.org/assignments/rsvp-parameters>http://www.i 
>
>ana.org/assignments/rsvp-parameters)
> > and noticed
> > > what may be a problem.
> > >
> > > The SONET/SDH FLOWSPEC C-Type
> > > (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt)
> > > is assigned the value 3.
> > >

Delivery-date: Thu, 08 Jan 2004 11:45:28 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Lou Berger <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: David Charlap <[email-masked]>, IETF CCAMP List <[email-masked]>, [email-masked]
Subject: RE: IANA assignments
Date: Thu, 8 Jan 2004 12:43:26 +0100 

> Bert,
>          Got to say I agree with David on this.  There is a 
> long standing issue with IANA assignments for long lived drafts.
> We hit this with MPLS, GMPLS and now this document.
> 
> The way this was resolved in the past was to make a formal request to IANA 
> that included specific values and then for implementations to use these 
> values until the formal assignment was made. 

NOPE,. NOPE and NOPE. I (and IANA, and our IANA rules/guidelines) are
OK with a WG asking for a specific value (in a ID), but that does NOT
mean that early implementors can or should use that value. 
Because it CAN and WILL be taken away for otehr assignments when the
ID does not make it to RFC.

> I think that the request for assignment of a specific value (3) got
> dropped in this case.  
> If that had been made, all would be good.
> 
NOPE, cause it would not have been assigned based on the fact that
it is in some ID.

> IMO this is an IANA process issue, but we've been here before 
> (at least some of us), and never really resolved anything.
> (A simple solution would be to reserve values for long lived drafts
> and formally assign on RFC publication or return the values if/when
> the draft dies.)
>
NOPE. The simple solution is that you request a value in experimental 
space while the ID is progressing and being discussed. Only at final
ID approval and RFC-publication will a value in the STDS track space
be assigned.

Bert 
> > > From: David Charlap 
> > [<mailto:[email-masked]>mailto:[email-masked]]
> > > Sent: dinsdag 6 januari 2004 18:34
> > > To: IETF CCAMP List
> > > Subject: IANA assignments
> > >
> > >
> > > Today, I was going through the IANA assignements for RSVP
> > > 
> > 
> (<http://www.iana.org/assignments/rsvp-parameters>http://www.i
ana.org/assignments/rsvp-parameters) 
> and noticed
> > what may be a problem.
> >
> > The SONET/SDH FLOWSPEC C-Type
> > (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt)
> > is assigned the value 3.
> >

Delivery-date: Thu, 08 Jan 2004 00:37:53 +0000
Date: Wed, 07 Jan 2004 19:35:02 -0500
To: "Wijnen, Bert (Bert)" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: IANA assignments
Cc: "David Charlap" <[email-masked]>, "IETF CCAMP List" <[email-masked]>, [email-masked]

Bert,
         Got to say I agree with David on this.  There is a long standing 
issue with IANA assignments for long lived drafts.  We hit this with MPLS, 
GMPLS and now this document.

The way this was resolved in the past was to make a formal request to IANA 
that included specific values and then for implementations to use these 
values until the formal assignment was made.  I think that the request for 
assignment of a specific value (3) got dropped in this case.  If that had 
been made, all would be good.

IMO this is an IANA process issue, but we've been here before (at least 
some of us), and never really resolved anything.  (A simple solution would 
be to reserve values for long lived drafts and formally assign on RFC 
publication or return the values if/when the draft dies.)

Lou

> > From: David Charlap 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: dinsdag 6 januari 2004 18:34
> > To: IETF CCAMP List
> > Subject: IANA assignments
> >
> >
> > Today, I was going through the IANA assignements for RSVP
> > 
> (<http://www.iana.org/assignments/rsvp-parameters>http://www.iana.org/assignments/rsvp-parameters) 
> and noticed
> > what may be a problem.
> >
> > The SONET/SDH FLOWSPEC C-Type
> > (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt)
> > is assigned the value 3.
> >

Delivery-date: Wed, 07 Jan 2004 17:29:15 +0000
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: [email-masked]
Subject: FW: ITU-T Q14/15, and Joint Q14/15, Q12/4, Q14/4 Rapporteur Grp.  Mtgs., 16-20 Feb. 2004, Chicago, USA
Date: Wed, 7 Jan 2004 12:25:58 -0500 

This is a re-send. It bounced on the ccamp list.

> From: 	Lam, Hing-Kam (Kam)  
> Sent:	Wednesday, January 07, 2004 9:53 AM
> To:	[email-masked]'; [email-masked]'; [email-masked]'
> Cc:	[email-masked]'; [email-masked]'; 'Kireeti Kompella'; [email-masked]'; 'Alex Zinin'; 'Bill Fenner'; [email-masked]'; [email-masked]'
> Subject:	ITU-T Q14/15, and Joint Q14/15, Q12/4, Q14/4 Rapporteur Grp. Mtgs., 16-20 Feb. 2004, Chicago, USA
> 
> Dear all,
> 
> Based on the information available at this time, i.e. number of expected participants (>20), the topics for discussion, and number of expected contributions (>15), the SG15 management team has authorized Q14/15 to hold the Q14/15, and the Joint Q14/15,  Q12/4, Q14/4 Rapporteur Group meetings as planned (16-20 February 2004, Chicago, Ill., USA).
> Note that the Joint Q14/15, Q12/4, Q14/4 Rapporteur Grp. Meeting will occur on the second part of the week from Wednesday to Friday (i.e., 18-20 Feb. 2004). 
> 
> I have created a directory in the ITU-T informal FTP site for contributons and logistic information
> http://ties.itu.int/u/tsg15/sg15/wp3/q14/0402/
> 
> Deadline for contribution submission is noon (U.S. EST) 9th February 2004.
> 
> If you plan to provide contributions, please send me the title as soon as possible so that I can assign Working Document (WD) numbers. Please upload your contributions BY Noon (U.S. EST) Monday 9th February 2004 to the above TIES ftp directory with the file name wdxx_company-name_short-title.doc, where xx is the WD number. Please include the leading 0 in the WD number and use all lower case and _ for spaces. After uploading, please send me a note so that I can update the document list. If you want me to upload the contributions for you, email me the file.
> 
> As the IETF experts have been invited to attend this interim meeting, 
> I have also created a directory in the ITU-T public site at
> ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/wp3/q14/0402 for them to access the contributions and logistic information without the need of an ITU-T TIES account. I will try to synchronize the information in this public directory with the TIES directory as often as possible.
> 
> Regards,
> Kam Lam
> ITU-T Q14/15 Rapporteur
> 1-732-949-8338
> [email-masked]
> 

Delivery-date: Wed, 07 Jan 2004 06:41:46 +0000
From: "rick king" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
Date: Wed, 7 Jan 2004 14:39:33 +0800

Delivery-date: Tue, 06 Jan 2004 22:56:06 +0000
Date: Tue, 06 Jan 2004 23:56:49 +0100
From: [email-masked]
To: rick king <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt

hi, thanks for commenting, see in-line:

rick king wrote:

> Some comments. Section 3.   ......The  ASON model allows for the protocols
> used within different control domains to be different; and for the protocol
> used between control domains to be different than the protocols used within
> control domains. ......
> 
> The routing requirements contained in this draft apply to protocols used
> between control domains(E-NNI routing) or protocols used within control
> domains(I-NNI routing) or both?

-> both

> ...... - For a RA, the cluster of RCs is referred to as a routing
> domain......
> 
> Does this means that RA=routing domain? Maybe routing control domain is more
> align with G.7715.

-> yes, it is "routing (control) domain", we will clarify in the
    next version

> Section 4.2.1    ......   - The second approach places the Level N routing
> function on a separate system from the Level N+1 routing function. In this 
> case, a communication interface must be used between the systems containing
> the routing functions for different levels. This communication interface and
> mechanisms are outside the scope of this document. .......
> 
> Is it possible that the Level N routing function and  the Level N+1 routing
> function are from different vendors? If the answer is yes, then I think the
> communication interface and mechanisms should be defined. Otherwise how can
> you achieve inter-operate?

-> it is expected to cover multi-vendor case (note that the other
    alternative is single vendor only) so that this "communication
    interface" is expected to be defined but it is not within the
    scope of this document, what's within the scope is the routing
    information exchanged (ie ways to achieve the communication
    interface between these systems is not)

thanks,
- dimitri.

> Thank you.
> 
> rick
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked] Sent: Tuesday, December 30, 2003 5:19 AM To:
> [email-masked] Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
> 
> 
> all,
> 
> the following version of the "ASON routing requirements" document completes
> the template proposed in the v00.txt:
> 
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt>
> 
> 
> please provide any comment you think relevant in order to progress this wg
> i-d
> 
> thanks, - dimitri.
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Tue, 06 Jan 2004 22:49:22 +0000
Date: Tue, 30 Dec 2003 18:57:31 -0800 (PST)
From: Jim Boyle <[email-masked]>
To: Jean Philippe Vasseur <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: MPLS Inter-area TE requirement draft

I also encourage the members of CCAMP to review my original draft, at

http://www.ietf.org/internet-drafts/draft-boyle-tewg-interarea-reqts-01.txt

I solicit comments on these 2 inter-area drafts, as well as the TEWG doc
on inter-as requirements be directed to [email-masked]

thanks!

Jim

On Tue, 30 Dec 2003, Jean Philippe Vasseur wrote:

> copying CCAMP for comments.
>
> Thanks.
>
> JP.
>
> >Date: Tue, 30 Dec 2003 15:25:20 -0500
> >To: [email-masked]
> >From: Jean Philippe Vasseur <[email-masked]>
> >Subject: MPLS Inter-area TE requirement draft
> >Cc: [email-masked], Jim Boyle <[email-masked]>, [email-masked],
> >[email-masked], [email-masked], Kenji
> >Kumaki <[email-masked]>, Yuichi Ikejiri <[email-masked]>, Parantap
> >Lahiri <[email-masked]>, [email-masked]
> >
> >Hi,
> >
> >Please find attached a new MPLS Inter-area TE requirement draft, which is
> >truly the collective effort of the SPs on this draft along with comments
> >we received form others. I took the liberty to send the draft to the list
> >since it is still not on the IETF site and Bert mentioned that quick
> >progress should be made on this item.
> >
> >Jim, as already mentioned on the list, we would be happy to work with you
> >on this draft in order to quickly come up with a single draft if you will.
> >
> >Thanks in advance for your comment.
> >
> >JP.
>

Delivery-date: Tue, 06 Jan 2004 22:49:11 +0000
Date: Tue, 30 Dec 2003 00:44:56 -0800 (PST)
From: rick king <[email-masked]>
Subject: RE: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
To: [email-masked]

--0-333418823-1072773896=:70951
Content-Type: text/plain; charset=us-ascii

Some comments.
Section 3.   ......The  ASON model allows for the protocols used within different control
   domains to be different; and for the protocol used between control
   domains to be different than the protocols used within control
   domains. ......
    The routing requirements contained in this draft apply to protocols used between control
   domains(E-NNI routing) or protocols used within control  domains(I-NNI routing) or both?
  ...... - For a RA, the cluster of RCs is referred to as a routing domain......

   Does this means that RA=routing domain? Maybe routing control domain is
   more align with G.7715.
Section 4.2.1    ......   - The second approach places the Level N routing function on a
        separate system from the Level N+1 routing function. In this
        case, a communication interface must be used between the
        systems containing the routing functions for different levels.
        This communication interface and mechanisms are outside the
        scope of this document. .......
  Is it possible that the Level N routing function and  the Level N+1 routing function are
from different vendors? If the answer is yes, then I think the  communication interface and mechanisms should be defined. Otherwise how can you achieve inter-operate?

Thank you.

-rick
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Tuesday, December 30, 2003 5:19 AM
To: [email-masked]
Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt

all,
the following version of the "ASON routing requirements" document
completes the template proposed in the v00.txt:
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt>
please provide any comment you think relevant in order to progress
this wg i-d
thanks,
- dimitri.

---------------------------------
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
--0-333418823-1072773896=:70951
Content-Type: text/html; charset=us-ascii

<DIV>Some comments.<BR>Section 3.&nbsp;&nbsp; ......The&nbsp; ASON model allows for the protocols used within different control<BR>&nbsp;&nbsp; domains to be different; and for the protocol used between control<BR>&nbsp;&nbsp; domains to be different than the protocols used within control<BR>&nbsp;&nbsp; domains. ......</DIV>
<DIV>&nbsp;&nbsp;&nbsp; The routing requirements contained in this draft apply to protocols used between control<BR>&nbsp;&nbsp; domains(E-NNI routing) or protocols used within control&nbsp; domains(I-NNI routing) or both?</DIV>
<DIV>&nbsp; ...... - For a RA, the cluster of RCs is referred to as a routing domain......<BR>&nbsp;&nbsp; <BR>&nbsp;&nbsp; Does this means that RA=routing domain? Maybe routing control domain is<BR>&nbsp;&nbsp; more align with G.7715.</DIV>
<DIV>Section 4.2.1&nbsp;&nbsp;&nbsp; ......&nbsp;&nbsp; - The second approach places the Level N routing function on a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; separate system from the Level N+1 routing function. In this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; case, a communication interface must be used between the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; systems containing the routing functions for different levels.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This communication interface and mechanisms are outside the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; scope of this document. .......</DIV>
<DIV>&nbsp; Is it possible that the Level N routing function and&nbsp; the Level N+1 routing function are <BR>from different vendors? If the answer is yes, then I think the&nbsp; communication interface and mechanisms should be defined. Otherwise how can you achieve inter-operate?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thank you.</DIV>
<DIV>&nbsp;</DIV>
<DIV>-rick</DIV>
<DIV>-----Original Message-----<BR>From: <A href="mailto:[email-masked]">[email-masked]</A> [mailto:[email-masked]]On Behalf Of <A href="mailto:[email-masked]">[email-masked]</A><BR>Sent: Tuesday, December 30, 2003 5:19 AM<BR>To: <A href="mailto:[email-masked]">[email-masked]</A><BR>Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt</DIV>
<DIV><BR>all,</DIV>
<DIV>the following version of the "ASON routing requirements" document<BR>completes the template proposed in the v00.txt:</DIV>
<DIV>&lt;<A href="http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt</A>&gt;</DIV>
<DIV>please provide any comment you think relevant in order to progress<BR>this wg i-d</DIV>
<DIV>thanks,<BR>- dimitri.</DIV>
<DIV>&nbsp;</DIV><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://search.yahoo.com/top2003">Find out what made the Top Yahoo! Searches of 2003
</a>
--0-333418823-1072773896=:70951--

Delivery-date: Tue, 06 Jan 2004 22:23:40 +0000
Date: Tue, 06 Jan 2004 17:23:21 -0500
From: David Charlap <[email-masked]>
Organization: Marconi, Vienna VA
To: IETF CCAMP List <[email-masked]>
Subject: Re: IANA assignments

Wijnen, Bert (Bert) wrote:
> The BAD thing is that someone else (some vendor) has used a value
> from some other draft document... and THAT WAS and IS BAD.
> If you want to use a value, you better MAKE SURE it is a value that
> has been assigned and registered by IANA, that is if it is in IANA
> maintained namespace.

The use of 3 for the CoS object was defined in many revisions of 
RSVP-TE.  Nearly every vendor shipped an implementation at the time.

Even though there are other proper methods for signaling best-effort 
today (the Null-Service IntServ class), I doubt anybody will want to 
remove their old pre-standard code, because they won't want to break 
backward-compatibility with their older system software revisions.

This sort of thing has happened in the past, and IANA usually responded 
by marking the pre-standard value as "Reserved".  For example, RSVP 
message type 14 was the pre-standard value used for Hello messages, and 
is now marked Reserved.

>> I realize that expired drafts aren't supposed to have an impact on these 
>> kinds of decisions, but there are shipping products currently on the 
>> market that still use this C-Type.
> 
> It migth be good to point out which products did this BAD move.
> And which document did they find them in?

Considering that the GMPLS-SONET/SDH draft version 0 was written years 
after RSVP-TE draft 01, where the CoS C-Type was originally defined, and 
after several vendors had already shipped product with it, I think the 
decision should be obvious.

draft-ietf-mpls-rsvp-lsp-tunnel-**.txt is not some fly-by-night 
proposal.  And the C-Type in question (including its value) was in the 
draft for seven revisions (that's 3.5 years).  This isn't something you 
casually ignore.

>> The person responsible for this draft should make sure to choose a 
>> different value before the draft becomes an RFC.
> 
> I am not so sure I agree.
> We should try to not make things break in the market. 
> But at the other hand, if we give into this kind of thing, it seems
> we might also do away with IANA... and that seems not right to me.

Who is "we"?  You sound as if there's a war on or something.

Last I heard, we (meaning all of us) were interested in making our 
routers work.  And you can't do that if someone defines a new standard 
that contradicts current (and popular) implementations.

-- David

Delivery-date: Tue, 06 Jan 2004 21:47:04 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: David Charlap <[email-masked]>, IETF CCAMP List <[email-masked]>
Subject: RE: IANA assignments
Date: Tue, 6 Jan 2004 22:44:52 +0100 

Inline:

> From: David Charlap [mailto:[email-masked]]
> Sent: dinsdag 6 januari 2004 18:34
> To: IETF CCAMP List
> Subject: IANA assignments
> 
> 
> Today, I was going through the IANA assignements for RSVP 
> (http://www.iana.org/assignments/rsvp-parameters) and noticed 
> what may be a problem.
> 
> The SONET/SDH FLOWSPEC C-Type 
> (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt) 
> is assigned the value 3.
> 
Actually, if it is on that IANA web page, as it indeed is, then that
means that IANA has already assigned it. 

The internet draft in fact has: TBA (means To Be Assigned).

> This is bad.  The value 3 was already used in some (now 
> expired) RSVP-TE drafts to represent the class-of-service C-Type.
> 
The BAD thing is that someone else (some vendor) has used a value
from some other draft document... and THAT WAS and IS BAD.
If you want to use a value, you better MAKE SURE it is a value that
has been assigned and registered by IANA, that is if it is in IANA
maintained namespace.

> The same problem exists for the SONET/SDH TSPEC.
> 
SAME answer!

> I realize that expired drafts aren't supposed to have an impact on these 
> kinds of decisions, but there are shipping products currently on the 
> market that still use this C-Type.
> 
It migth be good to point out which products did this BAD move.
And which document did they find them in?

> The person responsible for this draft should make sure to choose a 
> different value before the draft becomes an RFC.
> 
I am not so sure I agree.
We should try to not make things break in the market. 
But at the other hand, if we give into this kind of thing, it seems
we might also do away with IANA... and that seems not right to me.

Bert

> -- David

Delivery-date: Tue, 06 Jan 2004 21:11:07 +0000
Date: Tue, 06 Jan 2004 12:34:01 -0500
From: David Charlap <[email-masked]>
Organization: Marconi, Vienna VA
To: IETF CCAMP List <[email-masked]>
Subject: IANA assignments

Today, I was going through the IANA assignements for RSVP 
(http://www.iana.org/assignments/rsvp-parameters) and noticed what may 
be a problem.

The SONET/SDH FLOWSPEC C-Type (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt) 
is assigned the value 3.

This is bad.  The value 3 was already used in some (now expired) RSVP-TE 
drafts to represent the class-of-service C-Type.

The same problem exists for the SONET/SDH TSPEC.

I realize that expired drafts aren't supposed to have an impact on these 
kinds of decisions, but there are shipping products currently on the 
market that still use this C-Type.

The person responsible for this draft should make sure to choose a 
different value before the draft becomes an RFC.

-- David

Delivery-date: Fri, 02 Jan 2004 21:23:51 +0000
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "'Alex Zinin'" <[email-masked]>, "'Bill Fenner'" <[email-masked]>
Subject: Location Change: ITU-T Q14/15 Interim meeting
Date: Fri, 2 Jan 2004 16:21:32 -0500 

Dear Mr. Kompella and Mr. Farrel,

I was informed by Mr. McDonough of Cisco that the Cisco facility will be closed on February 16. Since we need a full week to get the work done, we have decided to change the location of the meeting to Chicago, USA hosted by Tellabs. The meeting date remain unchange, i.e., February 16 - 20, 2004.

For those ccamp WG experts interested in attending the interim meeting, please let me know by 13 January 2004 and also indicate how many contributions (if any) you plan to submit. The cut-off date for submitting contributions to the meeting is 9 February 2004.

Regards,
Kam Lam
ITU-T Q14/15 Rapporteur
1-732-949-8338

> From: 	Lam, Hing-Kam (Kam)  
> Sent:	Monday, December 08, 2003 3:08 PM
> To:	'Kireeti Kompella'; [email-masked]'
> Cc:	[email-masked]; 'Alex Zinin'; 'Bill Fenner'; 'Scott 
> Bradner'; Wijnen, Bert (Bert)
> Subject:	ITU-T Q14/15 Interim meeting
> 
> Dear Mr. Kompella and Mr. Farrel,
> 
> In the ITU-T Q14/15 to CCAMP WG liaison (7th November 2003) 
> and in the 58th IETF meeting, 
> we invited the participation of the CCAMP WG experts to the 
> upcoming Q14/15 Interim meeting, 
> in the week of 16 February 2004 in North Carolina (or San Jose). 
> 
> Now I have received confirmation from the host that the location
> will be at the Cisco campus in Research Triangle Park 
> in Raleigh, North Carolina, USA. 
> 
> For those ccamp WG experts interested in attending the 
> interim meeting, please reply by 13 January 2004 and
> also indicate how many contributions (if any) you plan to submit.  
> The cut-off date for submitting contributions to the meeting 
> is 9 February 2004.
> 
> The terms of Reference of the Q14/15 Rapporteur meeting are:
> 	-	Continue development of G.fame (Framework for 
> ASON Management)
> 	-	Revision to G.7710, G.784, and G.874
> 	-	Revision to G.7713 and G.7713.x
> 	-	Revision to G.7714 and G.7714.1
> 	-	Continue the specification of G.7716
> 	-	Consideration of protocol-specific link-state 
> routing protocols
> 
> Further information about the meeting, including logistic and 
> travel information, will
> be available later on.
> 
> Regards, 
> Kam Lam (Q14/15 Rapporteur) 
> +1 732 949 8338
>