Subject: RE: Please read and comment on GMPLS P&R DT documents
From: Ron Bonica <[email-masked]>
To: Sudheer Dharanikota <[email-masked]>, CCAMP WG <[email-masked]>
Date: Sun, 31 Mar 2002 17:45:19 -0500

Sudheer,

In Section 4.2.C of the terminology document, could you expand on the
definition of "null traffic"? How is it different from "extra traffic"?

Also, you don't use the term outside of section 4.2.C. Should this be cause
for concern?

                                                Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Sudheer Dharanikota
> Sent: Wednesday, March 13, 2002 12:28 PM
> To: CCAMP WG
> Subject: Please read and comment on GMPLS P&R DT documents
>
>
> Hi Folks:
>
> Please note that the "GMPLS Protection and Restoration
> Design Team"
> has produced the following two documents (1st version)...
>
> Recovery (Protection and Restoration) Terminology for GMPLS
> http://search.ietf.org/internet-drafts/draft-mannie-gmpls-recovery
> -terminology-00.txt
>
> Analysis for GMPLS-based Recovery Mechanisms(including
> Protection and Restoration)
> http://www.cs.odu.edu/~sudheer/draft-design-team-gmpls-recovery-an
> alysis-00.txt
>
> We request you to read and comment on them as quickly as you
> can.
>
> Regards,
>
> GMPLS P&R Design Team
>
>
>

Delivery-date: Fri, 29 Mar 2002 13:18:53 -0800
Date: Fri, 29 Mar 2002 16:17:58 -0500
To: "Zhi-Wei Lin" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Fwd: GMPLS signaling (RSVP) assignment request.
Cc: "Berger, Lou" <[email-masked]>, <[email-masked]>

At 02:53 PM 3/29/2002, Zhi-Wei Lin wrote:

>Hi Lou,
>
>I was looking over the codes you suggested, and saw that there was a
>redundancy: error code/value 24/6 and your suggested 24/13 both provide:
>
>o "Routing problem/Unacceptable label value"

looks like a duplicate, and should be dropped.

>Could you clarify whether 24/13 is for something else (a cut-and-paste
>problem)?

>  Also, for the RRO, type = 3 (label), this is a redefinition of
>the original RRO label type, and not a new type?

Yes, this is in fact just a definition of a bit in the flags field.

Lou

>Thanks
>Zhi
>
>
>Lou Berger wrote:
>
> > FYI
> >
> >> Date: Mon, 11 Mar 2002 18:39:18 -0500
> >> To: [email-masked]
> >> From: Lou Berger <[email-masked]>
> >> Subject: GMPLS signaling (RSVP) assignment request.
> >>
> >> Hello!
> >>
> >> We'd like to request assignment of types defined in
> >> draft-ietf-mpls-generalized-rsvp-te-06.  This draft has
> >> passed WG last call and is on it's way to IESG/IETF last call.
> >> Assignment is needed to ensure interoperability.
> >>
> >> Thank you,
> >> Lou Berger (and co-authors)
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >> RSVP related values defined in draft-ietf-mpls-generalized-rsvp-te-06
> >> with suggested values.
> >>
> >> ---------------------------------------------------------------------
> >> Message Types
> >>
> >> o Notify message (suggested Message type =21)
> >>
> >> ---------------------------------------------------------------------
> >> Class Types
> >>
> >> o RSVP_HOP (Existing C-Num 3)
> >>   - IPv4 IF_ID RSVP_HOP (Suggested C-type =3)
> >>   - IPv6 IF_ID RSVP_HOP (Suggested C-type =4)
> >>
> >> o ERROR_SPEC (Existing C-Num 6)
> >>   - IPv4 IF_ID ERROR_SPEC (Suggested C-type =3)
> >>   - IPv6 IF_ID ERROR_SPEC (Suggested C-type =4)
> >>
> >> o LABEL_REQUEST (Existing Class-Num 19)
> >>   - Generalized_Label_Request (Suggested C-Type =4)
> >>
> >> o RSVP_LABEL (Existing  Class-Num 16)
> >>   - Generalized_Label (Suggested C-Type =2)
> >>   - Waveband_Switching_Label C-Type (Suggested C-Type =3)
> >>
> >> ---------------------------------------------------------------------
> >> New Class-Nums, C-Types inherited from Label object (same as CNum16)
> >>
> >> o RECOVERY_LABEL     Class-Num of form 0bbbbbbb (suggested =34)
> >> o SUGGESTED_LABEL    Class-Num of form 10bbbbbb (suggested =129)
> >> o UPSTREAM_LABEL     Class-Num of form 0bbbbbbb (suggested =35)
> >>
> >> ---------------------------------------------------------------------
> >> New Class-Nums
> >>
> >> o LABEL_SET                     Class-Num of form 0bbbbbbb (suggested
> >> =36)
> >>   - Type 1               (C-Type =1)
> >> o ACCEPTABLE_LABEL_SET          Class-Num of form 10bbbbbb (suggested
> >> =130)
> >>   - Type 1 Acceptable_Label_Set (C-type from label_set cnum)
> >> o NOTIFY_REQUEST                Class-Num of form 11bbbbbb (suggested
> >> =195)
> >>   - IPv4 Notify Request  (C-Type =1)
> >>   - IPv6 Notify Request  (C-Type =2)
> >> o PROTECTION                    Class-Num of form 0bbbbbbb (suggested
> >> =37)
> >>   - Type 1               (C-Type =1)
> >> o ADMIN STATUS                  Class-Num of form 11bbbbbb (suggested
> >> =196)
> >>   - Type 1               (C-Type =1)
> >> o RESTART_CAP                   Class-Num of form 10bbbbbb (suggested
> >> =131)
> >>   - Type 1               (C-Type =1)
> >>
> >> ---------------------------------------------------------------------
> >> ERO/RRO subobject types
> >>
> >> o Label ERO subobject
> >>   Type 3 - Label
> >>
> >> o Label RRO subobject
> >>   Type 3 - Label
> >>
> >> ---------------------------------------------------------------------
> >> Error codes
> >>
> >> o "Routing problem/Label Set"                           (Suggested
> >> value =11)
> >> o "Routing problem/Switching Type"                      (Suggested
> >> value =12)
> >> o "Routing problem/Unacceptable label value"            (Suggested
> >> value =13)
> >> o "Routing problem/Unsupported Encoding"                (Suggested
> >> value =14)
> >> o "Routing problem/Unsupported Link Protection"         (Suggested
> >> value =15)
> >> o "Notify Error/Control Channel Active State"           (Suggested
> >> value =4)
> >> o "Notify Error/Control Channel Degraded State"         (Suggested
> >> value =5)
> >> ---------------------------------------------------------------------
> >>
> >> [related section from draft]
> >> 13. IANA Considerations
> >>
> >>    IANA assigns values to RSVP protocol parameters.  Within the current
> >>    document multiple objects are defined.  Each of these objects contain
> >>    C-Types.  This section defines the rules for the assignment of the
> >>    related C-Type values.  This section uses the terminology of BCP 26
> >>    "Guidelines for Writing an IANA Considerations Section in RFCs"
> >>    [BCP26].
> >>
> >>    As per [RFC2205], C-Type is an 8-bit number that identifies the
> >>    function of an object.  There are no range restrictions.  All
> >>    possible values except zero are available for assignment.
> >>
> >>    The assignment of C-Type values of the objects defined in this
> >>    document fall into three categories.  The first category inherit C-
> >>    Types from the Label object, i.e., object class number 16 [RSVP-TE].
> >>    IANA is requested to institute a policy whereby all C-Type values
> >>    assign for the Label object are also assigned for the following
> >>    objects:
> >>       o Suggested_Label    (Class-Num TBA)
> >>       o Upstream_Label     (Class-Num TBA)
> >>       o Recovery_Label     (Class-Num TBA)
> >>
> >>    The second category of objects follow independent policies.
> >>    Specifically, following the policies outlined in [BCP26], C-Type
> >>    values in the range 0x00 - 0x3F are allocated through an IETF
> >>    Consensus action, values in the range 00x40 - 0x5F are allocated as
> >>    First Come First Served, and values in the range 0x60 - 0x7F are
> >>    reserved for Private Use.  This policy applies to the following
> >>    objects.
> >>       o Label_Set          (Class-Num TBA)
> >>       o Notify_Request     (Class-Num TBA)
> >>       o Protection         (Class-Num TBA)
> >>       o Admin Status       (Class-Num TBA)
> >>       o Restart_Cap        (Class-Num TBA)
> >>
> >>
> >>
> >> Berger, et. al.                                                [Page 35]
> >> Internet Draft draft-ietf-mpls-generalized-rsvp-te-06.txt  November 2001
> >>
> >>
> >>    The assignment of C-Type values for the remaining object, the
> >>    Acceptable_Label_Set object, follows the assignment of C-Type values
> >>    of the Label_Set object.  IANA is requested to institute a policy
> >>    whereby all C-Type values assigned for the Label_Set object are also
> >>    assigned for the Acceptable_Label_Set object.
> >
> >
> >

Delivery-date: Fri, 29 Mar 2002 11:55:35 -0800
Date: Fri, 29 Mar 2002 14:53:11 -0500
From: Zhi-Wei Lin <[email-masked]>
To: Lou Berger <[email-masked]>
CC: [email-masked]
Subject: Re: Fwd: GMPLS signaling (RSVP) assignment request.

Hi Lou,

I was looking over the codes you suggested, and saw that there was a 
redundancy: error code/value 24/6 and your suggested 24/13 both provide:

o "Routing problem/Unacceptable label value"

Could you clarify whether 24/13 is for something else (a cut-and-paste 
problem)? Also, for the RRO, type = 3 (label), this is a redefinition of 
the original RRO label type, and not a new type?

Thanks
Zhi

Lou Berger wrote:

> FYI
>
>> Date: Mon, 11 Mar 2002 18:39:18 -0500
>> To: [email-masked]
>> From: Lou Berger <[email-masked]>
>> Subject: GMPLS signaling (RSVP) assignment request.
>>
>> Hello!
>>
>> We'd like to request assignment of types defined in
>> draft-ietf-mpls-generalized-rsvp-te-06.  This draft has
>> passed WG last call and is on it's way to IESG/IETF last call.
>> Assignment is needed to ensure interoperability.
>>
>> Thank you,
>> Lou Berger (and co-authors)
>>
>>
>> ---------------------------------------------------------------------
>>
>> RSVP related values defined in draft-ietf-mpls-generalized-rsvp-te-06
>> with suggested values.
>>
>> ---------------------------------------------------------------------
>> Message Types
>>
>> o Notify message (suggested Message type =21)
>>
>> ---------------------------------------------------------------------
>> Class Types
>>
>> o RSVP_HOP (Existing C-Num 3)
>>   - IPv4 IF_ID RSVP_HOP (Suggested C-type =3)
>>   - IPv6 IF_ID RSVP_HOP (Suggested C-type =4)
>>
>> o ERROR_SPEC (Existing C-Num 6)
>>   - IPv4 IF_ID ERROR_SPEC (Suggested C-type =3)
>>   - IPv6 IF_ID ERROR_SPEC (Suggested C-type =4)
>>
>> o LABEL_REQUEST (Existing Class-Num 19)
>>   - Generalized_Label_Request (Suggested C-Type =4)
>>
>> o RSVP_LABEL (Existing  Class-Num 16)
>>   - Generalized_Label (Suggested C-Type =2)
>>   - Waveband_Switching_Label C-Type (Suggested C-Type =3)
>>
>> ---------------------------------------------------------------------
>> New Class-Nums, C-Types inherited from Label object (same as CNum16)
>>
>> o RECOVERY_LABEL     Class-Num of form 0bbbbbbb (suggested =34)
>> o SUGGESTED_LABEL    Class-Num of form 10bbbbbb (suggested =129)
>> o UPSTREAM_LABEL     Class-Num of form 0bbbbbbb (suggested =35)
>>
>> ---------------------------------------------------------------------
>> New Class-Nums
>>
>> o LABEL_SET                     Class-Num of form 0bbbbbbb (suggested 
>> =36)
>>   - Type 1               (C-Type =1)
>> o ACCEPTABLE_LABEL_SET          Class-Num of form 10bbbbbb (suggested 
>> =130)
>>   - Type 1 Acceptable_Label_Set (C-type from label_set cnum)
>> o NOTIFY_REQUEST                Class-Num of form 11bbbbbb (suggested 
>> =195)
>>   - IPv4 Notify Request  (C-Type =1)
>>   - IPv6 Notify Request  (C-Type =2)
>> o PROTECTION                    Class-Num of form 0bbbbbbb (suggested 
>> =37)
>>   - Type 1               (C-Type =1)
>> o ADMIN STATUS                  Class-Num of form 11bbbbbb (suggested 
>> =196)
>>   - Type 1               (C-Type =1)
>> o RESTART_CAP                   Class-Num of form 10bbbbbb (suggested 
>> =131)
>>   - Type 1               (C-Type =1)
>>
>> ---------------------------------------------------------------------
>> ERO/RRO subobject types
>>
>> o Label ERO subobject
>>   Type 3 - Label
>>
>> o Label RRO subobject
>>   Type 3 - Label
>>
>> ---------------------------------------------------------------------
>> Error codes
>>
>> o "Routing problem/Label Set"                           (Suggested 
>> value =11)
>> o "Routing problem/Switching Type"                      (Suggested 
>> value =12)
>> o "Routing problem/Unacceptable label value"            (Suggested 
>> value =13)
>> o "Routing problem/Unsupported Encoding"                (Suggested 
>> value =14)
>> o "Routing problem/Unsupported Link Protection"         (Suggested 
>> value =15)
>> o "Notify Error/Control Channel Active State"           (Suggested 
>> value =4)
>> o "Notify Error/Control Channel Degraded State"         (Suggested 
>> value =5)
>> ---------------------------------------------------------------------
>>
>> [related section from draft]
>> 13. IANA Considerations
>>
>>    IANA assigns values to RSVP protocol parameters.  Within the current
>>    document multiple objects are defined.  Each of these objects contain
>>    C-Types.  This section defines the rules for the assignment of the
>>    related C-Type values.  This section uses the terminology of BCP 26
>>    "Guidelines for Writing an IANA Considerations Section in RFCs"
>>    [BCP26].
>>
>>    As per [RFC2205], C-Type is an 8-bit number that identifies the
>>    function of an object.  There are no range restrictions.  All
>>    possible values except zero are available for assignment.
>>
>>    The assignment of C-Type values of the objects defined in this
>>    document fall into three categories.  The first category inherit C-
>>    Types from the Label object, i.e., object class number 16 [RSVP-TE].
>>    IANA is requested to institute a policy whereby all C-Type values
>>    assign for the Label object are also assigned for the following
>>    objects:
>>       o Suggested_Label    (Class-Num TBA)
>>       o Upstream_Label     (Class-Num TBA)
>>       o Recovery_Label     (Class-Num TBA)
>>
>>    The second category of objects follow independent policies.
>>    Specifically, following the policies outlined in [BCP26], C-Type
>>    values in the range 0x00 - 0x3F are allocated through an IETF
>>    Consensus action, values in the range 00x40 - 0x5F are allocated as
>>    First Come First Served, and values in the range 0x60 - 0x7F are
>>    reserved for Private Use.  This policy applies to the following
>>    objects.
>>       o Label_Set          (Class-Num TBA)
>>       o Notify_Request     (Class-Num TBA)
>>       o Protection         (Class-Num TBA)
>>       o Admin Status       (Class-Num TBA)
>>       o Restart_Cap        (Class-Num TBA)
>>
>>
>>
>> Berger, et. al.                                                [Page 35]
>> Internet Draft draft-ietf-mpls-generalized-rsvp-te-06.txt  November 2001
>>
>>
>>    The assignment of C-Type values for the remaining object, the
>>    Acceptable_Label_Set object, follows the assignment of C-Type values
>>    of the Label_Set object.  IANA is requested to institute a policy
>>    whereby all C-Type values assigned for the Label_Set object are also
>>    assigned for the Acceptable_Label_Set object.
>
>
>

Delivery-date: Fri, 29 Mar 2002 07:55:28 -0800
From: "Soo-Hyun Choi" <[email-masked]>
To: "Jonathan Lang" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Jonathan Lang" <[email-masked]>
Subject: Re:  LMP over UDP
Date: Sat, 30 Mar 2002 01:02:28 -0800

Hi, Jonathan,

I don't understand why the IESG would reject the LMP over raw IP unless you
have a very very compelling reason.
Could you clarify more on this?

Regards,
Soo-Hyun Choi

----- Original Message -----
From: "Jonathan Lang" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; "Jonathan Lang" <[email-masked]>
Sent: Friday, March 22, 2002 10:51 AM
Subject: LMP over UDP

> All,
>
> I had a discussion with Scott in Minnesota about progressing LMP through
the
> IESG.  He had given the LMP draft a "pre-IESG" review (looking for obvious
> rejection material) and realized that it wouldn't fly as LMP over raw IP -
> they're not giving out IP protocol IDs unless you have a very very
> compelling reason.  Instead we will run LMP over UDP, and get a UDP port
for
> LMP from IANA.  Fixing this now will short-circuit an almost certain IESG
> rejection.
>
> Thanks,
> Jonathan
>
>

Delivery-date: Fri, 29 Mar 2002 07:38:51 -0800
From: Irwin Lazar <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: about draft-xu-bgp-gmpls-01
Date: Fri, 29 Mar 2002 08:33:59 -0700

Try:
http://search.ietf.org/internet-drafts/draft-xu-bgp-gmpls-01.txt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 29, 2002 12:19 AM
To: [email-masked]
Subject: about draft-xu-bgp-gmpls-01

hi, all,

where can I find the latest version of this draft ? or

which working group is discussing it ?

thanks

Delivery-date: Fri, 29 Mar 2002 04:03:52 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-signaling-survey-00.txt
Date: Fri, 29 Mar 2002 07:02:16 -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 Signaling - Implementation Survey
	Author(s)	: L. Berger, Y. Rekhter
	Filename	: draft-ietf-ccamp-gmpls-signaling-survey-00.txt
	Pages		: 63
	Date		: 28-Mar-02
	
This document provides a survey of GMPLS signaling implementations.
The primary focus of this survey are the signaling protocol
mechanisms specified in [GMPLS-SIG], [GMPLS-RSVP], [GMPLS-LDP] and
[GMPLS-SONET].  Other specifications and documents are listed if
included in the submitted form.  The survey form and latest version
of this document are available from http://www.labn.net/gmpls-survey.

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 28 Mar 2002 21:22:03 -0800
Subject: about draft-xu-bgp-gmpls-01
To: [email-masked]
From: [email-masked]
Date: Fri, 29 Mar 2002 13:18:58 +0800

hi, all,

where can I find the latest version of this draft ? or

which working group is discussing it ?

thanks

Delivery-date: Thu, 28 Mar 2002 04:10:48 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-05.txt
Date: Thu, 28 Mar 2002 07:06:32 -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		: OSPF Extensions in Support of Generalized MPLS
	Author(s)	: K. Kompella et al.
	Filename	: draft-ietf-ccamp-ospf-gmpls-extensions-05.txt
	Pages		: 10
	Date		: 27-Mar-02
	
This document specifies encoding of extensions to the OSPF routing
protocol in support of Generalized Multi-Protocol Label Switching
(GMPLS).  The description of the extensions is specified in [GMPLS-
ROUTING].

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 28 Mar 2002 04:10:45 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-03.txt
Date: Thu, 28 Mar 2002 07:06:45 -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		: Routing Extensions in Support of Generalized MPLS
	Author(s)	: K. Kompella et al.
	Filename	: draft-ietf-ccamp-gmpls-routing-03.txt
	Pages		: 24
	Date		: 27-Mar-02
	
This document specifies routing extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS).

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-routing-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: Mon, 25 Mar 2002 17:46:41 -0800
From: John Drake <[email-masked]>
To: 'Randy Bush' <[email-masked]>, Yakov Rekhter <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: Generalized Signaling documents 
Date: Mon, 25 Mar 2002 17:45:52 -0800

Randy,

Incisive and well-reasoned, and stylistically flawless.

Thanks,

John

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: Monday, March 25, 2002 12:26 PM
To: Yakov Rekhter
Cc: Wijnen, Bert (Bert); ccamp-wg
Subject: Re: Generalized Signaling documents 

>> but it will be so now.  no exact number, but no longs lists.
> Does that represent your own position, or the position of the
> IESG as the whole ?

the iesg, the rfc editor, the teacher, and my mommy.  more details
forthcoming.

can we get to work now?

randy

Delivery-date: Mon, 25 Mar 2002 16:13:01 -0800
From: Debanjan Saha <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Eric Gray <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: Generalized Signaling documents
Date: Mon, 25 Mar 2002 18:55:49 -0500

Vishal,

Echoing on what you said, the following is quoted from
http://www.rfc-editor.org/policy.html, the policy
document people keep referring to. 

Two reasons for avoiding long lists are mentioned. 
The first one is a formatting issue and does not 
apply to the GMPLS signaling draft. Formatting looks 
fine to me. In any case, it seems pretty frivolous.

The second reason also does not apply to this draft
since there are more authors than companies listed.
Clearly authors were not added for corporate name
dropping. This policy also seems very arbitrary and
goes much beyond editorial responsibility.

Just curious, who comes up with these policies?

"Objections to huge author lists are both practical and 
ideological. The practical issues have to do with the 
long-existing RFC formatting conventions that do not 
comfortably handle large author lists." 

"Ideological objections stem from the Internet community's 
tradition of individual rather than corporate action and 
responsibility. Some might see a list of 17 authors on one 
RFC as motivated by a desire for corporate name-dropping, 
which would be inappropriate in the IETF/RFC context. If 
there is a desire to demonstrate how many companies are 
interested in this spec, a simple acknowledgment section 
can accomplish the same thing, without Author Overload."

Debanjan

-----Original Message-----
From: Vishal Sharma [mailto:[email-masked]]
Sent: Monday, March 25, 2002 5:16 PM
To: Eric Gray; Randy Bush
Cc: Yakov Rekhter; Wijnen, Bert (Bert); ccamp-wg
Subject: RE: Generalized Signaling documents

Eric,

Thanks for your comments.

I think while general guidelines are good, it is necessary to
also consider the nature and scope of work done on 
individual work items of a WG's charter.

In each effort, there is a core group of people who take on
the mantle of initiating ideas (often being the ones making
the initial proposals) and progressing them through
the development and documentation process on their way to
becoming RFCs.  That core group, which is typically small, 
sometimes may be a little larger given the specific subject 
at hand.

In the case of the GMPLS signaling documents that core group
has remained pretty consistent right from the initial days of
this work (starting shortly before the Adelaide IETF in March
2000). Also, this core group is not unreasonably large.
As someone already mentioned, GMPLS is a complex subject, requiring 
expertise from several areas, which is what the core group has 
brought to the document.

Of course, many other people have contributed to shaping the
document with comments, ideas, and suggestions and they should
be acknowledged in the acknowledgement section of the document.

There were also a couple of emails that pointed out that the
signaling documents do not go against any of the RFC Editor's
guidelines, as currently laid out. Formatting is not a problem
(the document is very reasonably formatted), and certainly there
is no intent of name dropping for companies (the list has remained
fairly stable for quite a while, and represents the _individuals_
who contributed to the work). If the intent was to name drop, the
list would have looked a lot different, with many more names
perhaps.

So, in this instance, I do not see any justification for
arbitrarily coming down on the authors, especially after practically
all of the work has been done.

Given some other RFC examples that people have pointed to, and
the inter-disciplinary nature of the GMPLS work, I cannot see
a problem keeping the documents just as they are (and have been
for the better part of a year).

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Eric Gray
> Sent: Monday, March 25, 2002 4:02 PM
> To: Randy Bush
> Cc: Yakov Rekhter; Wijnen, Bert (Bert); ccamp-wg
> Subject: Re: Generalized Signaling documents
> 
> 
> Randy,
> 
>     I see the presentation on manners really took hold.
> 
>     You don't want to be so terse that the content of your
> many replies nears zero - considering each reply on its
> own - and I'm not sure that being so terse is consistent
> with the goal of getting back to work.
> 
>     As I understand it, the guidelines from the RFC editor
> are that people who made substantial contributions to the
> work are 'authors' and should be listed as such.  From there,
> the progression might reasonably be to list a small set of
> people (typically one) as the editor and acknowledge each
> of the contributing authors in an appropriate section.
> 
>     If authors intend to indicate widespread support for the
> ideas of an intended RFC, maybe it makes sense to add a
> section - or paragraph - that spells this out.
> 
>     The intention - IMHO - is that the list of authors should
> be consistent with the actual work and this implies some
> guidelines of 'reasonableness'.  Any such guidelines would
> naturally need to be flexible as such things tend to evolve.
> 
>     The RFC editor needs to put a stake in the ground in order
> to maintain credibility for the RFC publishing process.  The
> people contributing to the RFC process need to be sensitive
> to this if they would like to have this process continue to be
> as respected as it currently is.
> 
> You wrote:
> 
> >>>but it will be so now.  no exact number, but no longs lists.
> >>>
> >>Does that represent your own position, or the position of the
> >>IESG as the whole ?
> >>
> >
> >the iesg, the rfc editor, the teacher, and my mommy.  more details
> >forthcoming.
> >
> >can we get to work now?
> >
> >randy
> >
> 
> 
> -- 
> --
> Eric Gray (mailto:[email-masked])
> http://www.mindspring.com/~ewgray
> 
> 
> 

Delivery-date: Mon, 25 Mar 2002 14:10:25 -0800
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Eric Gray" <[email-masked]>, "Randy Bush" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>, "ccamp-wg" <[email-masked]>
Subject: RE: Generalized Signaling documents
Date: Mon, 25 Mar 2002 17:16:08 -0500

Eric,

Thanks for your comments.

I think while general guidelines are good, it is necessary to
also consider the nature and scope of work done on 
individual work items of a WG's charter.

In each effort, there is a core group of people who take on
the mantle of initiating ideas (often being the ones making
the initial proposals) and progressing them through
the development and documentation process on their way to
becoming RFCs.  That core group, which is typically small, 
sometimes may be a little larger given the specific subject 
at hand.

In the case of the GMPLS signaling documents that core group
has remained pretty consistent right from the initial days of
this work (starting shortly before the Adelaide IETF in March
2000). Also, this core group is not unreasonably large.
As someone already mentioned, GMPLS is a complex subject, requiring 
expertise from several areas, which is what the core group has 
brought to the document.

Of course, many other people have contributed to shaping the
document with comments, ideas, and suggestions and they should
be acknowledged in the acknowledgement section of the document.

There were also a couple of emails that pointed out that the
signaling documents do not go against any of the RFC Editor's
guidelines, as currently laid out. Formatting is not a problem
(the document is very reasonably formatted), and certainly there
is no intent of name dropping for companies (the list has remained
fairly stable for quite a while, and represents the _individuals_
who contributed to the work). If the intent was to name drop, the
list would have looked a lot different, with many more names
perhaps.

So, in this instance, I do not see any justification for
arbitrarily coming down on the authors, especially after practically
all of the work has been done.

Given some other RFC examples that people have pointed to, and
the inter-disciplinary nature of the GMPLS work, I cannot see
a problem keeping the documents just as they are (and have been
for the better part of a year).

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Eric Gray
> Sent: Monday, March 25, 2002 4:02 PM
> To: Randy Bush
> Cc: Yakov Rekhter; Wijnen, Bert (Bert); ccamp-wg
> Subject: Re: Generalized Signaling documents
> 
> 
> Randy,
> 
>     I see the presentation on manners really took hold.
> 
>     You don't want to be so terse that the content of your
> many replies nears zero - considering each reply on its
> own - and I'm not sure that being so terse is consistent
> with the goal of getting back to work.
> 
>     As I understand it, the guidelines from the RFC editor
> are that people who made substantial contributions to the
> work are 'authors' and should be listed as such.  From there,
> the progression might reasonably be to list a small set of
> people (typically one) as the editor and acknowledge each
> of the contributing authors in an appropriate section.
> 
>     If authors intend to indicate widespread support for the
> ideas of an intended RFC, maybe it makes sense to add a
> section - or paragraph - that spells this out.
> 
>     The intention - IMHO - is that the list of authors should
> be consistent with the actual work and this implies some
> guidelines of 'reasonableness'.  Any such guidelines would
> naturally need to be flexible as such things tend to evolve.
> 
>     The RFC editor needs to put a stake in the ground in order
> to maintain credibility for the RFC publishing process.  The
> people contributing to the RFC process need to be sensitive
> to this if they would like to have this process continue to be
> as respected as it currently is.
> 
> You wrote:
> 
> >>>but it will be so now.  no exact number, but no longs lists.
> >>>
> >>Does that represent your own position, or the position of the
> >>IESG as the whole ?
> >>
> >
> >the iesg, the rfc editor, the teacher, and my mommy.  more details
> >forthcoming.
> >
> >can we get to work now?
> >
> >randy
> >
> 
> 
> -- 
> --
> Eric Gray (mailto:[email-masked])
> http://www.mindspring.com/~ewgray
> 
> 
> 

Delivery-date: Mon, 25 Mar 2002 14:01:03 -0800
From: Debanjan Saha <[email-masked]>
To: 'Randy Bush' <[email-masked]>, Yakov Rekhter <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Generalized Signaling documents 
Date: Mon, 25 Mar 2002 16:45:46 -0500

Randy,
I think IETF will be better served if offensive mails
like this one are kept off official mailing lists.

Debanjan

>> but it will be so now.  no exact number, but no longs lists.
> Does that represent your own position, or the position of the
> IESG as the whole ?

the iesg, the rfc editor, the teacher, and my mommy.  more details
forthcoming.

can we get to work now?

randy

Delivery-date: Mon, 25 Mar 2002 13:02:14 -0800
Date: Mon, 25 Mar 2002 16:02:02 -0500
From: Eric Gray <[email-masked]>
To: Randy Bush <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: Re: Generalized Signaling documents

Randy,

    I see the presentation on manners really took hold.

    You don't want to be so terse that the content of your
many replies nears zero - considering each reply on its
own - and I'm not sure that being so terse is consistent
with the goal of getting back to work.

    As I understand it, the guidelines from the RFC editor
are that people who made substantial contributions to the
work are 'authors' and should be listed as such.  From there,
the progression might reasonably be to list a small set of
people (typically one) as the editor and acknowledge each
of the contributing authors in an appropriate section.

    If authors intend to indicate widespread support for the
ideas of an intended RFC, maybe it makes sense to add a
section - or paragraph - that spells this out.

    The intention - IMHO - is that the list of authors should
be consistent with the actual work and this implies some
guidelines of 'reasonableness'.  Any such guidelines would
naturally need to be flexible as such things tend to evolve.

    The RFC editor needs to put a stake in the ground in order
to maintain credibility for the RFC publishing process.  The
people contributing to the RFC process need to be sensitive
to this if they would like to have this process continue to be
as respected as it currently is.

You wrote:

>>>but it will be so now.  no exact number, but no longs lists.
>>>
>>Does that represent your own position, or the position of the
>>IESG as the whole ?
>>
>
>the iesg, the rfc editor, the teacher, and my mommy.  more details
>forthcoming.
>
>can we get to work now?
>
>randy
>

-- 
--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

Delivery-date: Mon, 25 Mar 2002 13:00:27 -0800
Date: Mon, 25 Mar 2002 12:57:03 -0800
From: Sudheer Dharanikota <[email-masked]>
To: Yakov Rekhter <[email-masked]>
CC: Jun Yu <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: FW: path TLV & srlg TLV

>
>
> > (2). If we only advertise Path Information for the FA, then the SRLG
> > information of the FA
> > can be derived, just as you specified in the "LSP Hierarchy" draft, it is
> > "the union of the
> > SRLGs of the underlying TE links that make up the FA-LSP path".
> >
> > On the other hand, if we only advertise SRLG Information for the FA, then
> > the FA-LSP's path
> > information becomes opaque to all the LSRs other than the headend LSR. This
> > makes it difficult
> > for the LSR to make a routing decision with "Link", or "Node" diversity
> > requirement.
>
> while L in SRLG stands for "links", one could be quite creative
> with the usage of SRLGs, and use them not just for links, but for
> nodes as well. Doing this would allow to support both link and node
> diversity.
>

Please refer to draft-many-ccamp-srg-01.txt for more details on "SRG" usage in the

context of diversity.

Delivery-date: Mon, 25 Mar 2002 12:26:38 -0800
From: Randy Bush <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: Re: Generalized Signaling documents 
Date: Mon, 25 Mar 2002 12:26:01 -0800

>> but it will be so now.  no exact number, but no longs lists.
> Does that represent your own position, or the position of the
> IESG as the whole ?

the iesg, the rfc editor, the teacher, and my mommy.  more details
forthcoming.

can we get to work now?

randy

Delivery-date: Mon, 25 Mar 2002 12:00:19 -0800
To: Jun Yu <[email-masked]>
cc: "'Kireeti Kompella'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: FW: path TLV & srlg TLV 
Date: Mon, 25 Mar 2002 11:59:47 -0800
From: Yakov Rekhter <[email-masked]>

Jun,

> No. I don't think so. 
> 
> But what I want to point out is,
> 
> (1). There is inconsistency between "LSP Hierarchy with Generalized MPLS TE"
> and 
> "Generalized Multi-Protocol Label Switching (GMPLS) Architecture" on this
> matter 
> (whether to use path TLV or SRLG TLV in FA advertisement).

that certainly has to be fixed (in the next iteration of the
Architecture document).

> (2). If we only advertise Path Information for the FA, then the SRLG
> information of the FA 
> can be derived, just as you specified in the "LSP Hierarchy" draft, it is
> "the union of the 
> SRLGs of the underlying TE links that make up the FA-LSP path".
> 
> On the other hand, if we only advertise SRLG Information for the FA, then
> the FA-LSP's path 
> information becomes opaque to all the LSRs other than the headend LSR. This
> makes it difficult 
> for the LSR to make a routing decision with "Link", or "Node" diversity
> requirement.

while L in SRLG stands for "links", one could be quite creative
with the usage of SRLGs, and use them not just for links, but for
nodes as well. Doing this would allow to support both link and node 
diversity.

Yakov.

> 
> Thanks.
> 
> -Jun
> 
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:[email-masked]]
> > Sent: Friday, March 15, 2002 5:05 PM
> > To: Jun Yu
> > Cc: [email-masked]'
> > Subject: Re: FW: path TLV & srlg TLV
> > 
> > 
> > 
> > 
> > On Fri, 15 Mar 2002, Jun Yu wrote:
> > 
> > > > Section 4.1.10, the context is changed to "SRLG 
> > Information" from the
> > > > previous "Path Information".
> > 
> > Do you think it is useful to include both SRLG and Path information?
> > 
> > Kireeti.
> > 
> 

Delivery-date: Mon, 25 Mar 2002 11:57:10 -0800
To: Randy Bush <[email-masked]>
cc: "Wijnen, Bert (Bert)" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: Re: Generalized Signaling documents 
Date: Mon, 25 Mar 2002 11:54:37 -0800
From: Yakov Rekhter <[email-masked]>

Randy,

> >> I suggest that the group of current authors/editors work out
> >> a reasonable number of people to be on the list.
> >> I was giving guidelines that we (in IESG discussion) have 
> >> used in the past.
> > So, you seem to suggest that the guidelines that the IESG "have
> > used in the past" was to have no more than 3 to 4 authors.
> 
> maybe it seems that way to you, but no one said that.
> 
> but it will be so now.  no exact number, but no longs lists.

Does that represent your own position, or the position of the
IESG as the whole ?

Yakov.

Delivery-date: Fri, 22 Mar 2002 16:00:54 -0800
From: Randy Bush <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: Re: Generalized Signaling documents 
Date: Fri, 22 Mar 2002 15:58:03 -0800

>> I suggest that the group of current authors/editors work out
>> a reasonable number of people to be on the list.
>> I was giving guidelines that we (in IESG discussion) have 
>> used in the past.
> So, you seem to suggest that the guidelines that the IESG "have
> used in the past" was to have no more than 3 to 4 authors.

maybe it seems that way to you, but no one said that.

but it will be so now.  no exact number, but no longs lists.

sorry to be terse, but i have work to do.

randy

Delivery-date: Fri, 22 Mar 2002 12:51:19 -0800
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: ccamp-wg <[email-masked]>
Subject: Re: Generalized Signaling documents 
Date: Fri, 22 Mar 2002 12:49:56 -0800
From: Yakov Rekhter <[email-masked]>

Bert,

> I suggest that the group of current authors/editors work out
> a reasonable number of people to be on the list.
> I was giving guidelines that we (in IESG discussion) have 
> used in the past.

So, you seem to suggest that the guidelines that the IESG "have
used in the past" was to have no more than 3 to 4 authors.

Out of the 47 recently published RFCs (rfc3196 to rfc3275) 2 were
published with 5 authors, 2 with 6 authors, 5 with 7 authors, 1
with 10 authors, and 1 with 14 authors. That is, about 1/4 of the
recently published RFCs seem to violate the guidelines.

With this in mind could you be a bit more precise on the guidelines
that have been applied when publishing these RFCs.

Yakov.

> Bert 
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[email-masked]]
> > Sent: Friday, March 22, 2002 12:40 AM
> > To: Wijnen, Bert (Bert)
> > Cc: Kireeti Kompella; Ron Bonica (E-mail); ccamp-wg
> > Subject: Re: Generalized Signaling documents 
> > 
> > 
> > Bert,
> > 
> > > Chairs and authors/editors, if/when you go through a new
> > > revision of the drafts (any drafts), pls take action
> > > 
> > > - to reduce the list of authors on the front page.
> > >   main contributors (those who wrote say 30% of the text)
> > >   can be on front page. Others can be explicitly acknoledged
> > >   in the acknowledgement section
> > 
> > If you suggest to limit the list of authors to only "those
> > who wrote say 30% of the text", then are you saying that
> > an RFC can't have more than 3-4 authors ?
> > 
> > Yakov.
> > 

Delivery-date: Fri, 22 Mar 2002 11:23:28 -0800
Date: Fri, 22 Mar 2002 14:22:52 -0500
To: [email-masked]
From: Baktha Muralidharan <[email-masked]>
Subject: Comments on LMP
Cc: [email-masked]

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

Hi Jonathan,

         Looks the following comments that I sent some time ago
         got lost.

Thanks,

/Baktha

>X-Sender: [email-masked]
>X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
>Date: Thu, 14 Mar 2002 23:02:27 -0500
>To: Jonathan Lang <[email-masked]>
>From: Baktha Muralidharan <[email-masked]>
>Subject: Comments on LMP
>Cc: [email-masked], [email-masked]
>
>Hi Jonathan
>
>          We have the following comments on LMP draft 3:
>--------------------------------------------------
>1. In the current LMP draft (draft-ietf-ccamp-lmp-03.txt), section 7 talks
>    about Message ID usage. It states,
>
>             "Unacknowledged messages sent with the MESSAGE_ID object
>              SHOULD be retransmitted until the message is acknowledged
>              or until a retry limit is reached."
>
>    What are the subsequent actions that need to take place when the
>    above conditions occur ?
>
>2. When Nacking a link summary, the current message format doesn't allow 
>indicate
>    what's wrong with each interface mapping.. "per-interface" error codes 
> would
>    be helpful. i.e. The TE link and each data link object in the Nack message
>    needs an error code to localize the failure.
>
>3. When a channel status msg is received with message ID less than
>an earlier (TE-Link) message, it might still be accepted per the
>draft. So, in the case where it is accepted, should the accepted
>    message ID become the basis for all future message ID (validations)?
>
>4. CC ID can be numbered (i.e. IPv4 format) per OIF/OUNI. However, the 
>current LMP
>    draft does not support it.
>
>------------------------------------------------------------
>Thanks,
>
>/Baktha Muralidharan
>Cisco Systems, Inc.
>Chelmsford, MA.

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

<html>
Hi Jonathan,<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Looks the
following comments that I sent some time ago<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>got
lost.<br>
<br>
Thanks,<br>
<br>
/Baktha<br>
<br>
<br>
<blockquote type=cite cite>X-Sender: [email-masked]<br>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2<br>
Date: Thu, 14 Mar 2002 23:02:27 -0500<br>
To: Jonathan Lang &lt;[email-masked]&gt;<br>
From: Baktha Muralidharan &lt;[email-masked]&gt;<br>
Subject: Comments on LMP<br>
Cc: [email-masked], [email-masked]<br>
<br>
Hi Jonathan<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; We have the following
comments on LMP draft 3:<br>
--------------------------------------------------<br>
<font face="Courier New, Courier">1. In the current LMP draft
(draft-ietf-ccamp-lmp-03.txt), section 7 talks<br>
&nbsp;&nbsp; about Message ID usage. It states,<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;Unacknowledged messages sent with the MESSAGE_ID object <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SHOULD be retransmitted until the message is acknowledged<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
or until a retry limit is reached.&quot;<br>
<br>
&nbsp;&nbsp; What are the subsequent actions that need to take place when
the<br>
&nbsp;&nbsp; above conditions occur ?<br>
<br>
2. When Nacking a link summary, the current message format doesn’t allow
indicate<br>
&nbsp;&nbsp; what's wrong with each interface mapping..
&quot;per-interface&quot; error codes would<br>
&nbsp;&nbsp; be helpful. i.e. The TE link and each data link object in
the Nack message<br>
&nbsp;&nbsp; needs an error code to localize the failure.<br>
<br>
3. When a channel status msg is received with message ID less than<br>
an earlier (TE-Link) message, it might still be accepted per the <br>
draft. So, in the case where it is accepted, should the accepted<br>
&nbsp;&nbsp; message ID become the basis for all future message ID
(validations)?<br>
&nbsp; <br>
4. CC ID can be numbered (i.e. IPv4 format) per OIF/OUNI. However, the
current LMP<br>
&nbsp;&nbsp; draft does not support it.<br>
<br>
</font>------------------------------------------------------------<br>
Thanks,<br>
<br>
/Baktha Muralidharan<br>
Cisco Systems, Inc.<br>
Chelmsford, MA. </blockquote></html>

--=====================_18841572==_.ALT--

Delivery-date: Fri, 22 Mar 2002 11:00:14 -0800
From: Jonathan Lang <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, Jonathan Lang <[email-masked]>
Subject:  LMP over UDP
Date: Fri, 22 Mar 2002 10:51:43 -0800

All,

I had a discussion with Scott in Minnesota about progressing LMP through the
IESG.  He had given the LMP draft a "pre-IESG" review (looking for obvious
rejection material) and realized that it wouldn't fly as LMP over raw IP -
they're not giving out IP protocol IDs unless you have a very very
compelling reason.  Instead we will run LMP over UDP, and get a UDP port for
LMP from IANA.  Fixing this now will short-circuit an almost certain IESG
rejection.

Thanks,
Jonathan

Delivery-date: Fri, 22 Mar 2002 09:03:00 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: John Drake <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: RE: Generalized Signaling documents
Date: Fri, 22 Mar 2002 18:01:55 +0100

I think that I did suggest that the authors try to come up with a 
reasonable list. Pls do so and then we can take it from there.

Bert 

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Friday, March 22, 2002 5:35 PM
> To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; Ron Bonica (E-mail)
> Cc: ccamp-wg
> Subject: RE: Generalized Signaling documents
> 
> 
> Bert,
> 
> I'd agree with 'main contributors' but not 'those who wrote 
> say 30% of the
> text'.  That reminds me of trying to judge programmer productivity by
> counting line of code.  In the spirit of 'main contributors' 
> why don't you
> let the authors themselves do some soul searching and revise the list
> themselves?
> 
> This seems to be more in keeping with the spirit of the IETF.
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Thursday, March 21, 2002 1:13 PM
> To: Kireeti Kompella; Ron Bonica (E-mail)
> Cc: ccamp-wg
> Subject: RE: Generalized Signaling documents
> 
> 
> Chairs and authors/editors, if/when you go through a new
> revision of the drafts (any drafts), pls take action
> 
> - to reduce the list of authors on the front page.
>   main contributors (those who wrote say 30% of the text)
>   can be on front page. Others can be explicitly acknoledged
>   in the acknowledgement section
>   An example is RFC2571 Acknowledgement section.
> 
> - Split your references in normative and informative 
>   references. 
> 
> For details on these RFC-guidelines, go to the www.rfc-editor.org
> web pages.
> 
> Bert 
> 

Delivery-date: Fri, 22 Mar 2002 08:37:28 -0800
From: John Drake <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: RE: Generalized Signaling documents
Date: Fri, 22 Mar 2002 08:34:48 -0800

Bert,

I'd agree with 'main contributors' but not 'those who wrote say 30% of the
text'.  That reminds me of trying to judge programmer productivity by
counting line of code.  In the spirit of 'main contributors' why don't you
let the authors themselves do some soul searching and revise the list
themselves?

This seems to be more in keeping with the spirit of the IETF.

Thanks,

John
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Thursday, March 21, 2002 1:13 PM
To: Kireeti Kompella; Ron Bonica (E-mail)
Cc: ccamp-wg
Subject: RE: Generalized Signaling documents

Chairs and authors/editors, if/when you go through a new
revision of the drafts (any drafts), pls take action

- to reduce the list of authors on the front page.
  main contributors (those who wrote say 30% of the text)
  can be on front page. Others can be explicitly acknoledged
  in the acknowledgement section
  An example is RFC2571 Acknowledgement section.

- Split your references in normative and informative 
  references. 

For details on these RFC-guidelines, go to the www.rfc-editor.org
web pages.

Bert 

Delivery-date: Thu, 21 Mar 2002 23:52:46 -0800
From: Heiles Juergen <[email-masked]>
To: "'Brungard, Deborah A, ALASO'" <[email-masked]>
Cc: ccamp <[email-masked]>
Subject: RE: LBM comment
Date: Fri, 22 Mar 2002 08:51:19 +0100

Deborah,

virtual concatenation with LCAS can also be used by non-GFP mapped clients like IP (via POS) and ATM.

Juergen

> -----Original Message-----
> From: Brungard, Deborah A, ALASO [mailto:[email-masked]]
> Sent: Thursday, March 21, 2002 4:26 PM
> To: Sudheer Dharanikota; Bernstein, Greg
> Cc: Maarten Vissers; ccamp
> Subject: RE: LBM comment
> 
> 
> Agree with Greg and Maarten.
> 
> Hopefully of help are some tutorials from the last T1X1 
> meeting on virtual conc and LCAS. I've given the links below. 
> Key is that LCAS is not about the addition/deletion of an 
> STS-x, this is handled by an EMS/NMS/control plane. LCAS is 
> about the use of the STS-x(s). It provides for the hitless 
> use of an STS-x by a client signal e.g. hitless resizing of 
> the bandwidth used by a client signal. It is based on the 
> premise that the STS-x is available. And, LCAS is only used 
> for client signals using virtual conc - it provides the 
> hitless resizing for the client mapping. The only client 
> signals defined for using Virtual conc/LCAS are the GFP 
> mapped clients: Ethernet, ESCON, Fiber Channel, FICON, etc.
> 
> Deborah
> 
> Links:
> LCAS:
> ftp://ftp.t1.org/T1X1/X1.5/2x150440.ppt
> Virtual concatenation:
> ftp://ftp.t1.org/T1X1/X1.5/2x150450.ppt
> GFP:
> ftp://ftp.t1.org/T1X1/X1.5/2x150460.ppt
> 
> 
> 
> 
> -----Original Message-----
> From: Sudheer Dharanikota [mailto:[email-masked]]
> Sent: Wednesday, March 20, 2002 9:15 PM
> To: Bernstein, Greg
> Cc: 'Maarten Vissers'; ccamp
> Subject: Re: LBM comment
> 
> 
> Hi Maarten and Greg:
> 
> Can you help me in understanding the following case?
> 
> Given:
> 
> LCAS is used for "hitless" increase or decrease of capacity
> of an end-to-end pipe.
> 
> Question:
> 
> How does the end nodes (of the pipe) know  whether a given
> increase of capacity is possible dynamically?
> 
> My view: I think this case can be addressed using NMS or
> using signaling protocol extensions. Using NMS we need
> to know the complete topology and "its current state". Using signaling
> protocol we can figure this information out either locally or 
> by polling.
> This is the case being called LBM.
> 
> Please comment.
> 
> - sudheer
> 
> 
> "Bernstein, Greg" wrote:
> 
> > Hi all, to reiterate what Maarten points out below: "LCAS 
> takes care of the
> > hitless addition/removal of this trail to/from the virtual 
> concatenated
> > group in service.".  Eric's statement concerning LCAS being between
> > PTE-to-PTE also applies to Virtual Concatenation in general.
> > Hence the SONET LTE layer (SDH MS termination) switches, 
> i.e., most of the
> > ADMs and XCs out there don't care that the signal is 
> virtually concatenated.
> > Hence all the current stuff in the SONET/SDH signaling 
> extensions concerning
> > virtual concatenation is just end system information and 
> not needed by the
> > network.
> > Is the LBM work really aimed at the virtual concatenated 
> case? If so it
> > seems unnecessary. Also instead of further complicating 
> connection signaling
> > couldn't we abstract things a bit to have some type of 
> grouping/association
> > of multiple (pt-to-pt) connections together rather than changing the
> > signaling protocol?
> >
> > Greg B.
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Wednesday, March 20, 2002 8:29 AM
> > To: ccamp
> > Subject: LBM comment
> >
> > Not having had time earlier to read the LBM draft, I only 
> just came across
> > some
> > still VERYY INCORRECT text in 
> draft-mannie-ccamp-gmpls-lbm-tdm-01.txt.
> >
> > >From section 3:
> >
> >    "LCAS is an end-to-end (i.e. PTE-to-PTE) signalling 
> protocol enabling
> >    the bandwidth modification at end systems and setting up and
> >    releasing circuits provisioned and configured through Network
> >    Management Systems (NMS). However, LCAS doesn't apply to 
> setting up
> >    and releasing bandwidth at intermediate nodes. This 
> means that LCAS
> >    must be combined with an NMS system in order to offer a dynamic
> >    connection setup throughout the network. Therefore, the 
> advantage of
> >    using GMPLS is that it provides a complete integrated solution,
> >    allowing for a wide range of traffic parameter modifications."
> >
> > LCAS MUST NOT AT ALL BE COMBINED WITH NMS!!!!!!!!!!!!!! LCAS must be
> > combined
> > with either NMS or ASON or GMPLS, which latter 3 take care 
> of the set up or
> > release of a VC-n or ODUk trail. LCAS takes care of the hitless
> > addition/removal
> > of this trail to/from the virtual concatenated group in service.
> >
> > >From section 3:
> >
> >    "Using LCAS in parallel with GMPLS implies that GMPLS traffic
> >    parameters may be modified without the GMPLS control plane being
> >    aware of these modifications. However, GMPLS provides native
> >    capabilities to modify traffic parameters of an established LSP
> >    since MPLS-TE signalling was originally conceived to 
> allow traffic
> >    parameter (bandwidth) modification."
> >
> > Using LCAS does *NOT* at all imply that GMPLS traffic parameters are
> > modified.
> > NMS/ASON/GMPLS are in full control of the connections setup 
> to support the
> > virtual concatenated group.
> >
> > Regards,
> >
> > Maarten
> 
> 

Delivery-date: Thu, 21 Mar 2002 17:55:43 -0800
From: Randy Bush <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: Re: Generalized Signaling documents 
Date: Thu, 21 Mar 2002 19:54:14 -0600

> If you suggest to limit the list of authors to only "those
> who wrote say 30% of the text", then are you saying that
> an RFC can't have more than 3-4 authors ?

my calculator comes up with similar results!

randy

Delivery-date: Thu, 21 Mar 2002 16:00:24 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: RE: Generalized Signaling documents 
Date: Fri, 22 Mar 2002 00:59:45 +0100

I suggest that the group of current authors/editors work out
a reasonable number of people to be on the list.
I was giving guidelines that we (in IESG discussion) have 
used in the past.

Bert 

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Friday, March 22, 2002 12:40 AM
> To: Wijnen, Bert (Bert)
> Cc: Kireeti Kompella; Ron Bonica (E-mail); ccamp-wg
> Subject: Re: Generalized Signaling documents 
> 
> 
> Bert,
> 
> > Chairs and authors/editors, if/when you go through a new
> > revision of the drafts (any drafts), pls take action
> > 
> > - to reduce the list of authors on the front page.
> >   main contributors (those who wrote say 30% of the text)
> >   can be on front page. Others can be explicitly acknoledged
> >   in the acknowledgement section
> 
> If you suggest to limit the list of authors to only "those
> who wrote say 30% of the text", then are you saying that
> an RFC can't have more than 3-4 authors ?
> 
> Yakov.
> 

Delivery-date: Thu, 21 Mar 2002 15:40:29 -0800
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: Kireeti Kompella <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: Re: Generalized Signaling documents 
Date: Thu, 21 Mar 2002 15:39:44 -0800
From: Yakov Rekhter <[email-masked]>

Bert,

> Chairs and authors/editors, if/when you go through a new
> revision of the drafts (any drafts), pls take action
> 
> - to reduce the list of authors on the front page.
>   main contributors (those who wrote say 30% of the text)
>   can be on front page. Others can be explicitly acknoledged
>   in the acknowledgement section

If you suggest to limit the list of authors to only "those
who wrote say 30% of the text", then are you saying that
an RFC can't have more than 3-4 authors ?

Yakov.

Delivery-date: Thu, 21 Mar 2002 15:36:46 -0800
From: "Ong, Lyndon" <[email-masked]>
To: "'Debanjan Saha'" <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: RE: Generalized Signaling documents
Date: Thu, 21 Mar 2002 15:34:52 -0800

FYI, this is a relatively new policy on the part of the
RFC Editor, there is an explanation at http://www.rfc-editor.org/policy.html
- it is being implemented in
other groups as well.

Cheers,

Lyndon

-----Original Message-----
From: Debanjan Saha [mailto:[email-masked]]
Sent: Thursday, March 21, 2002 2:58 PM
To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; Ron Bonica (E-mail)
Cc: ccamp-wg
Subject: RE: Generalized Signaling documents

Bert,

>>Chairs and authors/editors, if/when you go through a new
>>revision of the drafts (any drafts), pls take action
>>to reduce the list of authors on the front page.

Can you help me understand why this an issue?

>>  main contributors (those who wrote say 30% of the text)
>>  can be on front page. 

A lot of people contributed over a long time and I am not sure
if there are individuals who contributed 30% and more.

>>For details on these RFC-guidelines, go to the www.rfc-editor.org
>>web pages.

There seems to be a lot of material on the web page. Can you point out
the specific area/document where this issue is addressed?

Debanjan

Delivery-date: Thu, 21 Mar 2002 15:12:24 -0800
From: Debanjan Saha <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: RE: Generalized Signaling documents
Date: Thu, 21 Mar 2002 17:57:48 -0500

Bert,

>>Chairs and authors/editors, if/when you go through a new
>>revision of the drafts (any drafts), pls take action
>>to reduce the list of authors on the front page.

Can you help me understand why this an issue?

>>  main contributors (those who wrote say 30% of the text)
>>  can be on front page. 

A lot of people contributed over a long time and I am not sure
if there are individuals who contributed 30% and more.

>>For details on these RFC-guidelines, go to the www.rfc-editor.org
>>web pages.

There seems to be a lot of material on the web page. Can you point out
the specific area/document where this issue is addressed?

Debanjan

Delivery-date: Thu, 21 Mar 2002 14:23:35 -0800
Date: Thu, 21 Mar 2002 17:22:35 -0500
To: "Wijnen, Bert (Bert)" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: Generalized Signaling documents
Cc: "Berger, Lou" <[email-masked]>, "ccamp-wg" <[email-masked]>

At 05:07 PM 3/21/2002, Wijnen, Bert (Bert) wrote:

> > -----Original Message-----
> > From: Lou Berger [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Thursday, March 21, 2002 10:53 PM
> > To: Wijnen, Bert (Bert)
> > Cc: Kireeti Kompella; Ron Bonica (E-mail); ccamp-wg
> > Subject: RE: Generalized Signaling documents
> >
> >
> > At 04:13 PM 3/21/2002, Wijnen, Bert (Bert) wrote:
> >
> > >Chairs and authors/editors, if/when you go through a new
> > >revision of the drafts (any drafts), pls take action
> > >
> > >- to reduce the list of authors on the front page.
> > >   main contributors (those who wrote say 30% of the text)
> > >   can be on front page. Others can be explicitly acknoledged
> > >   in the acknowledgement section
> > >   An example is RFC2571 Acknowledgement section.
> >
> > Bert,
> >
> > An alternative approach is to list editors on the first page
> > and list all authors in the authors' addresses section.
> > I've seen this used in some older RFCs,
>
>If you point me to specific RFCs, I can try to check them and
>try to figure how that happened.

What's to figure out.

> > I also ran an this by
> > one of the rfc-editor's -  he didn't say no (or explicitly yes).
> >
>I did discuss this with my co-AD (scott) and with the RFC-Editor(s)
>this morning, and we are in agreement that your alternative seems
>not acceptable. Have you checked how it was done in RFC2571?

yes.

>Why would that not be good enough for acknowledging the
>contributions by the various people?

I'll send some private e-mail on the topic so as not to bother everyone 
else with the discussion.

Lou

>Bert

Delivery-date: Thu, 21 Mar 2002 14:07:40 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Lou Berger <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: RE: Generalized Signaling documents
Date: Thu, 21 Mar 2002 23:07:08 +0100

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Thursday, March 21, 2002 10:53 PM
> To: Wijnen, Bert (Bert)
> Cc: Kireeti Kompella; Ron Bonica (E-mail); ccamp-wg
> Subject: RE: Generalized Signaling documents
> 
> 
> At 04:13 PM 3/21/2002, Wijnen, Bert (Bert) wrote:
> 
> >Chairs and authors/editors, if/when you go through a new
> >revision of the drafts (any drafts), pls take action
> >
> >- to reduce the list of authors on the front page.
> >   main contributors (those who wrote say 30% of the text)
> >   can be on front page. Others can be explicitly acknoledged
> >   in the acknowledgement section
> >   An example is RFC2571 Acknowledgement section.
> 
> Bert,
> 
> An alternative approach is to list editors on the first page 
> and list all authors in the authors' addresses section.
> I've seen this used in some older RFCs,

If you point me to specific RFCs, I can try to check them and
try to figure how that happened.

> I also ran an this by
> one of the rfc-editor's -  he didn't say no (or explicitly yes).
> 
I did discuss this with my co-AD (scott) and with the RFC-Editor(s)
this morning, and we are in agreement that your alternative seems
not acceptable. Have you checked how it was done in RFC2571?
Why would that not be good enough for acknowledging the 
contributions by the various people?

Bert

Delivery-date: Thu, 21 Mar 2002 13:54:42 -0800
Date: Thu, 21 Mar 2002 16:53:13 -0500
To: "Wijnen, Bert (Bert)" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: Generalized Signaling documents
Cc: "Kireeti Kompella" <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>, "ccamp-wg" <[email-masked]>

At 04:13 PM 3/21/2002, Wijnen, Bert (Bert) wrote:

>Chairs and authors/editors, if/when you go through a new
>revision of the drafts (any drafts), pls take action
>
>- to reduce the list of authors on the front page.
>   main contributors (those who wrote say 30% of the text)
>   can be on front page. Others can be explicitly acknoledged
>   in the acknowledgement section
>   An example is RFC2571 Acknowledgement section.

Bert,

An alternative approach is to list editors on the first page and list all 
authors in the authors' addresses section.  I've seen this used in some 
older RFCs, I also ran an this by one of the rfc-editor's - he didn't say 
no (or explicitly yes).

>- Split your references in normative and informative
>   references.
>
>For details on these RFC-guidelines, go to the www.rfc-editor.org
>web pages.
>
>Bert

I'll make sure to do both of the above in the next rev of the signaling docs.

Lou

Delivery-date: Thu, 21 Mar 2002 13:18:01 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: RE: Generalized Signaling documents
Date: Thu, 21 Mar 2002 22:13:01 +0100

Chairs and authors/editors, if/when you go through a new
revision of the drafts (any drafts), pls take action

- to reduce the list of authors on the front page.
  main contributors (those who wrote say 30% of the text)
  can be on front page. Others can be explicitly acknoledged
  in the acknowledgement section
  An example is RFC2571 Acknowledgement section.

- Split your references in normative and informative 
  references. 

For details on these RFC-guidelines, go to the www.rfc-editor.org
web pages.

Bert 

Delivery-date: Thu, 21 Mar 2002 07:29:27 -0800
content-class: urn:content-classes:message
Subject: RE: LBM comment
Date: Thu, 21 Mar 2002 10:26:23 -0500
From: "Brungard, Deborah A, ALASO" <[email-masked]>
To: "Sudheer Dharanikota" <[email-masked]>, "Bernstein, Greg" <[email-masked]>
Cc: "Maarten Vissers" <[email-masked]>, "ccamp" <[email-masked]>

Agree with Greg and Maarten.

Hopefully of help are some tutorials from the last T1X1 meeting on =
virtual conc and LCAS. I've given the links below. Key is that LCAS is =
not about the addition/deletion of an STS-x, this is handled by an =
EMS/NMS/control plane. LCAS is about the use of the STS-x(s). It =
provides for the hitless use of an STS-x by a client signal e.g. hitless =
resizing of the bandwidth used by a client signal. It is based on the =
premise that the STS-x is available. And, LCAS is only used for client =
signals using virtual conc - it provides the hitless resizing for the =
client mapping. The only client signals defined for using Virtual =
conc/LCAS are the GFP mapped clients: Ethernet, ESCON, Fiber Channel, =
FICON, etc.

Deborah

Links:
LCAS:
ftp://ftp.t1.org/T1X1/X1.5/2x150440.ppt
Virtual concatenation:
ftp://ftp.t1.org/T1X1/X1.5/2x150450.ppt
GFP:
ftp://ftp.t1.org/T1X1/X1.5/2x150460.ppt

-----Original Message-----
From: Sudheer Dharanikota [mailto:[email-masked]]
Sent: Wednesday, March 20, 2002 9:15 PM
To: Bernstein, Greg
Cc: 'Maarten Vissers'; ccamp
Subject: Re: LBM comment

Hi Maarten and Greg:

Can you help me in understanding the following case?

Given:

LCAS is used for "hitless" increase or decrease of capacity
of an end-to-end pipe.

Question:

How does the end nodes (of the pipe) know  whether a given
increase of capacity is possible dynamically?

My view: I think this case can be addressed using NMS or
using signaling protocol extensions. Using NMS we need
to know the complete topology and "its current state". Using signaling
protocol we can figure this information out either locally or by =
polling.
This is the case being called LBM.

Please comment.

- sudheer

"Bernstein, Greg" wrote:

> Hi all, to reiterate what Maarten points out below: "LCAS takes care =
of the
> hitless addition/removal of this trail to/from the virtual =
concatenated
> group in service.".  Eric's statement concerning LCAS being between
> PTE-to-PTE also applies to Virtual Concatenation in general.
> Hence the SONET LTE layer (SDH MS termination) switches, i.e., most of =
the
> ADMs and XCs out there don't care that the signal is virtually =
concatenated.
> Hence all the current stuff in the SONET/SDH signaling extensions =
concerning
> virtual concatenation is just end system information and not needed by =
the
> network.
> Is the LBM work really aimed at the virtual concatenated case? If so =
it
> seems unnecessary. Also instead of further complicating connection =
signaling
> couldn't we abstract things a bit to have some type of =
grouping/association
> of multiple (pt-to-pt) connections together rather than changing the
> signaling protocol?
>
> Greg B.
>
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Wednesday, March 20, 2002 8:29 AM
> To: ccamp
> Subject: LBM comment
>
> Not having had time earlier to read the LBM draft, I only just came =
across
> some
> still VERYY INCORRECT text in draft-mannie-ccamp-gmpls-lbm-tdm-01.txt.
>
> >From section 3:
>
>    "LCAS is an end-to-end (i.e. PTE-to-PTE) signalling protocol =
enabling
>    the bandwidth modification at end systems and setting up and
>    releasing circuits provisioned and configured through Network
>    Management Systems (NMS). However, LCAS doesn't apply to setting up
>    and releasing bandwidth at intermediate nodes. This means that LCAS
>    must be combined with an NMS system in order to offer a dynamic
>    connection setup throughout the network. Therefore, the advantage =
of
>    using GMPLS is that it provides a complete integrated solution,
>    allowing for a wide range of traffic parameter modifications."
>
> LCAS MUST NOT AT ALL BE COMBINED WITH NMS!!!!!!!!!!!!!! LCAS must be
> combined
> with either NMS or ASON or GMPLS, which latter 3 take care of the set =
up or
> release of a VC-n or ODUk trail. LCAS takes care of the hitless
> addition/removal
> of this trail to/from the virtual concatenated group in service.
>
> >From section 3:
>
>    "Using LCAS in parallel with GMPLS implies that GMPLS traffic
>    parameters may be modified without the GMPLS control plane being
>    aware of these modifications. However, GMPLS provides native
>    capabilities to modify traffic parameters of an established LSP
>    since MPLS-TE signalling was originally conceived to allow traffic
>    parameter (bandwidth) modification."
>
> Using LCAS does *NOT* at all imply that GMPLS traffic parameters are
> modified.
> NMS/ASON/GMPLS are in full control of the connections setup to support =
the
> virtual concatenated group.
>
> Regards,
>
> Maarten

Delivery-date: Thu, 21 Mar 2002 01:14:46 -0800
Date: Thu, 21 Mar 2002 10:12:11 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>
Subject: Re: LBM comment

This is a multi-part message in MIME format.
--------------4C2166AF110615735207020D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have created a short document to illustrate where LCAS is involved in the
connection setup. (see attachment).

In principle, LCAS isn't involved in connection set up or release. 
LCAS controls if a trail is being used to forward payload information. 
The set up and release of the trail is fully controlled by NMS/ASON/GMPLS.

E.g. when the bandwidth of the client layer link that is supported by the
virtual concatenated trail is to be increased, the network engineering
controller will request this BANDWIDTH INCREASE. The Call Controller receiving
this request will send a Connection Modification request for Connection X to the
Connection Controller and it will send an ADD member command to the LCAS process
within the virt conc port group. The ADD command is now forwarded over the VC-n
port that will be the end point of the new VC-n trail. When this trail is set
up, the LCAS process at the far end will receive the ADD command and will detect
that the trail signal fail condition has cleared. It will reply with an OK
message. When this OK message is received by the near end LCAS process, it will
start forwarding payload information over this new trail (after it has send
another message indicating the exact frame which will contain paylaod in it for
the first time).

Now the bandwidth is increased in one direction. The similar process is
performed for the other direction. I.e. the far end virt conc port group
receiving the Connection Modification request will also receive the ADD command
(i.e. responsibility of the network engineering controller or call controller).
The far end LCAS process will now issue the ADD command over the VC-n port that
is the endpoint of the new trail. The near end LCAS process will at a certain
moment receive the ADD command from the far end and when the associated trail
signal fail condition clears, it will respond with the OK message. When this OK
message arrives at the far end LCAS process, that process will start forwarding
payload information over this new trail (after it has send another message
indicating the exact frame which will contain paylaod in it for the first time).

Up to so far.

Regards,

Maarten
--------------4C2166AF110615735207020D
Content-Type: application/x-zip-compressed;
 name="lcas-gmpls-pdf.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="lcas-gmpls-pdf.zip"

--------------4C2166AF110615735207020D
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------4C2166AF110615735207020D--

Delivery-date: Wed, 20 Mar 2002 18:18:47 -0800
Date: Wed, 20 Mar 2002 18:14:47 -0800
From: Sudheer Dharanikota <[email-masked]>
To: "Bernstein, Greg" <[email-masked]>
CC: "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>
Subject: Re: LBM comment

Hi Maarten and Greg:

Can you help me in understanding the following case?

Given:

LCAS is used for "hitless" increase or decrease of capacity
of an end-to-end pipe.

Question:

How does the end nodes (of the pipe) know  whether a given
increase of capacity is possible dynamically?

My view: I think this case can be addressed using NMS or
using signaling protocol extensions. Using NMS we need
to know the complete topology and "its current state". Using signaling
protocol we can figure this information out either locally or by polling.
This is the case being called LBM.

Please comment.

- sudheer

"Bernstein, Greg" wrote:

> Hi all, to reiterate what Maarten points out below: "LCAS takes care of the
> hitless addition/removal of this trail to/from the virtual concatenated
> group in service.".  Eric's statement concerning LCAS being between
> PTE-to-PTE also applies to Virtual Concatenation in general.
> Hence the SONET LTE layer (SDH MS termination) switches, i.e., most of the
> ADMs and XCs out there don't care that the signal is virtually concatenated.
> Hence all the current stuff in the SONET/SDH signaling extensions concerning
> virtual concatenation is just end system information and not needed by the
> network.
> Is the LBM work really aimed at the virtual concatenated case? If so it
> seems unnecessary. Also instead of further complicating connection signaling
> couldn't we abstract things a bit to have some type of grouping/association
> of multiple (pt-to-pt) connections together rather than changing the
> signaling protocol?
>
> Greg B.
>
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Wednesday, March 20, 2002 8:29 AM
> To: ccamp
> Subject: LBM comment
>
> Not having had time earlier to read the LBM draft, I only just came across
> some
> still VERYY INCORRECT text in draft-mannie-ccamp-gmpls-lbm-tdm-01.txt.
>
> >From section 3:
>
>    "LCAS is an end-to-end (i.e. PTE-to-PTE) signalling protocol enabling
>    the bandwidth modification at end systems and setting up and
>    releasing circuits provisioned and configured through Network
>    Management Systems (NMS). However, LCAS doesn't apply to setting up
>    and releasing bandwidth at intermediate nodes. This means that LCAS
>    must be combined with an NMS system in order to offer a dynamic
>    connection setup throughout the network. Therefore, the advantage of
>    using GMPLS is that it provides a complete integrated solution,
>    allowing for a wide range of traffic parameter modifications."
>
> LCAS MUST NOT AT ALL BE COMBINED WITH NMS!!!!!!!!!!!!!! LCAS must be
> combined
> with either NMS or ASON or GMPLS, which latter 3 take care of the set up or
> release of a VC-n or ODUk trail. LCAS takes care of the hitless
> addition/removal
> of this trail to/from the virtual concatenated group in service.
>
> >From section 3:
>
>    "Using LCAS in parallel with GMPLS implies that GMPLS traffic
>    parameters may be modified without the GMPLS control plane being
>    aware of these modifications. However, GMPLS provides native
>    capabilities to modify traffic parameters of an established LSP
>    since MPLS-TE signalling was originally conceived to allow traffic
>    parameter (bandwidth) modification."
>
> Using LCAS does *NOT* at all imply that GMPLS traffic parameters are
> modified.
> NMS/ASON/GMPLS are in full control of the connections setup to support the
> virtual concatenated group.
>
> Regards,
>
> Maarten

Delivery-date: Wed, 20 Mar 2002 09:03:41 -0800
From: "Bernstein, Greg" <[email-masked]>
To: "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>
Subject: RE: LBM comment
Date: Wed, 20 Mar 2002 09:02:55 -0800

Hi all, to reiterate what Maarten points out below: "LCAS takes care of the
hitless addition/removal of this trail to/from the virtual concatenated
group in service.".  Eric's statement concerning LCAS being between
PTE-to-PTE also applies to Virtual Concatenation in general.  
Hence the SONET LTE layer (SDH MS termination) switches, i.e., most of the
ADMs and XCs out there don't care that the signal is virtually concatenated.
Hence all the current stuff in the SONET/SDH signaling extensions concerning
virtual concatenation is just end system information and not needed by the
network.
Is the LBM work really aimed at the virtual concatenated case? If so it
seems unnecessary. Also instead of further complicating connection signaling
couldn't we abstract things a bit to have some type of grouping/association
of multiple (pt-to-pt) connections together rather than changing the
signaling protocol?

Greg B.

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, March 20, 2002 8:29 AM
To: ccamp
Subject: LBM comment

Not having had time earlier to read the LBM draft, I only just came across
some
still VERYY INCORRECT text in draft-mannie-ccamp-gmpls-lbm-tdm-01.txt.

>From section 3:

   "LCAS is an end-to-end (i.e. PTE-to-PTE) signalling protocol enabling
   the bandwidth modification at end systems and setting up and
   releasing circuits provisioned and configured through Network
   Management Systems (NMS). However, LCAS doesn't apply to setting up
   and releasing bandwidth at intermediate nodes. This means that LCAS
   must be combined with an NMS system in order to offer a dynamic
   connection setup throughout the network. Therefore, the advantage of
   using GMPLS is that it provides a complete integrated solution,
   allowing for a wide range of traffic parameter modifications."

LCAS MUST NOT AT ALL BE COMBINED WITH NMS!!!!!!!!!!!!!! LCAS must be
combined
with either NMS or ASON or GMPLS, which latter 3 take care of the set up or
release of a VC-n or ODUk trail. LCAS takes care of the hitless
addition/removal
of this trail to/from the virtual concatenated group in service.

>From section 3:

   "Using LCAS in parallel with GMPLS implies that GMPLS traffic
   parameters may be modified without the GMPLS control plane being
   aware of these modifications. However, GMPLS provides native
   capabilities to modify traffic parameters of an established LSP
   since MPLS-TE signalling was originally conceived to allow traffic
   parameter (bandwidth) modification."

Using LCAS does *NOT* at all imply that GMPLS traffic parameters are
modified.
NMS/ASON/GMPLS are in full control of the connections setup to support the
virtual concatenated group.

Regards,

Maarten

Delivery-date: Wed, 20 Mar 2002 08:29:52 -0800
Date: Wed, 20 Mar 2002 17:29:03 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>
Subject: LBM comment

This is a multi-part message in MIME format.
--------------44CA7BD9F833482B8F7B754B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Not having had time earlier to read the LBM draft, I only just came across some
still VERYY INCORRECT text in draft-mannie-ccamp-gmpls-lbm-tdm-01.txt.

>From section 3:

   "LCAS is an end-to-end (i.e. PTE-to-PTE) signalling protocol enabling
   the bandwidth modification at end systems and setting up and
   releasing circuits provisioned and configured through Network
   Management Systems (NMS). However, LCAS doesn't apply to setting up
   and releasing bandwidth at intermediate nodes. This means that LCAS
   must be combined with an NMS system in order to offer a dynamic
   connection setup throughout the network. Therefore, the advantage of
   using GMPLS is that it provides a complete integrated solution,
   allowing for a wide range of traffic parameter modifications."

LCAS MUST NOT AT ALL BE COMBINED WITH NMS!!!!!!!!!!!!!! LCAS must be combined
with either NMS or ASON or GMPLS, which latter 3 take care of the set up or
release of a VC-n or ODUk trail. LCAS takes care of the hitless addition/removal
of this trail to/from the virtual concatenated group in service.

>From section 3:

   "Using LCAS in parallel with GMPLS implies that GMPLS traffic
   parameters may be modified without the GMPLS control plane being
   aware of these modifications. However, GMPLS provides native
   capabilities to modify traffic parameters of an established LSP
   since MPLS-TE signalling was originally conceived to allow traffic
   parameter (bandwidth) modification."

Using LCAS does *NOT* at all imply that GMPLS traffic parameters are modified.
NMS/ASON/GMPLS are in full control of the connections setup to support the
virtual concatenated group.

Regards,

Maarten
--------------44CA7BD9F833482B8F7B754B
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------44CA7BD9F833482B8F7B754B--

Delivery-date: Wed, 20 Mar 2002 08:14:26 -0800
From: Jonathan Lang <[email-masked]>
To: 'Fugui Wang' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Comments on LMP draft 3
Date: Wed, 20 Mar 2002 08:04:55 -0800

Fugui,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Fugui Wang [mailto:[email-masked]]
> Sent: Monday, March 18, 2002 12:55 PM
> To: Jonathan Lang
> Cc: [email-masked]'
> Subject: Comments on LMP draft 3
> 
> 
> Hello Jonathan,
> 
> Here are some comments regarding draft-ietf-ccamp-lmp-03.txt:
> 
> 1. In page 5, section 3:
> "Rather, a node-wide unique 32-bit non-zero integer control channel
identifier
> CCId) is assigned at each end of the control channel. This identifier
comes
> from the same space as the unnumbered interface Id."
> 
> If the control channel is directly on ethernet instead of point-to-point 
> interface or IP tunnel, what should be chosen as the CCId?
> For example, in the following case, if Node A, B, C are connected by 
> ethernet. Node B should have a control channel to A and C respectively.
> What should be the CCIds for these two control channels? In this case
> interface ID is not able to uniquely identify the control channel.  
> 
>     .1                  .2                     .3    10.1.1.0/24
> ----+--------------------+----------------------+--------------
>     |                    +                      |
> +---+---+            +---+----+            +----+----+
> |ifId=2 |            | ifId=3 |            |  ifId=4 |
> |   A   |            |   B    |            |    C    |
> |       |            |        |            |         |
> +-------+            +--------+            +---------+
The CCId is a local identifier.  In the above case, Node B will assign two
separate CCIDs for the control channels to nodes A and C.

> 
> 2. In page 9, section 3.2:
> "The LMP Hello protocol is intended to be a lightweight 
>  keep-alive mechanism that will react to control channel failures 
>  rapidly so that IGP Hellos are not lost and the associated link-
>  state adjacencies are not removed unnecessarily."
> 
> I don't quite understand how LMP hello could prevent IGP hello lost.
> My understading is: as far as there is at least
> one contral channel active between the neighbor, IGP won't remove the
> link-state adjacency, even without LMP detecting the control channel
> failure.
> Is that right? 
LMP can be used to maintain active control channels between neighbors. These
control channels can be used to build a resilient adjacencies in
routing/signaling.

> 
> 3. In page 9, section 3.2.1:
> "If the fast keep-alive mechanism of LMP is not used, the 
>  HelloInterval and HelloDeadInterval parameters MUST be set to zero."
> 
> This paragraph says that the Hello could be optional. However, in the
> Control channel FSM, it seems that this case is not considered.
The intent of the Control channel FSM was to show the state changes when LMP
keep alive is used.  I'm not sure how interesting/helpful it is to discuss
the CC FSM when the keep alive is not used.

> 
> 
> 
> Thanks,
> Fugui
> 

Delivery-date: Tue, 19 Mar 2002 17:02:57 -0800
From: "Cheng, Dean" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: I-D ACTION:draft-cheng-ccamp-ospf-multiarea-te-extensions-00. txt
Date: Tue, 19 Mar 2002 16:28:09 -0800

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

------_=_NextPart_000_01C1CFA6.1E3C5238
Content-Type: text/plain;
	charset="iso-8859-1"

 <<...>> 
This I-D was'nt presented in yesterday's meeting but will 
be appreciated if you can read and send comments to the
mailing list.

Some highlights:

  1) An "address TLV" may be included in opaque LSA by ABRs
     and is capable of advertising multiple rechable addresses
     and subnets in a single opaque LSA. The LSA also includes
     the identity of the source area.

  2) Allows TE links that represent the aggregated traffic trunks
     between pairs of ABRs in a given area being advertised. The
     information contained in the TE links also includes the
     identity of the source area.

  3) The advertising scope of the above two may be specified according
     to the actual networking applications with the follwoing scenarios:

     3a) AS-wide advertising using opaque type 11 LSA.
     3b) per-area advertising (on-demand) using opaque type 10 LSA.
     3c) per-node (head-end LSR, on-demand) using opaque type 9 LSA.

  4) The information of 1) and 2) above tells the head-end LSR
     which area the tail-end LSR resides, and the LSR may build an
     optimized but loose-hop path from itself all the way to the
     entry ABR of the destination area. Note the hops that outside
     of the source area are concatenation of the ABRs in other areas.

Thanks
Dean

-----Original Message-----
From: [email-masked]
Cc: [email-masked]
Sent: 3/4/2002 4:06 AM
Subject: I-D ACTION:draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: OSPF Extensions to Support Multi-Area Traffic 
                          Engineering
	Author(s)	: D. Cheng
	Filename	:
draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt
	Pages		: 6
	Date		: 01-Mar-02
	
The [MULTI-AREA] introduces a set of mechanisms that could be used
to construct LSPs that span multiple IS-IS/OSPF areas, where one 
scenario is to allow the head-end LSR to compute the path all the
way to the ABR in the tail-end area. This document proposes some
new OSPF extensions that can be used in supporting that scenario,
i.e., by leaking some of the useful information from individual 
areas to others, the constraint-based routing at the head-end LSR
of LSPs in OSPF networks with multiple areas can be optimized.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-
extensions-00.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-cheng-ccamp-ospf-multiarea-te-extensions-00.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-cheng-ccamp-ospf-multiarea-te-extensions-00.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_01C1CFA6.1E3C5238
Content-Type: message/rfc822

To: 
Subject: 
Date: Tue, 19 Mar 2002 16:28:12 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C1CFA6.1E3C5238"

------_=_NextPart_002_01C1CFA6.1E3C5238
Content-Type: text/plain

------_=_NextPart_002_01C1CFA6.1E3C5238
Content-Type: application/octet-stream;
	name="ATT26770.txt"
Content-Disposition: attachment;
	filename="ATT26770.txt"

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-cheng-ccamp-ospf-multiarea-te-extensions-00.txt

------_=_NextPart_002_01C1CFA6.1E3C5238
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"

------_=_NextPart_002_01C1CFA6.1E3C5238--

------_=_NextPart_000_01C1CFA6.1E3C5238--

Envelope-to: [email-masked]
Delivery-date: Tue, 19 Mar 2002 08:43:00 -0800
Date: Tue, 19 Mar 2002 08:42:18 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Document status

Here is the document status as presented in CCAMP 53.  Please read,
especially if you are an author, and send corrections to Ron and me.

Thanks,
Kireeti.
-------
Finished Last Call in MPLS and CCAMP WGs
draft-ietf-mpls-generalized-cr-ldp-05.txt
draft-ietf-mpls-generalized-rsvp-te-06.txt
draft-ietf-mpls-generalized-signaling-07.txt
have implementation status, so ready for IETF Last Call

Call for consensus to send to IETF Last Call
draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  -- informational
draft-ietf-ccamp-gmpls-architecture-02.txt          -- informational
draft-ietf-ccamp-sdhsonet-control-00.txt            -- informational

One more WG Last Call for final changes, then IETF Last Call
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt             -- proposed standard
draft-ietf-ccamp-lmp-03.txt                         -- proposed standard

WG Last Call
draft-ietf-ccamp-gmpls-routing-02.txt               -- proposed standard
draft-ietf-ccamp-ospf-gmpls-extensions-04.txt       -- proposed standard

Call for consensus for WG Last Call
draft-ietf-ccamp-lmp-mib-01.txt ?                   -- proposed standard
draft-ietf-ccamp-lmp-wdm-00.txt                     -- proposed standard
draft-ietf-ccamp-oli-reqts-00.txt                   -- informational

Any objections to making this a WG document?
draft-fontana-ccamp-gmpls-g709-03.txt               -- proposed standard

Call for consensus to make into WG documents
draft-bellato-ccamp-g709-framework-01.txt           -- informational
draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt -- proposed standard
draft-mannie-ccamp-gmpls-lbm-tdm-01.txt             -- proposed standard
draft-mannie-gmpls-recovery-terminology-00.txt      -- informational
draft-bonica-tuntrace-02.txt                        -- informational

Update, followed by call for consensus to make WG docs
draft-nadeau-ccamp-gmpls-label-mib-01.txt           -- proposed standard
draft-nadeau-ccamp-gmpls-lsr-mib-01.txt             -- proposed standard
draft-nadeau-ccamp-gmpls-tc-mib-01.txt              -- proposed standard
draft-nadeau-ccamp-gmpls-te-mib-01.txt              -- proposed standard

Call for Design Team for "GMPLS Profile for ASON/ASTN"
  -- understand more clearly what needs to be done here
  -- figure out if a design team is needed (or just a set of IDs)
  -- figure out where this work should be done (CCAMP vs. IPO vs. ...)

Delivery-date: Tue, 19 Mar 2002 08:10:08 -0800
From: [email-masked]
Subject: Re: GMPLS Implementation Survey
To: "[email-masked]'" <[email-masked]>, Mark_Seery <[email-masked]>
Date: Tue, 19 Mar 2002 17:09:37 +0100

[ post by non-subscriber ]

Did anyone catch the URL for the GMPLS implementation survey presented
during CCAMP WG last night?

Try
http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signaling-survey-00.txt

Thanks,
-mark.s.

@+ manu

Delivery-date: Tue, 19 Mar 2002 08:04:02 -0800
From: Mark_Seery <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: GMPLS Implementation Survey
Date: Tue, 19 Mar 2002 07:53:29 -0800

[ post by non-subscriber ]

Did anyone catch the URL for the GMPLS implementation survey presented
during CCAMP WG last night?

Thanks,
-mark.s.

Delivery-date: Mon, 18 Mar 2002 18:24:41 -0800
Date: Mon, 18 Mar 2002 19:21:32 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>, Wesam Alanqar <[email-masked]>
Subject: URLs & Contact Info from ITU-T Presentation

All,
The Representative from ITU-T to ITU-T Study Group 15 is:
Wesam Alanqar
[email-masked]

The key URLs with the communications from ITU-T Study Group 15 to ccamp
are:

ITU-T FTP Site:
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html

IETF Liaison Page:
http://www.ietf.org/IESG/liaison.html

Several of the documents are in MS Word format, and therefore only appear on
the ITU-T site.

I have sent a copy of the slides to Kireeti to put on the web.
Regards,
Steve

Delivery-date: Mon, 18 Mar 2002 13:14:30 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Lou Berger <[email-masked]>, [email-masked]
Subject: RE: new draft Generalized MPLS Signaling - Implementation Survey
Date: Mon, 18 Mar 2002 22:13:32 +0100

Thanks

Bert 

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Monday, March 18, 2002 8:05 PM
> To: [email-masked]
> Subject: Fwd: new draft Generalized MPLS Signaling - Implementation
> Survey
> 
> 
> FYI - the survey has been submitted...
> 
> Thanks to all who participated!
> 
> Lou
> 
> >Date: Fri, 15 Mar 2002 17:18:00 -0500
> >To: [email-masked]
> >From: Lou Berger <[email-masked]>
> >Subject: new draft Generalized MPLS Signaling - Implementation Survey
> >Cc: [email-masked], Kireeti Kompella <[email-masked]>
> >
> >Hi,
> >         We would like to submit a new draft,
> >"Generalized MPLS Signaling - Implementation Survey".  We suggest
> >the name "draft-ietf-ccamp-gmpls-signaling-survey-00.txt".  This
> >has been approved by Kireeti, a CCAMP WG chair.  The information
> >on the draft is listed below, and the draft itself is available at:
> >(assuming you approve of the name.)
> >http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signa
ling-survey-00.txt
>
>Thank you,
>Lou and Yakov.
>
>
>============================================
>Network Working Group                        Lou Berger (Movaz) - Editor
>Internet Draft                          Yakov Rekhter (Juniper) - Editor
>Expiration Date: September 2002
>
>                                                               March 2002
>
>
>            Generalized MPLS Signaling - Implementation Survey
>
>
>Abstract
>
>    This document provides a survey of GMPLS signaling implementations.
>    The primary focus of this survey are the signaling protocol
>    mechanisms specified in [GMPLS-SIG], [GMPLS-RSVP], [GMPLS-LDP] and
>    [GMPLS-SONET].  Other specifications and documents are listed if
>    included in the submitted form.  The survey form and latest version
>    of this document are available from http://www.labn.net/gmpls-survey.
>
>
>

Delivery-date: Mon, 18 Mar 2002 12:57:09 -0800
From: Fugui Wang <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Comments on LMP draft 3
Date: Mon, 18 Mar 2002 15:54:41 -0500

Hello Jonathan,

Here are some comments regarding draft-ietf-ccamp-lmp-03.txt:

1. In page 5, section 3:
"Rather, a node-wide unique 32-bit non-zero integer control channel
identifier
CCId) is assigned at each end of the control channel. This identifier comes
from the same space as the unnumbered interface Id."

If the control channel is directly on ethernet instead of point-to-point 
interface or IP tunnel, what should be chosen as the CCId?
For example, in the following case, if Node A, B, C are connected by 
ethernet. Node B should have a control channel to A and C respectively.
What should be the CCIds for these two control channels? In this case
interface ID is not able to uniquely identify the control channel.  

    .1                  .2                     .3    10.1.1.0/24
----+--------------------+----------------------+--------------
    |                    +                      |
+---+---+            +---+----+            +----+----+
|ifId=2 |            | ifId=3 |            |  ifId=4 |
|   A   |            |   B    |            |    C    |
|       |            |        |            |         |
+-------+            +--------+            +---------+

2. In page 9, section 3.2:
"The LMP Hello protocol is intended to be a lightweight 
 keep-alive mechanism that will react to control channel failures 
 rapidly so that IGP Hellos are not lost and the associated link-
 state adjacencies are not removed unnecessarily."

I don't quite understand how LMP hello could prevent IGP hello lost.
My understading is: as far as there is at least
one contral channel active between the neighbor, IGP won't remove the
link-state adjacency, even without LMP detecting the control channel
failure.
Is that right? 

3. In page 9, section 3.2.1:
"If the fast keep-alive mechanism of LMP is not used, the 
 HelloInterval and HelloDeadInterval parameters MUST be set to zero."

This paragraph says that the Hello could be optional. However, in the
Control channel FSM, it seems that this case is not considered.

Thanks,
Fugui

Envelope-to: [email-masked]
Delivery-date: Mon, 18 Mar 2002 12:05:41 -0800
Date: Mon, 18 Mar 2002 12:04:42 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Agenda update

Agenda bashing and status update -- 15 min
	Blue sheets, minutes takers

Steve Trowbridge -- 10 min
	ITU-T update

Lou Berger -- 5 min
	GMPLS implementation survey

P & R DT (Mannie) -- 15 min
	Members, charter, status
	draft-mannie-gmpls-recovery-terminology-00.txt

Cheng-Yin Lee -- 5 min
	draft-lee-rsvp-te-xro-00.txt

Kohei Shiomoto -- 5 min
	draft-shiomoto-ccamp-multiarea-te-00.txt

Wataru Imajuku -- 5 min
	draft-imajuku-ml-routing-01.txt

Ash, Gerald -- 5 (multiarea)

Multiarea discussion -- 10 min

Mannie, Eric -- 15 min
	draft-ietf-ccamp-gmpls-architecture-02.txt
	draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
	draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt

[email-masked] -- 15 min
	draft-ietf-ccamp-gmpls-g709-00.txt
	draft-mannie-ccamp-gmpls-lbm-tdm-01.txt
	draft-ansorge-ccamp-lmp-sonet-sdh-00.txt

Osama Aboul-Magd -- 5 min
	draft-aboulmagd-ccamp-call-conn-separation-00.txt.

Jonathan Lang -- 5 min
	draft-ietf-ccamp-lmp-03.txt

Ron Bonica -- 5 min
	draft-bonica-tunneltrace-02.txt

Yoshihiko SUEMURA -- 5 min
	draft-suemura-gmpls-restoration-signaling-00.txt
	draft-suemura-protection-hierarchy-00.txt

Dimitri -- 10 min
	draft-design-team-ccamp-recovery-analysis-00.txt

Kohei Shiomoto -- time permitting
	discussion on draft-matsuura-gmpls-rsvp-requirements-00.txt

Delivery-date: Mon, 18 Mar 2002 11:07:05 -0800
Date: Mon, 18 Mar 2002 14:05:09 -0500
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: Fwd: new draft Generalized MPLS Signaling - Implementation Survey

FYI - the survey has been submitted...

Thanks to all who participated!

Lou

>Date: Fri, 15 Mar 2002 17:18:00 -0500
>To: [email-masked]
>From: Lou Berger <[email-masked]>
>Subject: new draft Generalized MPLS Signaling - Implementation Survey
>Cc: [email-masked], Kireeti Kompella <[email-masked]>
>
>Hi,
>         We would like to submit a new draft,
>"Generalized MPLS Signaling - Implementation Survey".  We suggest
>the name "draft-ietf-ccamp-gmpls-signaling-survey-00.txt".  This
>has been approved by Kireeti, a CCAMP WG chair.  The information
>on the draft is listed below, and the draft itself is available at:
>(assuming you approve of the name.)
>http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signaling-survey-00.txt
>
>Thank you,
>Lou and Yakov.
>
>
>============================================
>Network Working Group                        Lou Berger (Movaz) - Editor
>Internet Draft                          Yakov Rekhter (Juniper) - Editor
>Expiration Date: September 2002
>
>                                                               March 2002
>
>
>            Generalized MPLS Signaling - Implementation Survey
>
>
>Abstract
>
>    This document provides a survey of GMPLS signaling implementations.
>    The primary focus of this survey are the signaling protocol
>    mechanisms specified in [GMPLS-SIG], [GMPLS-RSVP], [GMPLS-LDP] and
>    [GMPLS-SONET].  Other specifications and documents are listed if
>    included in the submitted form.  The survey form and latest version
>    of this document are available from http://www.labn.net/gmpls-survey.
>
>
>

Delivery-date: Mon, 18 Mar 2002 08:32:50 -0800
From: Jonathan Lang <[email-masked]>
To: 'S Ramesh' <[email-masked]>, [email-masked]
Cc: Bala Rajagopalan <[email-masked]>
Subject: RE: LMP Comments?
Date: Mon, 18 Mar 2002 08:22:18 -0800

Ramesh,
  Thanks for the catching the bad edits.  Further clarifications inline.

-Jonathan

> -----Original Message-----
> From: S Ramesh [mailto:[email-masked]]
> Sent: Sunday, March 17, 2002 4:33 AM
> To: [email-masked]
> Cc: Jonathan Lang; Bala Rajagopalan
> Subject: LMP Comments?
> 
> 
> Hi,
> 
> 1. The ConfigNack Object has the Config object inclusion in the Nack
> message as optional.[<CONFIG>]. This will be mandatory right, since
> there is no error code, when a Nack arrives, for a negotiable Config
> or non-negotiable Config, the Config Object MUST be included and hence
> mandatory.
Correct.  Config object is mandatory in ConfigNack object.

> 
> 2. Some paragraphs of section 13.4.3 still speaks about the error
> code. Hope missed out while editing.
Correct.  Text referring to Error Codes will be removed.

> 
> 3. Already mentioned about similarities with OIF UNI 1.0. There it is
> mentioned CCID == InterfaceID in in-fiber case. This draft also speaks
> about in-fiber case in Section 3. According to this draft,  CCID is a
> 32 bit number and Interface ID can be 32 bit( IPv4 or unnumbered ) or
> 128 bit
> ( IPv6 ).  OIF UNI is mentioning to refer IETF LMP for message
> formats. So how can a 32 bit number be matched with a 128bit number?
> Is this question is meaningful or am i missing something? Since OIF
> UNI is mentioning IETF LMP for message formats am cross posting in
> this list. Kindly clarify me in this regard.
The CCID is defined as a 32-bit number.  For in-fiber control channels where
the interfaces are IPv4 addresses, these could be the same.

> 
> Thanks,
> Ramesh
> 

Delivery-date: Sun, 17 Mar 2002 04:32:18 -0800
Date: Sun, 17 Mar 2002 18:03:14 +0530
From: S Ramesh <[email-masked]>
Organization: HCL Technologies Limited
To: "[email-masked]" <[email-masked]>
CC: Jonathan Lang <[email-masked]>, Bala Rajagopalan <[email-masked]>
Subject: LMP Comments?

Hi,

1. The ConfigNack Object has the Config object inclusion in the Nack
message as optional.[<CONFIG>]. This will be mandatory right, since
there is no error code, when a Nack arrives, for a negotiable Config
or non-negotiable Config, the Config Object MUST be included and hence
mandatory.

2. Some paragraphs of section 13.4.3 still speaks about the error
code. Hope missed out while editing.

3. Already mentioned about similarities with OIF UNI 1.0. There it is
mentioned CCID == InterfaceID in in-fiber case. This draft also speaks
about in-fiber case in Section 3. According to this draft,  CCID is a
32 bit number and Interface ID can be 32 bit( IPv4 or unnumbered ) or
128 bit
( IPv6 ).  OIF UNI is mentioning to refer IETF LMP for message
formats. So how can a 32 bit number be matched with a 128bit number?
Is this question is meaningful or am i missing something? Since OIF
UNI is mentioning IETF LMP for message formats am cross posting in
this list. Kindly clarify me in this regard.

Thanks,
Ramesh

Delivery-date: Sat, 16 Mar 2002 23:41:23 -0800
content-class: urn:content-classes:message
Subject: RE: CCAMP 53 agenda
Date: Sat, 16 Mar 2002 19:03:00 -0500
From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>

>=20
> Ash, Gerald -- 5 (multiarea)
>=20
The Internet Draft for this agenda item is
draft-ash-multi-area-te-compare-00.txt
http://search.ietf.org/internet-drafts/draft-ash-multi-area-te-compare-00=
.txt

Jerry Ash

Envelope-to: [email-masked]
Delivery-date: Fri, 15 Mar 2002 19:01:23 -0800
Date: Fri, 15 Mar 2002 18:13:46 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: CCAMP 53 agenda

Hi All,

Here is the CCAMP agenda for next week.

Speakers, please remember to keep to a very few slides (2-5), and
discuss just the basic issues.

Audience, please remember that the speakers are going to assume
that you've read the drafts, and will not be giving a tutorial on
the material.

Thanks!

Kireeti and Ron.
---------------

Agenda bashing and status update -- 15 min
	Blue sheets, minutes takers

Steve Trowbridge -- 10 min
	ITU-T update, communications

P & R DT -- 10 min
	Members, charter, status

Cheng-Yin Lee -- 5 min
	draft-lee-rsvp-te-xro-00.txt

Kohei Shiomoto -- 5 min
	draft-shiomoto-ccamp-multiarea-te-00.txt

Wataru Imajuku -- 5 min
	draft-imajuku-ml-routing-01.txt

Ash, Gerald -- 5 (multiarea)

Multiarea discussion -- 10 min

Mannie, Eric -- 20 min
	draft-ietf-ccamp-gmpls-architecture-02.txt
	draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
	draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt
	draft-mannie-ccamp-gmpls-lbm-tdm-01.txt

[email-masked] -- 5 min
	draft-ietf-ccamp-gmpls-g709-00.txt

Osama Aboul-Magd -- 5 min
	draft-aboulmagd-ccamp-call-conn-separation-00.txt.

Jonathan Lang -- 5 min
	draft-ietf-ccamp-lmp-03.txt

Andre/Jonathan -- 5 min
	draft-ietf-ccamp-lmp-wdm-00.txt

Dimitri Papadimitriou -- 5 min
	draft-ansorge-ccamp-lmp-sonet-sdh-00.txt

Adrian Farrel -- 10 min
	draft-nadeau-ccamp-gmpls-tc-mib-01.txt
	draft-nadeau-ccamp-gmpls-label-mib-01.txt
	draft-nadeau-ccamp-gmpls-te-mib-01.txt
	draft-nadeau-ccamp-gmpls-lsr-mib-01.txt

Ron Bonica -- 5 min
	draft-bonica-tunneltrace-02.txt

Yoshihiko SUEMURA -- 5 min
	draft-suemura-gmpls-restoration-signaling-00.txt
	draft-suemura-protection-hierarchy-00.txt

Sudheer -- 10 min
	draft-design-team-ccamp-recovery-analysis-00.txt

MATSUURA Nobuaki -- time permitting
	discussion on draft-matsuura-gmpls-rsvp-requirements-00.txt

Delivery-date: Fri, 15 Mar 2002 14:57:41 -0800
From: Jun Yu <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: FW: path TLV & srlg TLV
Date: Fri, 15 Mar 2002 17:56:19 -0500

No. I don't think so. 

But what I want to point out is,

(1). There is inconsistency between "LSP Hierarchy with Generalized MPLS TE"
and 
"Generalized Multi-Protocol Label Switching (GMPLS) Architecture" on this
matter 
(whether to use path TLV or SRLG TLV in FA advertisement).

(2). If we only advertise Path Information for the FA, then the SRLG
information of the FA 
can be derived, just as you specified in the "LSP Hierarchy" draft, it is
"the union of the 
SRLGs of the underlying TE links that make up the FA-LSP path".

On the other hand, if we only advertise SRLG Information for the FA, then
the FA-LSP's path 
information becomes opaque to all the LSRs other than the headend LSR. This
makes it difficult 
for the LSR to make a routing decision with "Link", or "Node" diversity
requirement.

Thanks.

-Jun

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Friday, March 15, 2002 5:05 PM
> To: Jun Yu
> Cc: [email-masked]'
> Subject: Re: FW: path TLV & srlg TLV
> 
> 
> 
> 
> On Fri, 15 Mar 2002, Jun Yu wrote:
> 
> > > Section 4.1.10, the context is changed to "SRLG 
> Information" from the
> > > previous "Path Information".
> 
> Do you think it is useful to include both SRLG and Path information?
> 
> Kireeti.
> 

Delivery-date: Fri, 15 Mar 2002 14:06:58 -0800
Date: Fri, 15 Mar 2002 14:04:58 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Jun Yu <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: FW: path TLV & srlg TLV

On Fri, 15 Mar 2002, Jun Yu wrote:

> > Section 4.1.10, the context is changed to "SRLG Information" from the
> > previous "Path Information".

Do you think it is useful to include both SRLG and Path information?

Kireeti.

Delivery-date: Fri, 15 Mar 2002 10:48:20 -0800
content-class: urn:content-classes:message
Subject: RE: MPLS OAM & the IETF
Date: Fri, 15 Mar 2002 13:46:43 -0500
From: "Cuevas, Enrique G, ALASO" <[email-masked]>
To: <[email-masked]>
Cc: "Scott  Bradner" <[email-masked]>

I vote for option 1.
The IETF should continue to work on IP-centric tools needed for basic IP =
services.
The ITU should work on the comprehensive set of OAM tools that are =
needed to make MPLS a robust platform infrastructure capable of =
supporting multi-services. After all, the ITU has developed Operations =
and Maintenance standards for ATM, Frame Relay, SDH, ISDN, optical =
fibers, etc. MPLS equipment vendors should become more involved in the =
related ITU work.

However, clear channels of cooperation between IETF/ITU are needed and =
we are waiting for our AD to provide a more precise statement on how =
this will be achieved.

Enrique=20

AT&T Labs

Delivery-date: Fri, 15 Mar 2002 08:51:36 -0800
Date: Fri, 15 Mar 2002 11:49:32 -0500
To: [email-masked], Kireeti Kompella <[email-masked]>, [email-masked]
From: Lou Berger <[email-masked]>
Subject: Proposed change to draft-ietf-ccamp-ospf-gmpls-extensions-04.txt 
Cc: "Dan Dovolsky" <[email-masked]>

Kireeti, Yakov, other authors...

We propose the changes to the draft identified below with change bars.  (To 
address advertisement of discrete allocation bandwidths.)

What do you think?

Thanks,
Lou and Dan
--------------------------------------------------------------------

5.5. Interface Switching Capability Descriptor

    The Interface Switching Capability Descriptor is a sub-TLV of the
    Link TLV with type 15. The length is the length of value field in
    octets.  The format of the value field is as shown below:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    | Switching Cap |   Encoding    |   Reserved    | Priority Mask |
  |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    |                  Max LSP Bandwidth                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Switching Capability-specific information              |
       |                  (variable)                                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The Switching Capability (Switching Cap) field contains one of the
    following values:
            1     Packet-Switch Capable-1 (PSC-1)
            2     Packet-Switch Capable-2 (PSC-2)
            3     Packet-Switch Capable-3 (PSC-3)
            4     Packet-Switch Capable-4 (PSC-4)
            51    Layer-2 Switch Capable  (L2SC)
            100   Time-Division-Multiplex Capable (TDM)
            150   Lambda-Switch Capable   (LSC)
            200   Fiber-Switch Capable    (FSC)

    The Encoding field contains one of the values specified in Section
    3.1.1 of [GMPLS-SIG].

  | Priority mask identifies the priorities levels at which Maximum LSP
  | Bandwidth is available.  Bit 0 identifies priority 0, bit 7
  | identifies priority 7.
  |
  | Maximum LSP Bandwidth is encoded as 4 octet field in
  | the IEEE floating point format. The units are bytes (not bits!) per
  | second.

    The content of the Switching Capability specific information field
    depends on the value of the Switching Capability field.

    When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4,
    the specific information includes Interface MTU, Minimum LSP
    Bandwidth, and padding. The Interface MTU is encoded as a 2 octets
    integer. The Minimum LSP Bandwidth is is encoded in a 4 octets field
    in the IEEE floating point format. The units are bytes (not bits!)
    per second. The padding is 2 octets, and is used to make the
    Interface Switching Capability Descriptor sub-TLV 32-bits aligned.

    When the Switching Capability field is L2SC, there is no specific
    information.

    When the Switching Capability field is TDM, the specific information
    includes Minimum LSP Bandwidth, an indication whether the interface
    supports Standard or Arbitrary SONET/SDH, and padding. The Minimum
    LSP Bandwidth is encoded in a 4 octets field in the IEEE floating
    point format. The units are bytes (not bits!) per second. The
    indication whether the interface supports Standard or Arbitrary
    SONET/SDH is encoded as 1 octet. The value of this octet is 0 if the
    interface supports Standard SONET/SDH, and 1 if the interface
    supports Arbitrary SONET/SDH.  The padding is 3 octets, and is used
    to make the Interface Switching Capability Descriptor sub-TLV 32-bits
    aligned.

    When the Switching Capability field is LSC, there is no specific
    information.

    The Interface Switching Capability Descriptor sub-TLV may occur more
  | than once within the Link TLV.  This is used to handle interfaces
  | that support multiple switching capabilities, for interfaces
  | that have Max LSP Bandwidth values that differ by priority level,
  | and for interfaces that support discrete bandwidths.

Delivery-date: Fri, 15 Mar 2002 08:24:13 -0800
From: Jonathan Lang <[email-masked]>
To: 'Su-Hun YUN' <[email-masked]>, [email-masked]
Subject: RE: LMP question
Date: Fri, 15 Mar 2002 08:16:52 -0800

Su-Hun,
  This was an editorial mistake and will be added to IPv4 and IPv6 C-types.

Thanks,
Jonathan

> -----Original Message-----
> From: Su-Hun YUN [mailto:[email-masked]]
> Sent: Thursday, March 14, 2002 10:10 PM
> To: [email-masked]
> Subject: LMP question
> 
> 
> [ post by non-subscriber ]
> 
> Hi there,
> 
> In the draft-ietf-ccamp-lmp-03.txt, direction bit to the 
> Channel_Status
> object was added.
> 
> However it added only to Unnumbered (C-type=3) but not to 
> IPv4 (C-type=1)
> and IPv6 (C-type=2).  Why so?
> 
> And D (direction) bit was added only to the last Channel_Status field
> and not to all Channel_Status field. Is there any reason for that?
> (Then, the last Channel_Status field should be 30 bit anyway)
> 
> Regards,
> 
> 
> -------
> Su-Hun YUN <[email-masked]>
> 1st Optical Network Division
> NEC Corp. Japan
> 
> 
> 

Delivery-date: Fri, 15 Mar 2002 08:18:30 -0800
From: Jun Yu <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: FW: path TLV & srlg TLV
Date: Fri, 15 Mar 2002 11:16:32 -0500

> I have a question regarding the latest version of "LSP Hierarchy with
> Generalized MPLS TE". 
> 
> Section 4.1.10, the context is changed to "SRLG Information" from the
> previous "Path Information".
> 
> Is  it the intention  of the WG to advertise only SRLG info in the OSPF
> LSA (for example) using SRLG sub-TLV, instead of the previous way of
> advertising path information using Path sub-TLV?
> 
> I have the confusion because the latest version of "Generalized
> Multi-Protocol Label Switching (GMPLS) Architecture" (March 02) still
> talks about path TLV in section 10.1 "Routing and Forwarding Adjacencies".
> 
> Could somebody please clarify this?
> 
> Also, if only the SRLG information is advertised, then does it implies
> that GMPLS will only support SRLG diversity? Because without the path
> information, Link diversity and Node diversity (as specified in OIF UNI
> 1.0) will not be possible when doing source routing.
> 
> Thanks.
> 
-Jun Yu
Firstwave Intelligent Optical Networks,
(301) 345 2137

>   
> 

Delivery-date: Fri, 15 Mar 2002 05:45:34 -0800
content-class: urn:content-classes:message
Subject: RE: Notify Message in GMPLS
Date: Fri, 15 Mar 2002 08:40:36 -0500
From: "George Young" <[email-masked]>
To: "manoj juneja" <[email-masked]>, <[email-masked]>

Hello manoj,

See below:

>-----Original Message-----
>From: manoj juneja [mailto:[email-masked]]
>Sent: Thursday, March 14, 2002 3:38 PM
>To: [email-masked]
>Subject: Notify Message in GMPLS
>
>
>[ post by non-subscriber ]
>
>Hi All,
>
>Section 4.2.2 of the gmpls-rsvp-te daft mentions that
>"the inclusion of a Notify Request object does not guarantee=20
>that a Notify=20
>message will be generated".
>
>This means that it is an optional procedure as per the drafts.
>
>Is there any real technical reason for introducing this=20
>message in GMPLS=20
>drafts ?=20

We're planning to use the NOTIFY message to indicate path failure to the
head and the tail of an optical path, to intiate cutover to a backup
path.

Regards,
George R. Young.
Meriton Networks Inc.
3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9628
email: [email-masked]

>What will be the criteria for a node to insert a=20
>notify request=20
>object in path/resv message ?
>
>Thanks in Advance,
>Regards,
>manoj.
>
>_________________________________________________________________
>MSN Photos is the easiest way to share and print your photos:=20
>http://photos.msn.com/support/worldwide.aspx
>
>
>
>

Delivery-date: Fri, 15 Mar 2002 02:25:34 -0800
Date: Fri, 15 Mar 2002 15:09:44 +0900
From: Su-Hun YUN <[email-masked]>
To: [email-masked]
Subject: LMP question

[ post by non-subscriber ]

Hi there,

In the draft-ietf-ccamp-lmp-03.txt, direction bit to the Channel_Status
object was added.

However it added only to Unnumbered (C-type=3) but not to IPv4 (C-type=1)
and IPv6 (C-type=2).  Why so?

And D (direction) bit was added only to the last Channel_Status field
and not to all Channel_Status field. Is there any reason for that?
(Then, the last Channel_Status field should be 30 bit anyway)

Regards,

-------
Su-Hun YUN <[email-masked]>
1st Optical Network Division
NEC Corp. Japan

Delivery-date: Thu, 14 Mar 2002 20:06:40 -0800
Date: Thu, 14 Mar 2002 23:02:27 -0500
To: Jonathan Lang <[email-masked]>
From: Baktha Muralidharan <[email-masked]>
Subject: Comments on LMP
Cc: [email-masked], [email-masked]

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

Hi Jonathan

          We have the following comments on LMP draft 3:
--------------------------------------------------
1. In the current LMP draft (draft-ietf-ccamp-lmp-03.txt), section 7 talks
    about Message ID usage. It states,

             "Unacknowledged messages sent with the MESSAGE_ID object
              SHOULD be retransmitted until the message is acknowledged
              or until a retry limit is reached."

    What are the subsequent actions that need to take place when the
    above conditions occur ?

2. When Nacking a link summary, the current message format doesn't allow 
indicate
    what's wrong with each interface mapping.. "per-interface" error codes 
would
    be helpful. i.e. The TE link and each data link object in the Nack message
    needs an error code to localize the failure.

3. When a channel status msg is received with message ID less than
an earlier (TE-Link) message, it might still be accepted per the
draft. So, in the case where it is accepted, should the accepted
    message ID become the basis for all future message ID (validations)?

4. CC ID can be numbered (i.e. IPv4 format) per OIF/OUNI. However, the 
current LMP
    draft does not support it.

------------------------------------------------------------
Thanks,

/Baktha Muralidharan
Cisco Systems, Inc.
Chelmsford, MA.
--=====================_5373146==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Hi Jonathan<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; We have the following
comments on LMP draft 3:<br>
--------------------------------------------------<br>
<font face="Courier New, Courier">1. In the current LMP draft
(draft-ietf-ccamp-lmp-03.txt), section 7 talks<br>
&nbsp;&nbsp; about Message ID usage. It states,<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;Unacknowledged messages sent with the MESSAGE_ID object <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SHOULD be retransmitted until the message is acknowledged<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
or until a retry limit is reached.&quot;<br>
<br>
&nbsp;&nbsp; What are the subsequent actions that need to take place when
the<br>
&nbsp;&nbsp; above conditions occur ?<br>
<br>
2. When Nacking a link summary, the current message format doesn’t allow
indicate<br>
&nbsp;&nbsp; what's wrong with each interface mapping..
&quot;per-interface&quot; error codes would<br>
&nbsp;&nbsp; be helpful. i.e. The TE link and each data link object in
the Nack message<br>
&nbsp;&nbsp; needs an error code to localize the failure.<br>
<br>
3. When a channel status msg is received with message ID less than<br>
an earlier (TE-Link) message, it might still be accepted per the <br>
draft. So, in the case where it is accepted, should the accepted<br>
&nbsp;&nbsp; message ID become the basis for all future message ID
(validations)?<br>
&nbsp; <br>
4. CC ID can be numbered (i.e. IPv4 format) per OIF/OUNI. However, the
current LMP<br>
&nbsp;&nbsp; draft does not support it.<br>
<br>
</font>------------------------------------------------------------<br>
Thanks,<br>
<br>
/Baktha Muralidharan<br>
Cisco Systems, Inc.<br>
Chelmsford, MA.</html>

--=====================_5373146==_.ALT--

Delivery-date: Thu, 14 Mar 2002 15:05:48 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Notify Message in GMPLS
Date: Thu, 14 Mar 2002 13:38:08 -0700

[ post by non-subscriber ]

Hi All,

Section 4.2.2 of the gmpls-rsvp-te daft mentions that
"the inclusion of a Notify Request object does not guarantee that a Notify 
message will be generated".

This means that it is an optional procedure as per the drafts.

Is there any real technical reason for introducing this message in GMPLS 
drafts ? What will be the criteria for a node to insert a notify request 
object in path/resv message ?

Thanks in Advance,
Regards,
manoj.

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Delivery-date: Thu, 14 Mar 2002 08:34:40 -0800
content-class: urn:content-classes:message
Subject: RE: MPLS OAM & the IETF
Date: Thu, 14 Mar 2002 11:32:43 -0500
From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
To: "Scott  Bradner" <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>

Scott,

I prefer 2a (although option 1 is a close second).

Option 2a is what we were seeking in the BOF, and I agree with George =
that one standards body should own a core technology.  Presumable CCAMP =
(?) will be chartered to do the work, while the ITU can define =
extensions and bring them into the WG.

OTOH, option 1 appears to be a formalized agreement to split the tasks.  =
My concern is whether the required coordination will be there between =
ITU and IETF (as raised by Shahram, but not answered yet).

Any resolution that gets the requirements met with interoperable vendor =
implementations is acceptable IMO.

Jerry Ash

> 1 - split the tasks between the IETF and the ITU-T
> 2 - IETF produce standards track documents covering both areas
>  2a - trying to work with the ITU-T to produce common technology
>  2b - in competition with the ITU-T

Delivery-date: Thu, 14 Mar 2002 04:56:14 -0800
Subject: Re: Please read and comment on GMPLS P&R DT documents
To: [email-masked]
Cc: "Sudheer Dharanikota <sudheer" <[email-masked]>
From: "Mario Molinari" <[email-masked]>
Date: Thu, 14 Mar 2002 12:47:00 +0100

Hi P&R Design Team,

These are my comments on document
draft-mannie-gmpls-recovery-terminology-00.txt.

In paragraph 4.6 (Recovery types), sub-paragraphs D and E,
you state that "all these (working and recovery) LSPs/spans
must start and end at the same nodes".
In an end-to-end restoration scheme, couldn't we have LSP's
with different end nodes sharing the same restoration
resources?

For example, if restoration were pre-planned, the restoration
path computation process might select a route sharing resources
with the restoration route of other LSP's (possibly terminating
on different nodes), as long as it could guarantee that there
were no single risk affecting more than one of the LSP's using
the same restoration resource.

In paragraph 4.13 (External commands), I don't agree to some
of the terms used.

I would rename "Lockout of normal traffic" to "Forced switch
to working" and "Forced switch for normal traffic" to "Forced
switch to recovery".
I'd redefine "Lockout of normal traffic" as in the following.
"A configuration action initiated externally that results in
the normal LSP/span being temporarily unavailable to transport
traffic".
I'd also rename "Manual switch for normal traffic" into "Manual
switch to recovery", and add a "Manual switch to working", which
would be defined as in the following.
"A switch action initiated externally that switches normal
traffic (back) to the working LSP/span, unless a fault condition
exists on such LSPs/span or an equal or higher priority switch
command is in effect."

As a more general statement, it seems to me that this section
borrows from G.841 terminology, but introduces some changes
(like the ones for which I proposed an amendment). Which is the
reason for such changes, apart of the use of "recovery" instead
of "protection", which is obviously justified by the context?

Mario Molinari

Sudheer Dharanikota <[email-masked]>@ops.ietf.org on 13/03/2002 18.27.51

Sent by:  [email-masked]

To:   CCAMP WG <[email-masked]>
cc:

Subject:  Please read and comment on GMPLS P&R DT documents

Hi Folks:

Please note that the "GMPLS Protection and Restoration
Design Team"
has produced the following two documents (1st version)...

Recovery (Protection and Restoration) Terminology for GMPLS
http://search.ietf.org/internet-drafts/draft-mannie-gmpls-recovery-terminology-00.txt

Analysis for GMPLS-based Recovery Mechanisms(including
Protection and Restoration)
http://www.cs.odu.edu/~sudheer/draft-design-team-gmpls-recovery-analysis-00.txt

We request you to read and comment on them as quickly as you
can.

Regards,

GMPLS P&R Design Team

Delivery-date: Wed, 13 Mar 2002 15:33:03 -0800
From: "Richard Rabbat" <[email-masked]>
To: "'Sudheer Dharanikota'" <[email-masked]>, <[email-masked]>
Subject: RE: Please read and comment on GMPLS P&R DT documents
Date: Wed, 13 Mar 2002 15:30:40 -0800

Hi Design Team,

The following is the list of comments that I have on document:
draft-design-team-gmpls-recovery-analysis-00.txt

Comments include both substance as well as minor text corrections.

Page 2, line 53. 
- and (vertical hierarchy). Terminology used in this document is
- conforms to the one defined in [CCAMP-TERM].
+ and layering (vertical hierarchy). Terminology used in this document
+ conforms to the one defined in [CCAMP-TERM].

Page 2, line 41.
 -Signal Quality: monitors the performance of a signal. If
  the performance falls below a certain threshold a defect -
  excessive errors (EXC) or degraded signal (DEG) - is detected.

This seems to imply that signal performance monitoring only applies to
EXC and DEG. Changing the word to indicate that this is an example may
be better.

Actually, if this whole section is a re-write of SONET/SDH transport
plane capability, maybe just referencing the appropriate document makes
more sense to avoid duplication and possibly future changes in the
future from having to be constantly updated in documents.

Page 3, line 48.
-     comparing it with the expected identifier at the sink. Example,
-     the payload signal label (and the corresponding payload signal
-     mismatch detection).
+     comparing it with the expected identifier at the sink. An example
+     of payload types is the payload signal label (and the
corresponding
+     payload signal mismatch detection).

Page 3, line 54.
-   the next recovery phase) results in either:
+   the next recovery phase) result in either: 

Page 4, first paragraph.
   - Signal Fail (SF): A signal indicating the associated data has
     failed in the sense that a signal interrupting near-end defect
     condition (not being the degraded defect) is active.

Do you mean?
   - Signal Fail (SF): A signal indicating that the associated data has
     failed. This is a signal indicating that a near-end defect
     condition is active (as opposed to a degraded defect).

Page 4, line 16.
   ... In such cases, failure
   detection may be assisted by out-of-band communication, such as the
   one considered in [LMP-WDM] protocol which provides communication
   between the PXC and the OLS.

I think this should be more forcefully described. What conditions allow
for such assistance? How does the interaction between the 2 schemes
work, and what takes precedence?

Page 6, line 17.

"Too much" and "too few". It will be hard to quantify what is meant by
too much and too little information, since we do not currently discusss
information overload. Maybe we should wait for some protocol on fault
notification for protection to quantify the amount of information that
will be passed.

Page 6, line 39.

-     node) implies a consistent decisions based on the conditions for
+     node) implies that a consistent decision based on the conditions
for

Page 8, figure.

Maybe cut the figures into 2 separate figures and explain the axis for
the second figure.

Page 8, line 41
-   these operations are mostly planning time (using network planning
+   these operations are run mostly during planning time (using network
planning

Page 9, line 9
-   There are many mechanisms available allowing overbook the recovery
-   There are many mechanisms available allowing the overbooking of the
recovery

Page 9, line 15
-   best effort (recovered only if the resources are available).
-   unprotected (recovered only if the resources are available).  
It can be recovered if some restoration technique is applied.

Page 9, line 47
   Note: performance between the two approaches differs only by the
   time required for route computation and computation (and selection).

What is meant by the second computation?

---
I'll send an email later with the rest of the document, but I hope these
comments are helpful.

Richard
--
Richard Rabbat, Ph.D.
Fujitsu Laboratories of America, Inc.
595 Lawrence Expressway
Sunnyvale, CA 94085
Phone: 1-408-530-4537. Fax: 1-408-530-4515

Delivery-date: Wed, 13 Mar 2002 13:58:31 -0800
Date: Wed, 13 Mar 2002 14:53:31 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

John,
I didn't make this up - the argument was made in some earlier emails.
One example (Eric Mannie, Feb 22):
> If we change the SONET label format there are two issues:
> 
> - already used by the OIF for UNI1.0.
> - already implemented in many boxes.
For the first of these issues, we have the problem that OIF declares
as "final" an implementation agreement built around IDs that are not.
The second is the "pre-standard" implementations I referred to in
my earlier email.
I did use the word "some" since I cannot claim that this is the reason
for everyone who voted for (2), and I did not wish to attribute Eric's
arguments onto everyone else who voted for the same alternative.
Regards,
Steve

John Drake wrote:
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Wednesday, March 13, 2002 11:12 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> Snipped...
> 
> We know that one reason that (some) voted against (1) was to protect
> pre-standard implementations, which is not a valid basis for making
> standards decisions. It would be good to know if there are other
> reasons.
> 
> JD:  Oh really?  I'm counting at least two assertions here.

Delivery-date: Wed, 13 Mar 2002 13:45:28 -0800
From: "Ong, Lyndon" <[email-masked]>
To: "'Sudheer Dharanikota'" <[email-masked]>, CCAMP WG <[email-masked]>
Subject: RE: Please read and comment on GMPLS P&R DT documents
Date: Wed, 13 Mar 2002 13:43:27 -0800

Hi Sudheer & Team,

Some comments on the Analysis document:

One comment on the table on page 18: the evaluation
of robustness seems to be somewhat in conflict with
the text on robustness in Section 8.1, which notes
that the less pre-planning that is done for recovery
schemes the greater the robustness, due to the 
possibility of failures affecting both working and
recovery paths (subject to having enough resources
reserved for recovery).  Also it looks like the 
numbering is reversed from the figure on page 8.

Section 8.6.3 is a little confusing, it looks like 
some of the points are about SONET/SDH
Protection Schemes in particular, not SONET/SDH
transport in general.  I'm not sure which the section
was intended to discuss, characteristics of
SONET/SDH protection or SONET/SDH technology.

Generally like the classification of restoration 
schemes, it's basically the same as was defined in
the GMPLS Architecture - perhaps there should be
a reference to that document as well.

Cheers,

Lyndon Ong

-----Original Message-----
From: Sudheer Dharanikota [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002 9:28 AM
To: CCAMP WG
Subject: Please read and comment on GMPLS P&R DT documents

Hi Folks:

Please note that the "GMPLS Protection and Restoration
Design Team"
has produced the following two documents (1st version)...

Recovery (Protection and Restoration) Terminology for GMPLS
http://search.ietf.org/internet-drafts/draft-mannie-gmpls-recovery-terminolo
gy-00.txt

Analysis for GMPLS-based Recovery Mechanisms(including
Protection and Restoration)
http://www.cs.odu.edu/~sudheer/draft-design-team-gmpls-recovery-analysis-00.
txt

We request you to read and comment on them as quickly as you
can.

Regards,

GMPLS P&R Design Team

Delivery-date: Wed, 13 Mar 2002 13:38:42 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Wed, 13 Mar 2002 13:34:16 -0800

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002 11:12 AM
To: Kireeti Kompella
Cc: [email-masked]
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Snipped...

We know that one reason that (some) voted against (1) was to protect
pre-standard implementations, which is not a valid basis for making
standards decisions. It would be good to know if there are other
reasons.

JD:  Oh really?  I'm counting at least two assertions here.

Delivery-date: Wed, 13 Mar 2002 11:14:46 -0800
Date: Wed, 13 Mar 2002 12:11:49 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Kireeti,
>  The issue is, there
> are those who feel that there is a real reason not to do (1).  So, I
> would like to give this one more chance to get resolved.
I guess by asking for simple votes instead of diatribes, we don't know
all the reasons. Presumably everyone has a reason to have voted the way
they did.
We know that one reason that (some) voted against (1) was to protect
pre-standard implementations, which is not a valid basis for making
standards decisions. It would be good to know if there are other
reasons.
I look forward to getting this resolved in Minneapolis.
Steve

Delivery-date: Wed, 13 Mar 2002 11:02:44 -0800
Date: Wed, 13 Mar 2002 11:01:05 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Stephen Trowbridge <[email-masked]>
cc: [email-masked]
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Hi Steve,

On Tue, 12 Mar 2002, Stephen Trowbridge wrote:

> Kireeti,
> Wasn't there a default resolution indicated in your email of Feb 25?
> Kireeti Kompella wrote:
> (snip)
> > If there isn't consensus in either direction, we'll go with one
> > encoding -- that's the right thing to do in principle.
> > 
> > Kireeti.
> The way I read this, it says "If we can't agree to something
> different, we will do (1)". Did I misunderstand the earlier email?

You're right.  Others pointed out this as well.  The issue is, there
are those who feel that there is a real reason not to do (1).  So, I
would like to give this one more chance to get resolved.

Besides, if at all possible, I would prefer not to exercise a WG-chair
fiat.  If we can find no other resolution, it would be either the WG
chairs/ADs getting together and deciding what to do, or dropping the
document entirely.

Kireeti.

Delivery-date: Wed, 13 Mar 2002 09:39:42 -0800
Date: Wed, 13 Mar 2002 09:27:51 -0800
From: Sudheer Dharanikota <[email-masked]>
To: CCAMP WG <[email-masked]>
Subject: Please read and comment on GMPLS P&R DT documents

Hi Folks:

Please note that the "GMPLS Protection and Restoration
Design Team"
has produced the following two documents (1st version)...

Recovery (Protection and Restoration) Terminology for GMPLS
http://search.ietf.org/internet-drafts/draft-mannie-gmpls-recovery-terminology-00.txt

Analysis for GMPLS-based Recovery Mechanisms(including
Protection and Restoration)
http://www.cs.odu.edu/~sudheer/draft-design-team-gmpls-recovery-analysis-00.txt

We request you to read and comment on them as quickly as you
can.

Regards,

GMPLS P&R Design Team

Delivery-date: Tue, 12 Mar 2002 15:26:08 -0800
From: Randy Bush <[email-masked]>
To: [email-masked]
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 12 Mar 2002 15:24:59 -0800

> and now you know why we don't do voting in the ietf.

btw, this was not meant as a personal remark directed to anyone.  i was
merely trying to remind everyone of the wisdom of dave clark's statement.

randy

Delivery-date: Tue, 12 Mar 2002 14:45:29 -0800
From: Randy Bush <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 12 Mar 2002 14:43:54 -0800

and now you know why we don't do voting in the ietf.

randy

Delivery-date: Tue, 12 Mar 2002 14:41:35 -0800
Date: Tue, 12 Mar 2002 15:38:58 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Kireeti,
Wasn't there a default resolution indicated in your email of Feb 25?
Kireeti Kompella wrote:
(snip)
> If there isn't consensus in either direction, we'll go with one
> encoding -- that's the right thing to do in principle.
> 
> Kireeti.
The way I read this, it says "If we can't agree to something
different, we will do (1)". Did I misunderstand the earlier email?
Regards,
Steve

Kireeti Kompella wrote:
> 
> Hi All,
> 
> Here's what we got for each option:
> 
> 1) Trowbridge, Brungard, Vainshtein, Eve Varma, Natale, Juergen, Ash,
>    Aboul-Magd, Mack-Crane, Sadler, Sankaranarayanan, Yangguang,
>    Zhi-Wei Lin, Silman Lionel, Vissers, Hai Vodinh, Monica Lazer,
>    Aguirre-Torre, Kalmanek, Yates, Molinari, Caviglia, Guangzhi Li,
>    Dongmei, John Strand.
> -> 25
> 
> 2) Papadimitiriou, Mannie, Bala, Drake, Zhensheng, Kakutam, Saha,
>    Ayan Banerjee, Sudheer, Cheng, Dan Guo, TOMOHIRO OTANI, Grammel,
>    van_den_bosch, Rousseau, Dieter Beller, Gert Van Hoey, Yakov Rekhter,
>    Jonathan Lang, Lou Berger (4/2), Jim Jones, Luc Ceuppens, Hug Werner,
>    Emmanuel.Desmet.
> -> 23.5
> 
> 3) John Fee, Curtis Brownmiller.
> 
> 4) Greg, Sharma, Meehan, Lou Berger.
> 
> There were some ambiguous "votes": Lou Berger was counted in 2, as
> there wasn't much support for 4.  Meehan seemed to say that 1 was
> not acceptable in its current form, but he mentioned both 4 and 1.
> 
> If we missed your "vote", or misinterpreted it, please let us know.
> 
> Some of you have noticed that "voting" went on past the deadline.
> I haven't broken out results by dates.  The deadline was only to
> give Eric time to produce a document that matched the consensus;
> however, as there wasn't any clear consensus, Eric produced an
> interim document just so that there is a basis for discussion.
> 
> Others noticed that many folks from the same company voted the
> same way.  I didn't :-)  The IETF does not recognize companies
> when it comes to consensus decisions -- it's just individuals.
> 
> THE OUTCOME IS: no consensus.  Note that these are *not* votes.
> In a face-to-face meeting, consensus would mean that the people in
> favor of some option raised their hands, and it was obvious without
> actually counting that those were by far the biggest group.
> 
> So, on to Plan B.  A closed group, including some of the authors,
> the chairs and the ADs will meet at the IETF, and see if we can
> craft a document that those present will sign off on.  If so, that
> version will be published, and there will be a 2 week Last Call
> period after the IETF so that everyone in the CCAMP community can
> comment on the result.  Note that this Last Call will be limited
> to the SONET/SDH issue: i.e., the changes between the current
> version of the document and the new version that we (hopefully)
> will have after the IETF.
> 
> Ron and Kireeti.

Envelope-to: [email-masked]
Delivery-date: Tue, 12 Mar 2002 14:19:38 -0800
Date: Tue, 12 Mar 2002 14:18:16 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Hi All,

Here's what we got for each option:

1) Trowbridge, Brungard, Vainshtein, Eve Varma, Natale, Juergen, Ash,
   Aboul-Magd, Mack-Crane, Sadler, Sankaranarayanan, Yangguang,
   Zhi-Wei Lin, Silman Lionel, Vissers, Hai Vodinh, Monica Lazer,
   Aguirre-Torre, Kalmanek, Yates, Molinari, Caviglia, Guangzhi Li,
   Dongmei, John Strand.
-> 25

2) Papadimitiriou, Mannie, Bala, Drake, Zhensheng, Kakutam, Saha,
   Ayan Banerjee, Sudheer, Cheng, Dan Guo, TOMOHIRO OTANI, Grammel,
   van_den_bosch, Rousseau, Dieter Beller, Gert Van Hoey, Yakov Rekhter,
   Jonathan Lang, Lou Berger (4/2), Jim Jones, Luc Ceuppens, Hug Werner,
   Emmanuel.Desmet.
-> 23.5

3) John Fee, Curtis Brownmiller.

4) Greg, Sharma, Meehan, Lou Berger.

There were some ambiguous "votes": Lou Berger was counted in 2, as
there wasn't much support for 4.  Meehan seemed to say that 1 was
not acceptable in its current form, but he mentioned both 4 and 1.

If we missed your "vote", or misinterpreted it, please let us know.

Some of you have noticed that "voting" went on past the deadline.
I haven't broken out results by dates.  The deadline was only to
give Eric time to produce a document that matched the consensus;
however, as there wasn't any clear consensus, Eric produced an
interim document just so that there is a basis for discussion.

Others noticed that many folks from the same company voted the
same way.  I didn't :-)  The IETF does not recognize companies
when it comes to consensus decisions -- it's just individuals.

THE OUTCOME IS: no consensus.  Note that these are *not* votes.
In a face-to-face meeting, consensus would mean that the people in
favor of some option raised their hands, and it was obvious without
actually counting that those were by far the biggest group.

So, on to Plan B.  A closed group, including some of the authors,
the chairs and the ADs will meet at the IETF, and see if we can
craft a document that those present will sign off on.  If so, that
version will be published, and there will be a 2 week Last Call
period after the IETF so that everyone in the CCAMP community can
comment on the result.  Note that this Last Call will be limited
to the SONET/SDH issue: i.e., the changes between the current
version of the document and the new version that we (hopefully)
will have after the IETF.

Ron and Kireeti.

Delivery-date: Tue, 12 Mar 2002 10:33:12 -0800
Date: Tue, 12 Mar 2002 10:30:48 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Leen Mak suggests that I send mail to the list saying:

"we have heard you and will come back with a conclusion."

Thanks, everyone for indicating what you think should be done
with the SONET/SDH label issue.  We will let you know shortly
what we come up with, and what the next steps are.

Kireeti.

Delivery-date: Tue, 12 Mar 2002 06:26:32 -0800
Date: Tue, 12 Mar 2002 09:20:46 -0500
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: Reminder: Survey forms due tomorrow

If you wish to be included in the first draft of the GMPLS signaling 
implementation survey, please have your forms sent in by tomorrow (March 13).

Thanks,
Lou

Forms available from: http://www.labn.net/gmpls/sig-survey.txt 

Delivery-date: Mon, 11 Mar 2002 16:53:56 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Lou Berger <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked], Scott Bradner <[email-masked]>, IANA <[email-masked]>
Subject: RE: GMPLS signaling (RSVP) assignment request.
Date: Tue, 12 Mar 2002 01:53:01 +0100

> 
> PS What values would you suggest we use during the 
> interoperability testing 
> you have discussed?
> 
So that sounds like a good reason to try and convince IANA
to do the assignment earlier on.
Of course you can "test" with some temp agreed values.
I assume the testing is done in a controlled environment, right?

Bert

> At 06:50 PM 3/11/2002, Wijnen, Bert (Bert) wrote:
> >Lou, nomrally the IANA assigns such number right at the
> >time that the RFC gets published. The reason for that is
> >that they do not want to end up with assignments for
> >stuff that does not make it up to RFC.
> >
> >Bert
> >
> > > -----Original Message-----
> > > From: Lou Berger [mailto:[email-masked]]
> > > Sent: Tuesday, March 12, 2002 12:44 AM
> > > To: [email-masked]
> > > Subject: Fwd: GMPLS signaling (RSVP) assignment request.
> > >
> > >
> > > FYI
> > >
> > > >Date: Mon, 11 Mar 2002 18:39:18 -0500
> > > >To: [email-masked]
> > > >From: Lou Berger <[email-masked]>
> > > >Subject: GMPLS signaling (RSVP) assignment request.
> > > >
> > > >Hello!
> > > >
> > > >We'd like to request assignment of types defined in
> > > >draft-ietf-mpls-generalized-rsvp-te-06.  This draft has
> > > >passed WG last call and is on it's way to IESG/IETF last call.
> > > >Assignment is needed to ensure interoperability.
> > > >
> > > >Thank you,
> > > >Lou Berger (and co-authors)
> > > >
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >
> > > >RSVP related values defined in 
> draft-ietf-mpls-generalized-rsvp-te-06
> > > >with suggested values.
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >Message Types
> > > >
> > > >o Notify message (suggested Message type =21)
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >Class Types
> > > >
> > > >o RSVP_HOP (Existing C-Num 3)
> > > >   - IPv4 IF_ID RSVP_HOP (Suggested C-type =3)
> > > >   - IPv6 IF_ID RSVP_HOP (Suggested C-type =4)
> > > >
> > > >o ERROR_SPEC (Existing C-Num 6)
> > > >   - IPv4 IF_ID ERROR_SPEC (Suggested C-type =3)
> > > >   - IPv6 IF_ID ERROR_SPEC (Suggested C-type =4)
> > > >
> > > >o LABEL_REQUEST (Existing Class-Num 19)
> > > >   - Generalized_Label_Request (Suggested C-Type =4)
> > > >
> > > >o RSVP_LABEL (Existing  Class-Num 16)
> > > >   - Generalized_Label (Suggested C-Type =2)
> > > >   - Waveband_Switching_Label C-Type (Suggested C-Type =3)
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >New Class-Nums, C-Types inherited from Label object 
> (same as CNum16)
> > > >
> > > >o RECOVERY_LABEL     Class-Num of form 0bbbbbbb (suggested =34)
> > > >o SUGGESTED_LABEL    Class-Num of form 10bbbbbb (suggested =129)
> > > >o UPSTREAM_LABEL     Class-Num of form 0bbbbbbb (suggested =35)
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >New Class-Nums
> > > >
> > > >o LABEL_SET                     Class-Num of form 0bbbbbbb
> > > (suggested =36)
> > > >   - Type 1               (C-Type =1)
> > > >o ACCEPTABLE_LABEL_SET          Class-Num of form 10bbbbbb
> > > (suggested =130)
> > > >   - Type 1 Acceptable_Label_Set (C-type from label_set cnum)
> > > >o NOTIFY_REQUEST                Class-Num of form 11bbbbbb
> > > (suggested =195)
> > > >   - IPv4 Notify Request  (C-Type =1)
> > > >   - IPv6 Notify Request  (C-Type =2)
> > > >o PROTECTION                    Class-Num of form 0bbbbbbb
> > > (suggested =37)
> > > >   - Type 1               (C-Type =1)
> > > >o ADMIN STATUS                  Class-Num of form 11bbbbbb
> > > (suggested =196)
> > > >   - Type 1               (C-Type =1)
> > > >o RESTART_CAP                   Class-Num of form 10bbbbbb
> > > (suggested =131)
> > > >   - Type 1               (C-Type =1)
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >ERO/RRO subobject types
> > > >
> > > >o Label ERO subobject
> > > >   Type 3 - Label
> > > >
> > > >o Label RRO subobject
> > > >   Type 3 - Label
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >Error codes
> > > >
> > > >o "Routing problem/Label Set"
> > > (Suggested value =11)
> > > >o "Routing problem/Switching Type"
> > > (Suggested value =12)
> > > >o "Routing problem/Unacceptable label value"
> > > (Suggested value =13)
> > > >o "Routing problem/Unsupported Encoding"
> > > (Suggested value =14)
> > > >o "Routing problem/Unsupported Link Protection"
> > > (Suggested value =15)
> > > >o "Notify Error/Control Channel Active State"
> > > (Suggested value =4)
> > > >o "Notify Error/Control Channel Degraded State"
> > > (Suggested value =5)
> > > 
> >---------------------------------------------------------------------
> > > >
> > > >[related section from draft]
> > > >13. IANA Considerations
> > > >
> > > >    IANA assigns values to RSVP protocol parameters.  Within
> > > the current
> > > >    document multiple objects are defined.  Each of these
> > > objects contain
> > > >    C-Types.  This section defines the rules for the
> > > assignment of the
> > > >    related C-Type values.  This section uses the
> > > terminology of BCP 26
> > > >    "Guidelines for Writing an IANA Considerations 
> Section in RFCs"
> > > >    [BCP26].
> > > >
> > > >    As per [RFC2205], C-Type is an 8-bit number that 
> identifies the
> > > >    function of an object.  There are no range restrictions.  All
> > > >    possible values except zero are available for assignment.
> > > >
> > > >    The assignment of C-Type values of the objects 
> defined in this
> > > >    document fall into three categories.  The first category
> > > inherit C-
> > > >    Types from the Label object, i.e., object class number
> > > 16 [RSVP-TE].
> > > >    IANA is requested to institute a policy whereby all 
> C-Type values
> > > >    assign for the Label object are also assigned for 
> the following
> > > >    objects:
> > > >       o Suggested_Label    (Class-Num TBA)
> > > >       o Upstream_Label     (Class-Num TBA)
> > > >       o Recovery_Label     (Class-Num TBA)
> > > >
> > > >    The second category of objects follow independent policies.
> > > >    Specifically, following the policies outlined in 
> [BCP26], C-Type
> > > >    values in the range 0x00 - 0x3F are allocated through an IETF
> > > >    Consensus action, values in the range 00x40 - 0x5F are
> > > allocated as
> > > >    First Come First Served, and values in the range 
> 0x60 - 0x7F are
> > > >    reserved for Private Use.  This policy applies to 
> the following
> > > >    objects.
> > > >       o Label_Set          (Class-Num TBA)
> > > >       o Notify_Request     (Class-Num TBA)
> > > >       o Protection         (Class-Num TBA)
> > > >       o Admin Status       (Class-Num TBA)
> > > >       o Restart_Cap        (Class-Num TBA)
> > > >
> > > >
> > > >
> > > >Berger, et. al.
> > >   [Page 35]
> > > >Internet Draft draft-ietf-mpls-generalized-rsvp-te-06.txt
> > > November 2001
> > > >
> > > >
> > > >    The assignment of C-Type values for the remaining object, the
> > > >    Acceptable_Label_Set object, follows the assignment of
> > > C-Type values
> > > >    of the Label_Set object.  IANA is requested to 
> institute a policy
> > > >    whereby all C-Type values assigned for the Label_Set
> > > object are also
> > > >    assigned for the Acceptable_Label_Set object.
> > >
> > >
> 

Delivery-date: Mon, 11 Mar 2002 16:38:42 -0800
Date: Mon, 11 Mar 2002 19:37:23 -0500
To: "Wijnen, Bert (Bert)" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: GMPLS signaling (RSVP) assignment request.
Cc: Lou Berger <[email-masked]>, [email-masked], Scott Bradner <[email-masked]>, IANA <[email-masked]>

Bert,

         I've seen & had many conversations on this topic.  I do understand 
that IANA wants to avoid making assignments too early and ending up with 
dead/wrong assignments.  But the community needs to balance this with the 
need to support interoperability.  My experience over the years has been 
that the authors request values and some time later IANA assigns 
values.  In the mean time, early adopters agree on values, interoperate and 
deploy using these values. This is what happens so that we establish a 
"running code" endorsement and the industry can make progress.

As far as I can tell, there is no documented process being followed by IANA 
or authors, it's just the way it works.  (I went looking for a documented 
policy, and all I could find was a statement to send a request to IANA!)  I 
personally believe this "unofficial" IANA assignment process hurts the 
community, but I'm resigned to following it.  - I think it took ~18 months 
from the time I made the request until the RSVP-TE assignments were issued...

Lou

PS What values would you suggest we use during the interoperability testing 
you have discussed?

At 06:50 PM 3/11/2002, Wijnen, Bert (Bert) wrote:
>Lou, nomrally the IANA assigns such number right at the
>time that the RFC gets published. The reason for that is
>that they do not want to end up with assignments for
>stuff that does not make it up to RFC.
>
>Bert
>
> > -----Original Message-----
> > From: Lou Berger [mailto:[email-masked]]
> > Sent: Tuesday, March 12, 2002 12:44 AM
> > To: [email-masked]
> > Subject: Fwd: GMPLS signaling (RSVP) assignment request.
> >
> >
> > FYI
> >
> > >Date: Mon, 11 Mar 2002 18:39:18 -0500
> > >To: [email-masked]
> > >From: Lou Berger <[email-masked]>
> > >Subject: GMPLS signaling (RSVP) assignment request.
> > >
> > >Hello!
> > >
> > >We'd like to request assignment of types defined in
> > >draft-ietf-mpls-generalized-rsvp-te-06.  This draft has
> > >passed WG last call and is on it's way to IESG/IETF last call.
> > >Assignment is needed to ensure interoperability.
> > >
> > >Thank you,
> > >Lou Berger (and co-authors)
> > >
> > >
> > >---------------------------------------------------------------------
> > >
> > >RSVP related values defined in draft-ietf-mpls-generalized-rsvp-te-06
> > >with suggested values.
> > >
> > >---------------------------------------------------------------------
> > >Message Types
> > >
> > >o Notify message (suggested Message type =21)
> > >
> > >---------------------------------------------------------------------
> > >Class Types
> > >
> > >o RSVP_HOP (Existing C-Num 3)
> > >   - IPv4 IF_ID RSVP_HOP (Suggested C-type =3)
> > >   - IPv6 IF_ID RSVP_HOP (Suggested C-type =4)
> > >
> > >o ERROR_SPEC (Existing C-Num 6)
> > >   - IPv4 IF_ID ERROR_SPEC (Suggested C-type =3)
> > >   - IPv6 IF_ID ERROR_SPEC (Suggested C-type =4)
> > >
> > >o LABEL_REQUEST (Existing Class-Num 19)
> > >   - Generalized_Label_Request (Suggested C-Type =4)
> > >
> > >o RSVP_LABEL (Existing  Class-Num 16)
> > >   - Generalized_Label (Suggested C-Type =2)
> > >   - Waveband_Switching_Label C-Type (Suggested C-Type =3)
> > >
> > >---------------------------------------------------------------------
> > >New Class-Nums, C-Types inherited from Label object (same as CNum16)
> > >
> > >o RECOVERY_LABEL     Class-Num of form 0bbbbbbb (suggested =34)
> > >o SUGGESTED_LABEL    Class-Num of form 10bbbbbb (suggested =129)
> > >o UPSTREAM_LABEL     Class-Num of form 0bbbbbbb (suggested =35)
> > >
> > >---------------------------------------------------------------------
> > >New Class-Nums
> > >
> > >o LABEL_SET                     Class-Num of form 0bbbbbbb
> > (suggested =36)
> > >   - Type 1               (C-Type =1)
> > >o ACCEPTABLE_LABEL_SET          Class-Num of form 10bbbbbb
> > (suggested =130)
> > >   - Type 1 Acceptable_Label_Set (C-type from label_set cnum)
> > >o NOTIFY_REQUEST                Class-Num of form 11bbbbbb
> > (suggested =195)
> > >   - IPv4 Notify Request  (C-Type =1)
> > >   - IPv6 Notify Request  (C-Type =2)
> > >o PROTECTION                    Class-Num of form 0bbbbbbb
> > (suggested =37)
> > >   - Type 1               (C-Type =1)
> > >o ADMIN STATUS                  Class-Num of form 11bbbbbb
> > (suggested =196)
> > >   - Type 1               (C-Type =1)
> > >o RESTART_CAP                   Class-Num of form 10bbbbbb
> > (suggested =131)
> > >   - Type 1               (C-Type =1)
> > >
> > >---------------------------------------------------------------------
> > >ERO/RRO subobject types
> > >
> > >o Label ERO subobject
> > >   Type 3 - Label
> > >
> > >o Label RRO subobject
> > >   Type 3 - Label
> > >
> > >---------------------------------------------------------------------
> > >Error codes
> > >
> > >o "Routing problem/Label Set"
> > (Suggested value =11)
> > >o "Routing problem/Switching Type"
> > (Suggested value =12)
> > >o "Routing problem/Unacceptable label value"
> > (Suggested value =13)
> > >o "Routing problem/Unsupported Encoding"
> > (Suggested value =14)
> > >o "Routing problem/Unsupported Link Protection"
> > (Suggested value =15)
> > >o "Notify Error/Control Channel Active State"
> > (Suggested value =4)
> > >o "Notify Error/Control Channel Degraded State"
> > (Suggested value =5)
> > >---------------------------------------------------------------------
> > >
> > >[related section from draft]
> > >13. IANA Considerations
> > >
> > >    IANA assigns values to RSVP protocol parameters.  Within
> > the current
> > >    document multiple objects are defined.  Each of these
> > objects contain
> > >    C-Types.  This section defines the rules for the
> > assignment of the
> > >    related C-Type values.  This section uses the
> > terminology of BCP 26
> > >    "Guidelines for Writing an IANA Considerations Section in RFCs"
> > >    [BCP26].
> > >
> > >    As per [RFC2205], C-Type is an 8-bit number that identifies the
> > >    function of an object.  There are no range restrictions.  All
> > >    possible values except zero are available for assignment.
> > >
> > >    The assignment of C-Type values of the objects defined in this
> > >    document fall into three categories.  The first category
> > inherit C-
> > >    Types from the Label object, i.e., object class number
> > 16 [RSVP-TE].
> > >    IANA is requested to institute a policy whereby all C-Type values
> > >    assign for the Label object are also assigned for the following
> > >    objects:
> > >       o Suggested_Label    (Class-Num TBA)
> > >       o Upstream_Label     (Class-Num TBA)
> > >       o Recovery_Label     (Class-Num TBA)
> > >
> > >    The second category of objects follow independent policies.
> > >    Specifically, following the policies outlined in [BCP26], C-Type
> > >    values in the range 0x00 - 0x3F are allocated through an IETF
> > >    Consensus action, values in the range 00x40 - 0x5F are
> > allocated as
> > >    First Come First Served, and values in the range 0x60 - 0x7F are
> > >    reserved for Private Use.  This policy applies to the following
> > >    objects.
> > >       o Label_Set          (Class-Num TBA)
> > >       o Notify_Request     (Class-Num TBA)
> > >       o Protection         (Class-Num TBA)
> > >       o Admin Status       (Class-Num TBA)
> > >       o Restart_Cap        (Class-Num TBA)
> > >
> > >
> > >
> > >Berger, et. al.
> >   [Page 35]
> > >Internet Draft draft-ietf-mpls-generalized-rsvp-te-06.txt
> > November 2001
> > >
> > >
> > >    The assignment of C-Type values for the remaining object, the
> > >    Acceptable_Label_Set object, follows the assignment of
> > C-Type values
> > >    of the Label_Set object.  IANA is requested to institute a policy
> > >    whereby all C-Type values assigned for the Label_Set
> > object are also
> > >    assigned for the Acceptable_Label_Set object.
> >
> >

Delivery-date: Mon, 11 Mar 2002 15:50:51 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Lou Berger <[email-masked]>, [email-masked]
Cc: Scott Bradner <[email-masked]>, IANA <[email-masked]>
Subject: RE: GMPLS signaling (RSVP) assignment request.
Date: Tue, 12 Mar 2002 00:50:29 +0100

Lou, nomrally the IANA assigns such number right at the
time that the RFC gets published. The reason for that is
that they do not want to end up with assignments for
stuff that does not make it up to RFC.

Bert 

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Tuesday, March 12, 2002 12:44 AM
> To: [email-masked]
> Subject: Fwd: GMPLS signaling (RSVP) assignment request.
> 
> 
> FYI
> 
> >Date: Mon, 11 Mar 2002 18:39:18 -0500
> >To: [email-masked]
> >From: Lou Berger <[email-masked]>
> >Subject: GMPLS signaling (RSVP) assignment request.
> >
> >Hello!
> >
> >We'd like to request assignment of types defined in
> >draft-ietf-mpls-generalized-rsvp-te-06.  This draft has
> >passed WG last call and is on it's way to IESG/IETF last call.
> >Assignment is needed to ensure interoperability.
> >
> >Thank you,
> >Lou Berger (and co-authors)
> >
> >
> >---------------------------------------------------------------------
> >
> >RSVP related values defined in draft-ietf-mpls-generalized-rsvp-te-06
> >with suggested values.
> >
> >---------------------------------------------------------------------
> >Message Types
> >
> >o Notify message (suggested Message type =21)
> >
> >---------------------------------------------------------------------
> >Class Types
> >
> >o RSVP_HOP (Existing C-Num 3)
> >   - IPv4 IF_ID RSVP_HOP (Suggested C-type =3)
> >   - IPv6 IF_ID RSVP_HOP (Suggested C-type =4)
> >
> >o ERROR_SPEC (Existing C-Num 6)
> >   - IPv4 IF_ID ERROR_SPEC (Suggested C-type =3)
> >   - IPv6 IF_ID ERROR_SPEC (Suggested C-type =4)
> >
> >o LABEL_REQUEST (Existing Class-Num 19)
> >   - Generalized_Label_Request (Suggested C-Type =4)
> >
> >o RSVP_LABEL (Existing  Class-Num 16)
> >   - Generalized_Label (Suggested C-Type =2)
> >   - Waveband_Switching_Label C-Type (Suggested C-Type =3)
> >
> >---------------------------------------------------------------------
> >New Class-Nums, C-Types inherited from Label object (same as CNum16)
> >
> >o RECOVERY_LABEL     Class-Num of form 0bbbbbbb (suggested =34)
> >o SUGGESTED_LABEL    Class-Num of form 10bbbbbb (suggested =129)
> >o UPSTREAM_LABEL     Class-Num of form 0bbbbbbb (suggested =35)
> >
> >---------------------------------------------------------------------
> >New Class-Nums
> >
> >o LABEL_SET                     Class-Num of form 0bbbbbbb 
> (suggested =36)
> >   - Type 1               (C-Type =1)
> >o ACCEPTABLE_LABEL_SET          Class-Num of form 10bbbbbb 
> (suggested =130)
> >   - Type 1 Acceptable_Label_Set (C-type from label_set cnum)
> >o NOTIFY_REQUEST                Class-Num of form 11bbbbbb 
> (suggested =195)
> >   - IPv4 Notify Request  (C-Type =1)
> >   - IPv6 Notify Request  (C-Type =2)
> >o PROTECTION                    Class-Num of form 0bbbbbbb 
> (suggested =37)
> >   - Type 1               (C-Type =1)
> >o ADMIN STATUS                  Class-Num of form 11bbbbbb 
> (suggested =196)
> >   - Type 1               (C-Type =1)
> >o RESTART_CAP                   Class-Num of form 10bbbbbb 
> (suggested =131)
> >   - Type 1               (C-Type =1)
> >
> >---------------------------------------------------------------------
> >ERO/RRO subobject types
> >
> >o Label ERO subobject
> >   Type 3 - Label
> >
> >o Label RRO subobject
> >   Type 3 - Label
> >
> >---------------------------------------------------------------------
> >Error codes
> >
> >o "Routing problem/Label Set"                           
> (Suggested value =11)
> >o "Routing problem/Switching Type"                      
> (Suggested value =12)
> >o "Routing problem/Unacceptable label value"            
> (Suggested value =13)
> >o "Routing problem/Unsupported Encoding"                
> (Suggested value =14)
> >o "Routing problem/Unsupported Link Protection"         
> (Suggested value =15)
> >o "Notify Error/Control Channel Active State"           
> (Suggested value =4)
> >o "Notify Error/Control Channel Degraded State"         
> (Suggested value =5)
> >---------------------------------------------------------------------
> >
> >[related section from draft]
> >13. IANA Considerations
> >
> >    IANA assigns values to RSVP protocol parameters.  Within 
> the current
> >    document multiple objects are defined.  Each of these 
> objects contain
> >    C-Types.  This section defines the rules for the 
> assignment of the
> >    related C-Type values.  This section uses the 
> terminology of BCP 26
> >    "Guidelines for Writing an IANA Considerations Section in RFCs"
> >    [BCP26].
> >
> >    As per [RFC2205], C-Type is an 8-bit number that identifies the
> >    function of an object.  There are no range restrictions.  All
> >    possible values except zero are available for assignment.
> >
> >    The assignment of C-Type values of the objects defined in this
> >    document fall into three categories.  The first category 
> inherit C-
> >    Types from the Label object, i.e., object class number 
> 16 [RSVP-TE].
> >    IANA is requested to institute a policy whereby all C-Type values
> >    assign for the Label object are also assigned for the following
> >    objects:
> >       o Suggested_Label    (Class-Num TBA)
> >       o Upstream_Label     (Class-Num TBA)
> >       o Recovery_Label     (Class-Num TBA)
> >
> >    The second category of objects follow independent policies.
> >    Specifically, following the policies outlined in [BCP26], C-Type
> >    values in the range 0x00 - 0x3F are allocated through an IETF
> >    Consensus action, values in the range 00x40 - 0x5F are 
> allocated as
> >    First Come First Served, and values in the range 0x60 - 0x7F are
> >    reserved for Private Use.  This policy applies to the following
> >    objects.
> >       o Label_Set          (Class-Num TBA)
> >       o Notify_Request     (Class-Num TBA)
> >       o Protection         (Class-Num TBA)
> >       o Admin Status       (Class-Num TBA)
> >       o Restart_Cap        (Class-Num TBA)
> >
> >
> >
> >Berger, et. al.                                              
>   [Page 35]
> >Internet Draft draft-ietf-mpls-generalized-rsvp-te-06.txt  
> November 2001
> >
> >
> >    The assignment of C-Type values for the remaining object, the
> >    Acceptable_Label_Set object, follows the assignment of 
> C-Type values
> >    of the Label_Set object.  IANA is requested to institute a policy
> >    whereby all C-Type values assigned for the Label_Set 
> object are also
> >    assigned for the Acceptable_Label_Set object.
> 
> 

Delivery-date: Mon, 11 Mar 2002 15:48:14 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: MPLS OAM & the IETF 
Date: Mon, 11 Mar 2002 23:47:37 -0000

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

------_=_NextPart_001_01C1C957.1F851E40
Content-Type: text/plain;
	charset="ISO-8859-1"

Scott, I agree with the proposal below.  Noting that 1 (below) is already
completed.....but it goes further than Mina indicated (for brevity I guess)
since it also defines all the defects in terms of entry/exit criteria and
consequent actions.
BTW - I saw some mails (eg from George) saying they thought the
principles/requirements in Y.1710 were good.  And if these can be satisfied
by some other way (than Y.1711) then I guess that's fine....though clearly
not applications will demand this level of treatment (which is actually not
that complex anyway, despite what some say), even if an alternative approach
is produced.
 
If this new option 3 is not acceptable, then my vote is for the existing
option 1.
 
regards, Neil

-----Original Message-----
From: Mina Azad [mailto:[email-masked]]
Sent: 07 March 2002 17:23
To: 'Scott Bradner'; [email-masked]
Subject: RE: MPLS OAM & the IETF 

As it's been pointed out on the mailing list in a various ways, option 1 is
pragmatic but needs clarification.
I'd like to suggest a third option which is effectively  refinement to "1".
 
Option 3:
Principles of this option: Split the OAM (M stands for management and
measurement) work between ITU and ITEF with commitment on both bodies to
work towards complementing solutions, taking into consideration the core
competency of the two standard bodies and the business drivers behind the
technologies (from vendor, operator, and standards perspectives).

In specific, option 3 proposes splitting the OAM in three areas 

      1) Definition and mechanism for availability and measurement to be
handled by ITU   
      2) ad-hoc diagnostic tools for ip-centric networks to be handled by
IETF
      3) ad-hoc diagnostic and measurement tools primarily for
non-ip-centric networks to be handled by ITU         

Regards, 

Mina  Azad

------_=_NextPart_001_01C1C957.1F851E40
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<TITLE>RE: MPLS OAM & the IETF</TITLE>

<META content="MSHTML 5.00.3013.2600" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face="Comic Sans MS" size=2><SPAN 
class=960512623-11032002>Scott, I agree with the proposal below.&nbsp; Noting 
that 1 (below) is already completed.....but it goes further than Mina indicated 
(for brevity I guess) since it also defines all the defects in terms of 
entry/exit criteria and consequent actions.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS" size=2><SPAN 
class=960512623-11032002>BTW - I saw some mails (eg from George) saying they 
thought the principles/requirements in Y.1710 were good.&nbsp; And if these can 
be satisfied by some other way (than Y.1711) then I guess that's fine....though 
clearly not applications will demand this level of treatment (which is actually 
not that complex anyway, despite what some say), even if an alternative approach 
is produced.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS" size=2><SPAN 
class=960512623-11032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS" size=2><SPAN 
class=960512623-11032002>If this new option 3 is not acceptable, then my vote is 
for the existing option 1.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS" size=2><SPAN 
class=960512623-11032002>regards, Neil</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Mina Azad 
  [mailto:[email-masked]]<BR><B>Sent:</B> 07 March 2002 
  17:23<BR><B>To:</B> 'Scott Bradner'; [email-masked]<BR><B>Subject:</B> RE: 
  MPLS OAM &amp; the IETF <BR><BR></DIV></FONT>
  <DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=660375316-07032002>As it's been p</SPAN><SPAN 
  class=660375316-07032002>ointed out on the mailing list</SPAN><SPAN 
  class=660375316-07032002> in a&nbsp;</SPAN><SPAN 
  class=660375316-07032002>various ways, option 1 is pragmatic but needs 
  clarification.</SPAN></FONT></FONT></FONT></DIV>
  <DIV><SPAN class=660375316-07032002></SPAN><FONT size=2><FONT 
  color=#0000ff><FONT face=Arial><SPAN class=660375316-07032002>I'd like to 
  sug</SPAN><SPAN class=660375316-07032002>gest a third option which is 
  effectively&nbsp; refinement to "1".</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=660375316-07032002>&nbsp;</SPAN></FONT></DIV>
  <DIV><SPAN class=660375316-07032002></SPAN><FONT size=2><FONT 
  color=#0000ff><FONT face=Arial>Option 3<SPAN 
  class=660375316-07032002>:</SPAN></FONT></FONT></FONT></DIV>
  <DIV><SPAN class=660375316-07032002></SPAN><FONT size=2><FONT 
  color=#0000ff><FONT face=Arial><SPAN class=660375316-07032002>Principles of 
  this option: Split the OA<SPAN class=360451317-07032002>M</SPAN> (M stands for 
  management and measurement) wo</SPAN><SPAN class=660375316-07032002>rk between 
  IT<SPAN class=360451317-07032002>U</SPAN> and ITE<SPAN 
  class=360451317-07032002>F</SPAN> with commitment on both bodies to work 
  towards complementing solutions, taking into consideration the core competency 
  of the two standard bodies and </SPAN>the business drivers behind the 
  technologies<SPAN class=660375316-07032002> (</SPAN>from vendor, operator, and 
  standards perspective<SPAN class=660375316-07032002>s</SPAN><SPAN 
  class=660375316-07032002>)</SPAN>.</FONT></FONT></FONT></DIV>
  <DIV>
  <P><FONT face=Arial><FONT color=#0000ff><FONT size=2>I<SPAN 
  class=660375316-07032002>n specific, option 3 proposes splitting the OAM in 
  three areas </SPAN><SPAN class=660375316-07032002></FONT></FONT></FONT></P>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=080165717-06032002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1)&nbsp;<SPAN 
  class=360451317-07032002>D</SPAN>efinition and&nbsp;mechanism for availability 
  and measurement to be handled by ITU&nbsp;&nbsp; </SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=080165717-06032002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2) ad-hoc 
  diagnostic tools for ip-centric networks to be handled by 
  IETF</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=080165717-06032002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3) ad-hoc 
  diagnostic and measurement tools primarily for non-ip-centric networks to be 
  handled by ITU</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
  class=080165717-06032002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FONT></SPAN></DIV></DIV></DIV>
  <P><I><FONT face="Monotype Corsiva">Regards,</FONT></I> </P>
  <P><I><B><FONT face="Monotype Corsiva">Mina</FONT></B></I>&nbsp;<FONT 
  face="Monotype Corsiva"><SPAN class=360451317-07032002><STRONG><EM> 
  Azad</EM></STRONG></SPAN></FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1C957.1F851E40--

Delivery-date: Mon, 11 Mar 2002 15:45:43 -0800
Date: Mon, 11 Mar 2002 18:43:44 -0500
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: Fwd: GMPLS signaling (RSVP) assignment request.

FYI

>Date: Mon, 11 Mar 2002 18:39:18 -0500
>To: [email-masked]
>From: Lou Berger <[email-masked]>
>Subject: GMPLS signaling (RSVP) assignment request.
>
>Hello!
>
>We'd like to request assignment of types defined in
>draft-ietf-mpls-generalized-rsvp-te-06.  This draft has
>passed WG last call and is on it's way to IESG/IETF last call.
>Assignment is needed to ensure interoperability.
>
>Thank you,
>Lou Berger (and co-authors)
>
>
>---------------------------------------------------------------------
>
>RSVP related values defined in draft-ietf-mpls-generalized-rsvp-te-06
>with suggested values.
>
>---------------------------------------------------------------------
>Message Types
>
>o Notify message (suggested Message type =21)
>
>---------------------------------------------------------------------
>Class Types
>
>o RSVP_HOP (Existing C-Num 3)
>   - IPv4 IF_ID RSVP_HOP (Suggested C-type =3)
>   - IPv6 IF_ID RSVP_HOP (Suggested C-type =4)
>
>o ERROR_SPEC (Existing C-Num 6)
>   - IPv4 IF_ID ERROR_SPEC (Suggested C-type =3)
>   - IPv6 IF_ID ERROR_SPEC (Suggested C-type =4)
>
>o LABEL_REQUEST (Existing Class-Num 19)
>   - Generalized_Label_Request (Suggested C-Type =4)
>
>o RSVP_LABEL (Existing  Class-Num 16)
>   - Generalized_Label (Suggested C-Type =2)
>   - Waveband_Switching_Label C-Type (Suggested C-Type =3)
>
>---------------------------------------------------------------------
>New Class-Nums, C-Types inherited from Label object (same as CNum16)
>
>o RECOVERY_LABEL     Class-Num of form 0bbbbbbb (suggested =34)
>o SUGGESTED_LABEL    Class-Num of form 10bbbbbb (suggested =129)
>o UPSTREAM_LABEL     Class-Num of form 0bbbbbbb (suggested =35)
>
>---------------------------------------------------------------------
>New Class-Nums
>
>o LABEL_SET                     Class-Num of form 0bbbbbbb (suggested =36)
>   - Type 1               (C-Type =1)
>o ACCEPTABLE_LABEL_SET          Class-Num of form 10bbbbbb (suggested =130)
>   - Type 1 Acceptable_Label_Set (C-type from label_set cnum)
>o NOTIFY_REQUEST                Class-Num of form 11bbbbbb (suggested =195)
>   - IPv4 Notify Request  (C-Type =1)
>   - IPv6 Notify Request  (C-Type =2)
>o PROTECTION                    Class-Num of form 0bbbbbbb (suggested =37)
>   - Type 1               (C-Type =1)
>o ADMIN STATUS                  Class-Num of form 11bbbbbb (suggested =196)
>   - Type 1               (C-Type =1)
>o RESTART_CAP                   Class-Num of form 10bbbbbb (suggested =131)
>   - Type 1               (C-Type =1)
>
>---------------------------------------------------------------------
>ERO/RRO subobject types
>
>o Label ERO subobject
>   Type 3 - Label
>
>o Label RRO subobject
>   Type 3 - Label
>
>---------------------------------------------------------------------
>Error codes
>
>o "Routing problem/Label Set"                           (Suggested value =11)
>o "Routing problem/Switching Type"                      (Suggested value =12)
>o "Routing problem/Unacceptable label value"            (Suggested value =13)
>o "Routing problem/Unsupported Encoding"                (Suggested value =14)
>o "Routing problem/Unsupported Link Protection"         (Suggested value =15)
>o "Notify Error/Control Channel Active State"           (Suggested value =4)
>o "Notify Error/Control Channel Degraded State"         (Suggested value =5)
>---------------------------------------------------------------------
>
>[related section from draft]
>13. IANA Considerations
>
>    IANA assigns values to RSVP protocol parameters.  Within the current
>    document multiple objects are defined.  Each of these objects contain
>    C-Types.  This section defines the rules for the assignment of the
>    related C-Type values.  This section uses the terminology of BCP 26
>    "Guidelines for Writing an IANA Considerations Section in RFCs"
>    [BCP26].
>
>    As per [RFC2205], C-Type is an 8-bit number that identifies the
>    function of an object.  There are no range restrictions.  All
>    possible values except zero are available for assignment.
>
>    The assignment of C-Type values of the objects defined in this
>    document fall into three categories.  The first category inherit C-
>    Types from the Label object, i.e., object class number 16 [RSVP-TE].
>    IANA is requested to institute a policy whereby all C-Type values
>    assign for the Label object are also assigned for the following
>    objects:
>       o Suggested_Label    (Class-Num TBA)
>       o Upstream_Label     (Class-Num TBA)
>       o Recovery_Label     (Class-Num TBA)
>
>    The second category of objects follow independent policies.
>    Specifically, following the policies outlined in [BCP26], C-Type
>    values in the range 0x00 - 0x3F are allocated through an IETF
>    Consensus action, values in the range 00x40 - 0x5F are allocated as
>    First Come First Served, and values in the range 0x60 - 0x7F are
>    reserved for Private Use.  This policy applies to the following
>    objects.
>       o Label_Set          (Class-Num TBA)
>       o Notify_Request     (Class-Num TBA)
>       o Protection         (Class-Num TBA)
>       o Admin Status       (Class-Num TBA)
>       o Restart_Cap        (Class-Num TBA)
>
>
>
>Berger, et. al.                                                [Page 35]
>Internet Draft draft-ietf-mpls-generalized-rsvp-te-06.txt  November 2001
>
>
>    The assignment of C-Type values for the remaining object, the
>    Acceptable_Label_Set object, follows the assignment of C-Type values
>    of the Label_Set object.  IANA is requested to institute a policy
>    whereby all C-Type values assigned for the Label_Set object are also
>    assigned for the Acceptable_Label_Set object.

Delivery-date: Mon, 11 Mar 2002 12:06:31 -0800
From: "Vip Sharma" <[email-masked]>
To: <[email-masked]>
Cc: "'Scott Bradner'" <[email-masked]>
Subject: RE: MPLS OAM & the IETF
Date: Mon, 11 Mar 2002 14:59:17 -0500

I vote for 2. If we add the buerocracy of working with ITU we will add
significant delays. IETF should come out with solutions and then market
forces will cause them to be adopted or not. Anyway, ITU folks should
also participated (if they want) and make this a complete solution...

vip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomas D. Nadeau
Sent: Sunday, March 10, 2002 12:28 PM
To: [email-masked]
Cc: Scott Bradner
Subject: Re: MPLS OAM & the IETF

         I vote for 2.  Although I think there is room
for input in the form of requirements/requests and such
from the ITU, I think that having to interface with
the ITU for this work is going to lead to interop
problems as well as delay the work.  The IETF created the
standards for MPLS and continues to evolve the technology,
so it makes sense to me that we continue to create and evolve
the standards for managing MPLS.

         --Tom

>Scott Bradner wrote:
>
> >
> > 0/ you think I do not understand the issue
> >
> > 1/ split the tasks:  The IETF focus on the ping/traceroute
mechanisms and
> > cede to the ITU-T work on the more telco-like OAM.  In this option
the IETF
> > would publish draft-ohta-mpls-label-value-01.txt as an RFC and
assign an
> > MPLS reserved label value for use by the ITU-T to identify Y.1711
> > information.
> >
> > 2/ The IETF work on a suite of technologies ranging from the
> > ping/traceroute-like mechanisms to the more telephone system OAM
ones.  The
> > IETF could try to figure out how to do this in conjunction with the
ITU,
> > though it is a bit late for that considering the state of Y.1711, or
be in
> > competition with the ITU-T.
> >
> > So - please indicate your opinion on how the IETF should proceed
> >
> > 1 - split the tasks between the IETF and the ITU-T
> > 2 - IETF produce standards track documents covering both areas
> >   2a - trying to work with the ITU-T to produce common technology
> >   2b - in competition with the ITU-T
> >
> > In any case, it would be good to provide feedback to the ITU-T on
Y.1711 if
> > you see anything that looks broken.
> >
> > Scott (with sub-ip AD hat on)

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Mon, 11 Mar 2002 08:30:41 -0800
Date: Mon, 11 Mar 2002 08:31:04 -0800
From: Ping Pan <[email-masked]>
To: Scott Bradner <[email-masked]>
CC: [email-masked]
Subject: Re: MPLS OAM & the IETF

Scott,

Here is my view: we have been looking at this matter for a long time. As 
the same time, the data-plane problem has not gone away and is making 
every provider nervous.

Part of the culture in many standardization bodies is a tendency to 
debate and argue and raise every issue to the highest level of 
abstraction. This process has almost become one of the elegance of the 
definition of the problem rather than the actual execution of an action 
plan. IETF should avoid this.

In option 1, we will split the task among IETF and ITU. Don't think this 
will fly. First of all, we have just at least doubled our engineering 
work to solve the same problem. Second, we need to develop yet another 
plan to solve the integration problem so that the providers can actually 
  figure out what to do in case of network trouble.

Option 2 does sound a lot better, and I hope people can focus on solving 
the problem.

Regards!

- Ping

Scott Bradner wrote:

> It seems to me that there are two options on what we (the IETF) could do at
> this point.
> 
> 0/ you think I do not understand the issue
> 
> 1/ split the tasks:  The IETF focus on the ping/traceroute mechanisms and
> cede to the ITU-T work on the more telco-like OAM.  In this option the IETF
> would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an
> MPLS reserved label value for use by the ITU-T to identify Y.1711
> information.
> 
> 2/ The IETF work on a suite of technologies ranging from the
> ping/traceroute-like mechanisms to the more telephone system OAM ones.  The
> IETF could try to figure out how to do this in conjunction with the ITU,
> though it is a bit late for that considering the state of Y.1711, or be in
> competition with the ITU-T.  
> 
> So - please indicate your opinion on how the IETF should proceed
> 
> 1 - split the tasks between the IETF and the ITU-T
> 2 - IETF produce standards track documents covering both areas
>   2a - trying to work with the ITU-T to produce common technology
>   2b - in competition with the ITU-T
> 
> In any case, it would be good to provide feedback to the ITU-T on Y.1711 if
> you see anything that looks broken.
> 
> 
> Scott (with sub-ip AD hat on)
> 
> 

Delivery-date: Mon, 11 Mar 2002 07:38:28 -0800
From: "Mohammad Siddiqui" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Finding Remote IfIndex for OSPF for Unnumbered case
Date: Mon, 11 Mar 2002 15:36:25 +0000

Hi,

In ISIS, an attempt to add "Link Identifier TLV" was made to discover remote 
Link Identifier for Unnumbered Interfaces 
[draft-ietf-isis-gmpls-extensions-08.txt]. It was pointed out that ISIS 
already has an existing mechanism to exchange link identifiers - see 
draft-ietf-isis-3way-05.txt.

Any way, while we're covered well in ISIS for this purpose, I was wondering 
what is the mechanism that should be used in OSPF in this regard? Is there 
anything that exists today and we can use, or there are some plans for 
adding a new sub-TLV, similar to "Link Identifier TLV" that was added to 
ISIS?

Thanks

/MS

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Delivery-date: Mon, 11 Mar 2002 05:23:20 -0800
From: "Don Fedyk"<[email-masked]>
To: Scott  Bradner <[email-masked]>, [email-masked]
Subject: RE: MPLS OAM & the IETF
Date: Mon, 11 Mar 2002 08:18:25 -0500

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

------_=_NextPart_001_01C1C8FF.39CB3940
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Scott

I vote for 1. 

This seems to be the practical solution. Many have mentioned we 
need to keep the lines of communication open and I am for that. 
But 2a just seems too much like what we are doing right now and 
I don't think we are making progress.

Don

>1 - split the tasks between the IETF and the ITU-T
>
>2 - IETF produce standards track documents covering both areas
>  2a - trying to work with the ITU-T to produce common technology
>  2b - in competition with the ITU-T

------_=_NextPart_001_01C1C8FF.39CB3940
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: MPLS OAM &amp; the IETF</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Scott</FONT>
</P>

<P><FONT SIZE=2>I vote for 1. </FONT>
</P>

<P><FONT SIZE=2>This seems to be the practical solution. Many have mentioned we </FONT>
<BR><FONT SIZE=2>need to keep the lines of communication open and I am for that. </FONT>
<BR><FONT SIZE=2>But 2a just seems too much like what we are doing right now and </FONT>
<BR><FONT SIZE=2>I don't think we are making progress.</FONT>
</P>

<P><FONT SIZE=2>Don</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>&gt;1 - split the tasks between the IETF and the ITU-T</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;2 - IETF produce standards track documents covering both areas</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; 2a - trying to work with the ITU-T to produce common technology</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; 2b - in competition with the ITU-T</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C8FF.39CB3940--

Delivery-date: Sun, 10 Mar 2002 13:38:47 -0800
From: "Mohammad Siddiqui" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: MPLS OAM & the IETF
Date: Sun, 10 Mar 2002 21:37:01 +0000

I second this and vote for 2.

>From: "Thomas D. Nadeau" <[email-masked]>
>To: [email-masked]
>CC: Scott Bradner <[email-masked]>
>Subject: Re: MPLS OAM & the IETF
>Date: Sun, 10 Mar 2002 12:28:19 -0500
>
>
>         I vote for 2.  Although I think there is room
>for input in the form of requirements/requests and such
>from the ITU, I think that having to interface with
>the ITU for this work is going to lead to interop
>problems as well as delay the work.  The IETF created the
>standards for MPLS and continues to evolve the technology,
>so it makes sense to me that we continue to create and evolve
>the standards for managing MPLS.
>
>         --Tom
>
>
>>Scott Bradner wrote:
>>
>> >
>> > 0/ you think I do not understand the issue
>> >
>> > 1/ split the tasks:  The IETF focus on the ping/traceroute mechanisms 
>>and
>> > cede to the ITU-T work on the more telco-like OAM.  In this option the 
>>IETF
>> > would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign 
>>an
>> > MPLS reserved label value for use by the ITU-T to identify Y.1711
>> > information.
>> >
>> > 2/ The IETF work on a suite of technologies ranging from the
>> > ping/traceroute-like mechanisms to the more telephone system OAM ones.  
>>The
>> > IETF could try to figure out how to do this in conjunction with the 
>>ITU,
>> > though it is a bit late for that considering the state of Y.1711, or be 
>>in
>> > competition with the ITU-T.
>> >
>> > So - please indicate your opinion on how the IETF should proceed
>> >
>> > 1 - split the tasks between the IETF and the ITU-T
>> > 2 - IETF produce standards track documents covering both areas
>> >   2a - trying to work with the ITU-T to produce common technology
>> >   2b - in competition with the ITU-T
>> >
>> > In any case, it would be good to provide feedback to the ITU-T on 
>>Y.1711 if
>> > you see anything that looks broken.
>> >
>> > Scott (with sub-ip AD hat on)
>
>
>
>------------------------------------------------------------------------
>Mathematics is the supreme nostalgia of our time.
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Delivery-date: Sun, 10 Mar 2002 09:32:07 -0800
Date: Sun, 10 Mar 2002 12:28:19 -0500
To: [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: MPLS OAM & the IETF
Cc: Scott Bradner <[email-masked]>

         I vote for 2.  Although I think there is room
for input in the form of requirements/requests and such
from the ITU, I think that having to interface with
the ITU for this work is going to lead to interop
problems as well as delay the work.  The IETF created the
standards for MPLS and continues to evolve the technology,
so it makes sense to me that we continue to create and evolve
the standards for managing MPLS.

         --Tom

>Scott Bradner wrote:
>
> >
> > 0/ you think I do not understand the issue
> >
> > 1/ split the tasks:  The IETF focus on the ping/traceroute mechanisms and
> > cede to the ITU-T work on the more telco-like OAM.  In this option the IETF
> > would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an
> > MPLS reserved label value for use by the ITU-T to identify Y.1711
> > information.
> >
> > 2/ The IETF work on a suite of technologies ranging from the
> > ping/traceroute-like mechanisms to the more telephone system OAM ones.  The
> > IETF could try to figure out how to do this in conjunction with the ITU,
> > though it is a bit late for that considering the state of Y.1711, or be in
> > competition with the ITU-T.
> >
> > So - please indicate your opinion on how the IETF should proceed
> >
> > 1 - split the tasks between the IETF and the ITU-T
> > 2 - IETF produce standards track documents covering both areas
> >   2a - trying to work with the ITU-T to produce common technology
> >   2b - in competition with the ITU-T
> >
> > In any case, it would be good to provide feedback to the ITU-T on Y.1711 if
> > you see anything that looks broken.
> >
> > Scott (with sub-ip AD hat on)

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Sun, 10 Mar 2002 06:04:02 -0800
Date: Sun, 10 Mar 2002 09:01:28 -0500
From: Matt Squire <[email-masked]>
Reply-To: [email-masked]
To: Scott Bradner <[email-masked]>
CC: [email-masked]
Subject: Re: MPLS OAM & the IETF

A vote for (1).  The IETF should focus on the simple and ip-oriented
utilities and get the darn thing done.  The ITU should focus on the more
generic MPLS utilities which need to get done but is a larger problem.  

Certainly this might lead to interoperability problems, but I hope the
ITU will submit drafts to the IETF mailing lists for review.  Drawing on
the expertise of the IETF can help minimize the problems.  There are
also many testing labs and bakeoffs where problems can get found.  Every
extension has the possibility of creating interoperability problems yet
they seem to keep coming, so lets split it up and be done with it.

- Matt

Scott Bradner wrote:

> 
> 0/ you think I do not understand the issue
> 
> 1/ split the tasks:  The IETF focus on the ping/traceroute mechanisms and
> cede to the ITU-T work on the more telco-like OAM.  In this option the IETF
> would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an
> MPLS reserved label value for use by the ITU-T to identify Y.1711
> information.
> 
> 2/ The IETF work on a suite of technologies ranging from the
> ping/traceroute-like mechanisms to the more telephone system OAM ones.  The
> IETF could try to figure out how to do this in conjunction with the ITU,
> though it is a bit late for that considering the state of Y.1711, or be in
> competition with the ITU-T.
> 
> So - please indicate your opinion on how the IETF should proceed
> 
> 1 - split the tasks between the IETF and the ITU-T
> 2 - IETF produce standards track documents covering both areas
>   2a - trying to work with the ITU-T to produce common technology
>   2b - in competition with the ITU-T
> 
> In any case, it would be good to provide feedback to the ITU-T on Y.1711 if
> you see anything that looks broken.
> 
> Scott (with sub-ip AD hat on)

Delivery-date: Sun, 10 Mar 2002 02:36:11 -0800
Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Scott  Bradner" <[email-masked]>, <[email-masked]>
Subject: Re: MPLS OAM & the IETF
Date: Sun, 10 Mar 2002 10:27:38 -0000

2a

An old and wise consultant used to advise me that there were
management solutions to technical problems but never
technical solutions to management problems.
IETF and ITU-T are both successful organisations - else I
would never get your messages nor you mine - but with very
different ways of working and until we find a way that works
for both of us, solving the management problem, we can never
resolve technical issues such as these.

Tom Petch, Network Consultant
[email-masked]

Delivery-date: Fri, 08 Mar 2002 13:21:28 -0800
From: "Meehan, John" <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Fri, 8 Mar 2002 16:20:50 -0500 

#4.  Would be #1 if it didn't make it sound like SONET doesn't exist anymore
as Eric Mannie said.  But I must say I agree with Bob's statements below,
the word "should" does bother me.

-----Original Message-----
From: Natale, Robert C (Bob) [mailto:[email-masked]]
Sent: Friday, March 01, 2002 3:48 PM
To: ccamp-wg
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

Hi,

Apologies in advance for this post going against the
grain of the AD's guidance for this thread.  I am not
(I hope!) posting a "diatribe" here :-) -- I am just
curious about something and maybe the answer to it
will affect my own and possibly others' assessment
of the options before us....

As a non-expert (re the diffs between SONET and SDH as
they might necessarily affect labeling requirements or
not), I opted for #1 (or #4, which I consider to be its
moral equivalent) on the basis of my interpretation of
s/w engineering principles and my (negative) experience
with allowing optionality in widely deployed standards.

Since the respondents seems largely divided between
#1 and #2 (with the few mentioning #4 as an acceptable
alternative about equally divided between #1 and #2
as another acceptable choice for them), my attention
is naturally drawn to the absence of any "votes" for
#3 (apologies if I've missed anyone's vote for #3)...?

The only diff that I can discern between #2 and #3 is
the SHOULD in #2 vs the MUST in #3.  It is that SHOULD
in #2 that caused me to discount it up front.  I am
curious to know how the people expressing a preference
for #2 feel about #3 -- that is, do they see it important
that we specify #2 rather than #3, or rather than #1?

I'm really against that SHOULD in #2.  But -- although
I do prefer #1 (or, second, #4) for the reasons mentioned
above -- I might not feel as determinedly antagonistic
to #3, if that were to end up being the WG's consensus.

Thanks,

BobN

>At 07:39 AM 2/26/2002, Wijnen, Bert (Bert) wrote:
>If people want to express their support for this 4th option
>then that is fine with me. WG chair(s) do you agree too
>(don't want to step on your toes or sit in your chair).
>
>Bert
>
> > -----Original Message-----
> > From: Mannie, Eric 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Tuesday, February 26, 2002 11:32 AM
> > To: 'Wijnen, Bert (Bert)'; ccamp-wg
> > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> >
> >
> > Hello Bert and all,
> >
> > One question is missing:
> >
> > 4) Do you think we should have just a single set of traffic
> > parameters and label format (values) for both SDH and SONET.
> >
> > In 1) "none for SONET" assumes that SONET doesn't exist
> > anymore. Note also that the traffic parameters are already
> > identical, the only difference is about the label. As editor
> > of these drafts I would like at least to see the right
> > questions asked on the mailing list.
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Tuesday, February 26, 2002 10:37 AM
> > To: ccamp-wg
> > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> >
> > CCAMP WG members,
> >
> > before we start down another many 100s of emails re-discussing
> > the same topic....
> >
> > PLEASE express your support for one of the 3 options that Kireeti
> > posed to the WG. Don't elaborate... just help the WG chair(s) to
> > figure out the (rough) consensus of the WG. The choices formulated
> > by Kireeti:
> >
> > > So, here we are again, arguing over this.  Let's follow the AD's
> > > suggestion and look for consensus in the WG.
> > >
> > > 1) Do you think we should have just a single set of traffic
> > >    parameters and label values for SDH, and none for SONET?
> > > or
> > > 2) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one SHOULD
> > >    use the SDH equivalent?
> > > or
> > > 3) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one MUST
> > >    use the SDH equivalent?
> > >
> > > (in the above, SHOULD and MUST are to be interpreted as in
> > > RFC 2119.)
> > >
> > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> >
> > Thanks
> > Bert, speaking as AD who would like to see the WG take
> >       a decision on this topic.

Envelope-to: [email-masked]
Delivery-date: Fri, 08 Mar 2002 12:32:48 -0800
Message-Id: <[email-masked]>
To: "Don Fedyk" <[email-masked]>
cc: George Swallow <[email-masked]>, Peter Willis <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Tunnels v. circuits was Re: MPLS OAM & the IETF 
Date: Fri, 08 Mar 2002 13:58:03 -0500
From: George Swallow <[email-masked]>

> > > And the difference betwenn IP tunnels and circuits would be?
> > 
> > At the service level not much except that ordered delivery cannot be
> > assumed.
> > 
> > But in between the end points -
> > 
> > A circuit has a static (fixed) route, IP is dynamic.
> > 
> > Intermediate nodes carrying a circuit usually have state associated
> > with those circuits, IP nodes have no such state.
> 
> MPLS LSPs have state associated with the LSPS on the intermediate 
> nodes. Seem like a case for circuit based diagnostics for MPLS!
> 
> Don 

The statement I responded to (at the top of this message) did not
mention MPLS.  The point is circuit like techinique cannot and should
not be applied across the board to all LSPs because not all LSPs
behave like circuits (actually make that the overwhelming majority of
LSPs).

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Fri, 08 Mar 2002 11:55:08 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-fontana-ccamp-gmpls-g709-03.txt
Date: Fri, 08 Mar 2002 14:53:11 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: GMPLS Signalling Extensions for G.709 Optical 
                          Transport Networks Control
	Author(s)	: D. Papadimitriou et al.
	Filename	: draft-fontana-ccamp-gmpls-g709-03.txt
	Pages		: 19
	Date		: 08-Mar-02
	
This document is a companion to the Generalized MPLS (GMPLS)
signalling documents [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It
describes the G.709 [ITUT-G709] technology specific information
needed to extend GMPLS signalling to control Optical Transport
Networks (OTN); it also includes the so-called pre-OTN
developments.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-fontana-ccamp-gmpls-g709-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: Fri, 08 Mar 2002 09:10:09 -0800
From: "Don Fedyk"<[email-masked]>
To: George Swallow <[email-masked]>, Peter Willis <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Tunnels v. circuits was Re: MPLS OAM & the IETF 
Date: Fri, 8 Mar 2002 12:08:57 -0500 

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

------_=_NextPart_001_01C1C6C3.EED874D0
Content-Type: text/plain;
	charset="iso-8859-1"

George

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Friday, March 08, 2002 10:24 AM
> To: Peter Willis
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Tunnels v. circuits was Re: MPLS OAM & the IETF 
> 
> 
> > And the difference betwenn IP tunnels and circuits would be?
> 
> At the service level not much except that ordered delivery cannot be
> assumed.
> 
> But in between the end points -
> 
> A circuit has a static (fixed) route, IP is dynamic.
> 
> Intermediate nodes carrying a circuit usually have state associated
> with those circuits, IP nodes have no such state.

MPLS LSPs have state associated with the LSPS on the intermediate 
nodes. Seem like a case for circuit based diagnostics for MPLS!

Don 

> 
> So in terms of diagnostics they are vastly different.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
> 

------_=_NextPart_001_01C1C6C3.EED874D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Tunnels v. circuits was Re: MPLS OAM &amp; the IETF </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>George</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: George Swallow [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, March 08, 2002 10:24 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Peter Willis</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Tunnels v. circuits was Re: MPLS =
OAM &amp; the IETF </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; And the difference betwenn IP tunnels and =
circuits would be?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At the service level not much except that =
ordered delivery cannot be</FONT>
<BR><FONT SIZE=3D2>&gt; assumed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; But in between the end points -</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A circuit has a static (fixed) route, IP is =
dynamic.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Intermediate nodes carrying a circuit usually =
have state associated</FONT>
<BR><FONT SIZE=3D2>&gt; with those circuits, IP nodes have no such =
state.</FONT>
</P>

<P><FONT SIZE=3D2>MPLS LSPs have state associated with the LSPS on the =
intermediate </FONT>
<BR><FONT SIZE=3D2>nodes. Seem like a case for circuit based =
diagnostics for MPLS!</FONT>
</P>

<P><FONT SIZE=3D2>Don </FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So in terms of diagnostics they are vastly =
different.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ...George</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; George =
Swallow&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cisco =
Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (978) 497-8143</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 250 =
Apollo Drive</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Chelmsford, Ma 01824</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C6C3.EED874D0--

Delivery-date: Fri, 08 Mar 2002 08:43:59 -0800
Date: Fri, 08 Mar 2002 11:36:14 -0500
From: Ron Bonica <[email-masked]>
Subject: Gentle Reminder
To: [email-masked]

Folks,

Anyone producing Internet Drafts should read
http://www.rfc-editor.org/policy.html and http://www.ietf.org/ID-nits.html.

The ADs remind us that if a draft departs significantly from these
guidelines, it may not be accepted. (Be careful about number of authors and
be specific about reference types).

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"Not all who wander are lost."
                -- J.R.R. Tolkien

Delivery-date: Fri, 08 Mar 2002 07:53:18 -0800
Date: Fri, 08 Mar 2002 10:47:34 -0500
To: George Swallow <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: draft-bonica-tunneltrace-02 
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

>Neil -
>
> > Thanks Ping.....nice to see a positive response from a specific 
> manufacturer
> > to our concerns as operators on this.  This is a really good positive step
> > IMO. Its a shame other manufacturers have discounted Y.1710, as what 
> Enrique
>
>Unlike the ITU, members of the IETF act as individuals.  It is
>inappropriate to generalize the remarks of one person to an entire
>company.

>Further I believe that Tom was confused between Y.1710 and
>Y.1711.

         George is correct. I mixed up the document numbers. Indeed, the
OAM requirements are a very positive first step.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Envelope-to: [email-masked]
Delivery-date: Fri, 08 Mar 2002 07:26:35 -0800
Message-Id: <[email-masked]>
To: Peter Willis <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Tunnels v. circuits was Re: MPLS OAM & the IETF 
Date: Fri, 08 Mar 2002 10:24:07 -0500
From: George Swallow <[email-masked]>

> And the difference betwenn IP tunnels and circuits would be?

At the service level not much except that ordered delivery cannot be
assumed.

But in between the end points -

A circuit has a static (fixed) route, IP is dynamic.

Intermediate nodes carrying a circuit usually have state associated
with those circuits, IP nodes have no such state.

So in terms of diagnostics they are vastly different.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Fri, 08 Mar 2002 04:01:38 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-03.txt
Date: Fri, 08 Mar 2002 06:56:19 -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		: Link Management Protocol (LMP)
	Author(s)	: J. Lang et al.
	Filename	: draft-ietf-ccamp-lmp-03.txt
	Pages		: 68
	Date		: 07-Mar-02
	
Optical networks are being developed to include photonic switches, 
optical crossconnects, and routers that are configured with control 
channels and data links.  Furthermore, multiple data links may be 
combined to form a single traffic engineering (TE) link for routing 
purposes. This draft specifies a link management protocol (LMP) that 
runs between neighboring nodes and is used to manage TE links.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-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: Fri, 08 Mar 2002 02:22:51 -0800
To: [email-masked]
cc: [email-masked]
Subject: Tunnels v. circuits was Re: MPLS OAM & the IETF 
Date: Fri, 08 Mar 2002 10:21:02 +0000
From: Peter Willis <[email-masked]>

Eric said:
>   It's that they  think of LSPs as being more like IP tunnels than like
>   circuits. 

And the difference betwenn IP tunnels and circuits would be?

.........

Not such a crazy question when you start to think about it!

Regards,
Peter Willis
BTexact Technologies.

Delivery-date: Fri, 08 Mar 2002 00:57:56 -0800
Date: Fri, 08 Mar 2002 17:51:31 +0900
From: Yutaka SAKAI <[email-masked]>
To: [email-masked]
Subject: Re: MPLS OAM & the IETF

i am not expert but...
If trend of communication move more ip-centric, 
*ip-based* #2a is more better.
but i feel that ITU-T considers #1 or #3 (both well 
cared for legacy) as far as i heard about abstract 
report from last SG13 attendees.
 if something is wrong, please correct me.

below figures are my current poor understandings.

#0 starting point
-------------------------------------------------
telco's OAM stack           IETF tools
(mainly ITU-T)              ping, tracert etc

                 |  upper  |
                 |---------|
                 |         |
                 |  MPLS   |
                 |         |
                 |---------|
                 |  lower  |

#1 split the tasks
-------------------------------------------------
telco's OAM stack           IETF tools

                 |  upper  |
      +----------+---------|
      |          |         |
      | MPLS OAM |  MPLS   |
      |  ITU-T?  |  IETF?  |
      +----------+---------|
                 |  lower  |

issue:
 How to split ?
 Does ITU-T want *all* OAM ?

#2a produce common
-------------------------------------------------
******* *** *****           **** *****

                 |  upper  |
                 |---------+----------+
                 |         |  common  |
                 |  MPLS   | MPLS OAM |
                 |         | ITU&IETF |
                 |---------+----------+
                 |  lower  |

issue:
 Which does it stand up for non-ip-centric or ip-centric ?

#2b compete
-------------------------------------------------
telco's OAM stack           IETF tools

                 |  upper  |
      +  --  --  +---------+  --  --  +
                 |         |           
      | MPLS OAM |  MPLS   | MPLS OAM |
         ITU-T   |         |   IETF    
      +  --  --  +---------+  --  --  +
                 |  lower  |

issue:
 Are there more two ways ?
 #2b-1 at last, select only one  or
 #2b-2 fight forever (=not same as #3)

#3 split & dual adhoc (by Mina Azad)
-------------------------------------------------
telco's OAM stack           IETF tools

                 |  upper  |
      +----------+---------+----------+
      | non-ip.. |         | ip-based |
      | MPLS OAM |  MPLS   | MPLS OAM |
      |  ITU-T   |         |   IETF   |
      +----------+---------+----------+
                 |  lower  |

issue:
 Do we want to swim in muddy waters ?
 #3-2 for non-ip-centric by ITU  and
 #3-3 for ip-centric by IETF

regards,
Yutaka

Delivery-date: Thu, 07 Mar 2002 15:34:44 -0800
From: Raj Sharma <[email-masked]>
To: 'Scott  Bradner' <[email-masked]>, [email-masked]
Subject: RE: MPLS OAM & the IETF
Date: Thu, 7 Mar 2002 15:30:54 -0800 

2a

> -----Original Message-----
> From: Scott Bradner [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 7:34 AM
> To: [email-masked]
> Subject: MPLS OAM & the IETF
> 
> 
> subject:   MPLS OAM & the IETF
> 
> The result of the MPLS OAM BOF in Salt Lake City has been 
> confirmed over
> the last few days in the mailing list thread 
> "draft-bonica-tunneltrace-02."
> 
> 
> That result was and is that there are at least two quite 
> different views on
> the type of OAM tools and technologies needed for MPLS networks.  
> 
> My reading of the groups is that one group, who are mostly 
> concerned with
> the transport of IP over MPLS, generally feel that tools 
> approximating the
> traditional "ping" and "traceroute" tools used on IP networks are
> sufficient.  A second group seems to feel that those tools do 
> not provide
> enough of a view of the service a customer is getting to be 
> sufficient and
> that tools approximating traditional telephone system OAM 
> tools are needed
> to get the complete picture.
> 
> Meanwhile, the ITU-T has been working in this area and has a 
> document in
> their equivalent of the IETF Last-Call. Brian Moore, the 
> ITU-T Study Group
> 13 chair, kindly arraigned for the ITU-T document (known as 
> Y.1711) to be
> put on an ftp site so interested IETF folk can take a look at 
> what they
> have done.  The URL is 
> http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.ht
ml (IETF folk
have to register to use the FTP site.)

It seems to me that there are two options on what we (the IETF) could do at
this point.

0/ you think I do not understand the issue

1/ split the tasks:  The IETF focus on the ping/traceroute mechanisms and
cede to the ITU-T work on the more telco-like OAM.  In this option the IETF
would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an
MPLS reserved label value for use by the ITU-T to identify Y.1711
information.

2/ The IETF work on a suite of technologies ranging from the
ping/traceroute-like mechanisms to the more telephone system OAM ones.  The
IETF could try to figure out how to do this in conjunction with the ITU,
though it is a bit late for that considering the state of Y.1711, or be in
competition with the ITU-T.  

So - please indicate your opinion on how the IETF should proceed

1 - split the tasks between the IETF and the ITU-T
2 - IETF produce standards track documents covering both areas
  2a - trying to work with the ITU-T to produce common technology
  2b - in competition with the ITU-T

In any case, it would be good to provide feedback to the ITU-T on Y.1711 if
you see anything that looks broken.

Scott (with sub-ip AD hat on)

Delivery-date: Thu, 07 Mar 2002 11:20:12 -0800
From: Randy Bush <[email-masked]>
To: Shahram Davari <[email-masked]>
Cc: [email-masked]
Subject: RE: MPLS OAM & the IETF
Date: Thu, 07 Mar 2002 11:19:05 -0800

> I think the essence of the questions raised by Scott at this point is
> not whether IETF should work on simple tools presented or not, rather
> should IETF also work on the comprehensive OAM tools, as described in
> the BOF, or leave it to ITU.

we transport ip over atm, but someone else does the non-ip atm tools.
we do the ip-oriented tools.

i am not jealous of the itu.  each body brings expertise to the table.
we need the best expertise focused on any issue.  where we need to
overlap is ensuring we have a consistent architecture and harmonious
non-conflicting details.

randy

Envelope-to: [email-masked]
Delivery-date: Thu, 07 Mar 2002 10:44:19 -0800
Date: Thu, 7 Mar 2002 13:42:38 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RE: MPLS OAM & the IETF

Shahram sez:

> I think the essence of the questions raised by Scott at this point is 
> not whether IETF should work on simple tools presented or not, rather 
> should IETF also work on the comprehensive OAM tools, as described 
> in the BOF, or leave it to ITU.

that is what I tried to ask - thanks for making it clearer

Scott

Delivery-date: Thu, 07 Mar 2002 09:24:28 -0800
From: "Mina Azad"<[email-masked]>
To: "'Scott Bradner'" <[email-masked]>, [email-masked]
Subject: RE: MPLS OAM & the IETF 
Date: Thu, 7 Mar 2002 12:23:26 -0500 

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

------_=_NextPart_001_01C1C5FC.CAE0B8C0
Content-Type: text/plain;
	charset="iso-8859-1"

As it's been pointed out on the mailing list in a various ways, option 1 is
pragmatic but needs clarification.
I'd like to suggest a third option which is effectively  refinement to "1".
 
Option 3:
Principles of this option: Split the OAM (M stands for management and
measurement) work between ITU and ITEF with commitment on both bodies to
work towards complementing solutions, taking into consideration the core
competency of the two standard bodies and the business drivers behind the
technologies (from vendor, operator, and standards perspectives).

In specific, option 3 proposes splitting the OAM in three areas 

      1) Definition and mechanism for availability and measurement to be
handled by ITU   
      2) ad-hoc diagnostic tools for ip-centric networks to be handled by
IETF
      3) ad-hoc diagnostic and measurement tools primarily for
non-ip-centric networks to be handled by ITU         

Regards, 

Mina  Azad

------_=_NextPart_001_01C1C5FC.CAE0B8C0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: MPLS OAM & the IETF</TITLE>

<META content="MSHTML 5.00.3314.2100" name=GENERATOR></HEAD>
<BODY>
<DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=660375316-07032002>As it's been p</SPAN><SPAN 
class=660375316-07032002>ointed out on the mailing list</SPAN><SPAN 
class=660375316-07032002> in a&nbsp;</SPAN><SPAN 
class=660375316-07032002>various ways, option 1 is pragmatic but needs 
clarification.</SPAN></FONT></FONT></FONT></DIV>
<DIV><SPAN class=660375316-07032002></SPAN><FONT size=2><FONT 
color=#0000ff><FONT face=Arial><SPAN class=660375316-07032002>I'd like to 
sug</SPAN><SPAN class=660375316-07032002>gest a third option which is 
effectively&nbsp; refinement to "1".</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=660375316-07032002>&nbsp;</SPAN></FONT></DIV>
<DIV><SPAN class=660375316-07032002></SPAN><FONT size=2><FONT 
color=#0000ff><FONT face=Arial>Option 3<SPAN 
class=660375316-07032002>:</SPAN></FONT></FONT></FONT></DIV>
<DIV><SPAN class=660375316-07032002></SPAN><FONT size=2><FONT 
color=#0000ff><FONT face=Arial><SPAN class=660375316-07032002>Principles of this 
option: Split the OA<SPAN class=360451317-07032002>M</SPAN> (M stands for 
management and measurement) wo</SPAN><SPAN class=660375316-07032002>rk between 
IT<SPAN class=360451317-07032002>U</SPAN> and ITE<SPAN 
class=360451317-07032002>F</SPAN> with commitment on both bodies to work towards 
complementing solutions, taking into consideration the core competency of the 
two standard bodies and </SPAN>the business drivers behind the technologies<SPAN 
class=660375316-07032002> (</SPAN>from vendor, operator, and standards 
perspective<SPAN class=660375316-07032002>s</SPAN><SPAN 
class=660375316-07032002>)</SPAN>.</FONT></FONT></FONT></DIV>
<DIV>
<P><FONT face=Arial><FONT color=#0000ff><FONT size=2>I<SPAN 
class=660375316-07032002>n specific, option 3 proposes splitting the OAM in 
three areas </SPAN><SPAN class=660375316-07032002></FONT></FONT></FONT></P>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=080165717-06032002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1)&nbsp;<SPAN 
class=360451317-07032002>D</SPAN>efinition and&nbsp;mechanism for availability 
and measurement to be handled by ITU&nbsp;&nbsp; </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=080165717-06032002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2) ad-hoc 
diagnostic tools for ip-centric networks to be handled by 
IETF</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=080165717-06032002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3) ad-hoc 
diagnostic and measurement tools primarily for non-ip-centric networks to be 
handled by ITU</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=080165717-06032002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FONT></SPAN></DIV></DIV></DIV>
<P><I><FONT face="Monotype Corsiva">Regards,</FONT></I> </P>
<P><I><B><FONT face="Monotype Corsiva">Mina</FONT></B></I>&nbsp;<FONT 
face="Monotype Corsiva"><SPAN class=360451317-07032002><STRONG><EM> 
Azad</EM></STRONG></SPAN></FONT></P></BODY></HTML>

------_=_NextPart_001_01C1C5FC.CAE0B8C0--

Delivery-date: Thu, 07 Mar 2002 09:04:19 -0800
From: "David Allan"<[email-masked]>
To: John Drake <[email-masked]>, "'George Swallow'" <[email-masked]>, Shahram Davari <[email-masked]>
Cc: "'Scott Bradner'" <[email-masked]>, [email-masked]
Subject: RE: MPLS OAM & the IETF 
Date: Thu, 7 Mar 2002 12:03:38 -0500 

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

------_=_NextPart_001_01C1C5FA.06C64EC0
Content-Type: text/plain;
	charset="iso-8859-1"

John/George:

Superficially this would appear to be a sensible view, but we have gotten to
this point because for whatever reasons, on this subject the IETF has not
served a portion of its community, both vendors and providers. This has been
an ongoing issue. 

I agree with Eric that '1' is a pragmatic view that acknowledges how we got
to this point, and given the volume of past discussions on the subject, no
other method of arbitration appears to be tractable. IMHO '1' will need
refinement to become more workable.

If we can get to agreement that the OAM stuff should be done elsewhere, and
bundle that with some agreement to cooperate on the key interoperablity
issues (mainly IANA concerns), that should provide some form of workable
framework.  Ultimately it is the folks that buy this stuff that demand
interoperability, and we will be answerable to them for all our sins. ;-)

Dave

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 10:42 AM
> To: 'George Swallow'; Shahram Davari
> Cc: 'Scott Bradner'; [email-masked]
> Subject: RE: MPLS OAM & the IETF 
> 
> 
> George,
> 
> A very sensible view.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 9:26 AM
> To: Shahram Davari
> Cc: 'Scott Bradner'; [email-masked]; [email-masked]
> Subject: Re: MPLS OAM & the IETF 
> 
> 
> > Could you please clarify option (1) a bit more? If this route is
> > taken, still cooperation is needed between ITU and IETF. For example
> > ITU may need MPLS signaling extensions. Also in some cases packet
> > processing may need to be aligned between ITU and IETF in order to
> > avoid conflicts. For example ITU may consider an MPLS 
> path-trace that
> > uses TTL expiration, which requires a TTL expired MPLS packet to be
> > forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL
> > expired packets to ICMP/GTTP module. There needs to be a 
> coordination
> > between IETF and ITU in order to find a common method which could
> > determine whether a packet should be forwarded to OAM or ICMP/GTTP
> > module.
> 
> It's precisely issues such as these that lead me to believe that it
> would be best if *only one* standards body owns a core technology.
> Certainly other bodies should be free to create applications, define
> extentions, and do implementation agreements.  But when it come to
> something a central as the basic forwarding plane, one group alone
> should handle it.
> 
> Allowing another body to redifine core functions WILL lead to
> interoperability problems.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
> 

------_=_NextPart_001_01C1C5FA.06C64EC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: MPLS OAM &amp; the IETF </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>John/George:</FONT>
</P>

<P><FONT SIZE=3D2>Superficially this would appear to be a sensible =
view, but we have gotten to this point because for whatever reasons, on =
this subject the IETF has not served a portion of its community, both =
vendors and providers. This has been an ongoing issue. </FONT></P>

<P><FONT SIZE=3D2>I agree with Eric that '1' is a pragmatic view that =
acknowledges how we got to this point, and given the volume of past =
discussions on the subject, no other method of arbitration appears to =
be tractable. IMHO '1' will need refinement to become more =
workable.</FONT></P>

<P><FONT SIZE=3D2>If we can get to agreement that the OAM stuff should =
be done elsewhere, and bundle that with some agreement to cooperate on =
the key interoperablity issues (mainly IANA concerns), that should =
provide some form of workable framework.&nbsp; Ultimately it is the =
folks that buy this stuff that demand interoperability, and we will be =
answerable to them for all our sins. ;-)</FONT></P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: John Drake [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Thursday, March 07, 2002 10:42 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'George Swallow'; Shahram Davari</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Scott Bradner'; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: MPLS OAM &amp; the IETF </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; George,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A very sensible view.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; John</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: George Swallow [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, March 06, 2002 9:26 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Shahram Davari</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Scott Bradner'; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: MPLS OAM &amp; the IETF </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Could you please clarify option (1) a bit =
more? If this route is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; taken, still cooperation is needed between =
ITU and IETF. For example</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ITU may need MPLS signaling extensions. =
Also in some cases packet</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; processing may need to be aligned between =
ITU and IETF in order to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; avoid conflicts. For example ITU may =
consider an MPLS </FONT>
<BR><FONT SIZE=3D2>&gt; path-trace that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; uses TTL expiration, which requires a TTL =
expired MPLS packet to be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; forwarded to MPLS OAM module, while GTTP =
considers sending MPLS TTL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; expired packets to ICMP/GTTP module. There =
needs to be a </FONT>
<BR><FONT SIZE=3D2>&gt; coordination</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; between IETF and ITU in order to find a =
common method which could</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; determine whether a packet should be =
forwarded to OAM or ICMP/GTTP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; module.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It's precisely issues such as these that lead =
me to believe that it</FONT>
<BR><FONT SIZE=3D2>&gt; would be best if *only one* standards body owns =
a core technology.</FONT>
<BR><FONT SIZE=3D2>&gt; Certainly other bodies should be free to create =
applications, define</FONT>
<BR><FONT SIZE=3D2>&gt; extentions, and do implementation =
agreements.&nbsp; But when it come to</FONT>
<BR><FONT SIZE=3D2>&gt; something a central as the basic forwarding =
plane, one group alone</FONT>
<BR><FONT SIZE=3D2>&gt; should handle it.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Allowing another body to redifine core =
functions WILL lead to</FONT>
<BR><FONT SIZE=3D2>&gt; interoperability problems.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ...George</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; George =
Swallow&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cisco =
Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (978) 497-8143</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 250 =
Apollo Drive</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Chelmsford, Ma 01824</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C5FA.06C64EC0--

Delivery-date: Thu, 07 Mar 2002 08:48:11 -0800
From: Shahram Davari <[email-masked]>
To: "'Joel M. Halpern'" <[email-masked]>, [email-masked]
Subject: RE: MPLS OAM & the IETF
Date: Thu, 7 Mar 2002 08:47:33 -0800 

Joel,

I think the essence of the questions raised by Scott at this point is not whether IETF should work on simple tools presented or not, rather should IETF also work on the comprehensive OAM tools, as described in the BOF, or leave it to ITU.

-Shahram

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 11:30 AM
> To: [email-masked]
> Subject: RE: MPLS OAM & the IETF
> 
> 
> Having watched some of the discussion in SLC, and much of the 
> discussion on 
> this list, a couple of things were and are clear.
> 
> There are two different sets of objectives.  Sharam and Neil want a 
> comprehensive OAM solution.  In contrast, Ron and others are 
> looking to 
> define a simple tool.  It was agreed in Salt Lake that these 
> are different 
> tasks.
> 
> My understanding is that the CCAMP working group has agreed 
> to undertake 
> the task of defining a simple tool for a simple problem.  The 
> ADs have 
> agreed that this is within scope.
> 
> The debate then should focus on the documents for that simple 
> problem.  One 
> should have, at this point, a relatively small number of 
> clear choices:
> You can argue that the working group should not define a 
> solution for the 
> simple case.  I thought there was consensus to solve this, if 
> there really 
> isn't then we should not have a working group document.
> You can argue that the description of the problem in the proposed 
> requirements draft is completely off base.  In that case, 
> given the stage 
> of development, I think you should bring in a draft as to what the 
> requirements you do see FOR THE SIMPLE CASE.  A complete 
> draft about what 
> the full set of OAM needs for an operator are does not 
> address the question.
> In the absence of an alternative draft, and given the 
> consensus to work on 
> the simple case, we should take the starting point we have, and fix 
> whatever problems there are.  Taking it as a working group 
> document is not 
> a vacuous action, but it does not mean "it is done, start 
> last call".  It 
> means this is a decent starting point.  (And having a 
> starting point is the 
> only way to make progress.)
> 
> Yours,
> Joel M. Halpern
> 
> At 08:05 AM 3/7/02 -0800, Shahram Davari wrote:
> >Giles,
> >
> > > Agreed.
> > >
> > > I'm not sure which of Scott's options this corresponds 
> to, though!  I
> > > don't want to see the IETF working on MPLS OAM as per 
> option 2, but
> > > option 1 seems to be a step down the road of allowing the ITU to
> > > "co-own" MPLS?
> > >
> >
> >It seems that developing non-IP OAM tools for MPLS is not in 
> the spirit of 
> >IETF. However, it seems that many operators want functions 
> more than ping 
> >and trace-route for their MPLS networks that are used to carry their 
> >legacy traffic.
> >
> >Y.1711 and future ITU recommendations would possibly use 
> MPLS data-plane 
> >to carry the MPLS OAM packets, but that doesn't mean that 
> ITU will co-own 
> >the MPLS. Everybody knows that the MPLS data-plane as well as MPLS 
> >IP-based control-plane and MPLS IP-based management-plane 
> are owned by IETF.
> >
> >Besides any need by ITU for extensions to IETF standards 
> will formally go 
> >through IETF channels, and therefore be under IETF control.
> >
> >Therefore I think if there is a clear delineation of work 
> and procedures 
> >for the cooperation, then most of your concerns could be addressed.
> >
> >Yours,
> >-Shahram
> >
> 
> 

Delivery-date: Thu, 07 Mar 2002 08:35:26 -0800
From: Shahram Davari <[email-masked]>
To: "'Ron Bonica'" <[email-masked]>
Cc: [email-masked]
Subject: NEW SUBJECT: draft-bonica-tunproto-01.txt
Date: Thu, 7 Mar 2002 08:35:07 -0800 

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

------_=_NextPart_001_01C1C5F6.0AA72F40
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Ron,
 
As you may know after some discussions with Ping Pan regarding the use of ICMP-ping/LSP-Ping is non-IP carrying LSPs, he revised his draft and added the following text:
 
"  To test an LSP that carries non-IP traffic, before injecting ICMP and
   MPLS ping messages into the LSP, the IPv4 Explicit NULL label should
   be prepended to such messages."
 
It seems to me that the same principle applies to GTTP. Therefore I would like to suggest adding the same kind of text to your GTTP draft for this special case.
 
Yours,
-Shahram

------_=_NextPart_001_01C1C5F6.0AA72F40
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: draft-bonica-tunneltrace-02</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=983162816-07032002>Hi 
Ron,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=983162816-07032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=983162816-07032002>As you may know 
after some discussions with Ping Pan regarding the use of ICMP-ping/LSP-Ping is 
non-IP carrying LSPs, he revised his draft and added the following 
text:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=983162816-07032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=983162816-07032002>"&nbsp; To test an 
LSP that carries non-IP traffic, before injecting ICMP and<BR>&nbsp;&nbsp; MPLS 
ping messages into the LSP, the IPv4 Explicit NULL label should<BR>&nbsp;&nbsp; 
be prepended to such messages."</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=983162816-07032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=983162816-07032002>It seems to me that 
the same principle applies to GTTP. Therefore I would like to suggest adding the 
same kind of text to your GTTP draft for this special case.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=983162816-07032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=983162816-07032002>Yours,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=983162816-07032002>-Shahram<BR></DIV></SPAN></FONT></BODY></HTML>

------_=_NextPart_001_01C1C5F6.0AA72F40--

Delivery-date: Thu, 07 Mar 2002 08:32:09 -0800
Date: Thu, 07 Mar 2002 11:30:02 -0500
To: [email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: RE: MPLS OAM & the IETF

Having watched some of the discussion in SLC, and much of the discussion on 
this list, a couple of things were and are clear.

There are two different sets of objectives.  Sharam and Neil want a 
comprehensive OAM solution.  In contrast, Ron and others are looking to 
define a simple tool.  It was agreed in Salt Lake that these are different 
tasks.

My understanding is that the CCAMP working group has agreed to undertake 
the task of defining a simple tool for a simple problem.  The ADs have 
agreed that this is within scope.

The debate then should focus on the documents for that simple problem.  One 
should have, at this point, a relatively small number of clear choices:
You can argue that the working group should not define a solution for the 
simple case.  I thought there was consensus to solve this, if there really 
isn't then we should not have a working group document.
You can argue that the description of the problem in the proposed 
requirements draft is completely off base.  In that case, given the stage 
of development, I think you should bring in a draft as to what the 
requirements you do see FOR THE SIMPLE CASE.  A complete draft about what 
the full set of OAM needs for an operator are does not address the question.
In the absence of an alternative draft, and given the consensus to work on 
the simple case, we should take the starting point we have, and fix 
whatever problems there are.  Taking it as a working group document is not 
a vacuous action, but it does not mean "it is done, start last call".  It 
means this is a decent starting point.  (And having a starting point is the 
only way to make progress.)

Yours,
Joel M. Halpern

At 08:05 AM 3/7/02 -0800, Shahram Davari wrote:
>Giles,
>
> > Agreed.
> >
> > I'm not sure which of Scott's options this corresponds to, though!  I
> > don't want to see the IETF working on MPLS OAM as per option 2, but
> > option 1 seems to be a step down the road of allowing the ITU to
> > "co-own" MPLS?
> >
>
>It seems that developing non-IP OAM tools for MPLS is not in the spirit of 
>IETF. However, it seems that many operators want functions more than ping 
>and trace-route for their MPLS networks that are used to carry their 
>legacy traffic.
>
>Y.1711 and future ITU recommendations would possibly use MPLS data-plane 
>to carry the MPLS OAM packets, but that doesn't mean that ITU will co-own 
>the MPLS. Everybody knows that the MPLS data-plane as well as MPLS 
>IP-based control-plane and MPLS IP-based management-plane are owned by IETF.
>
>Besides any need by ITU for extensions to IETF standards will formally go 
>through IETF channels, and therefore be under IETF control.
>
>Therefore I think if there is a clear delineation of work and procedures 
>for the cooperation, then most of your concerns could be addressed.
>
>Yours,
>-Shahram
>

Delivery-date: Thu, 07 Mar 2002 08:06:06 -0800
From: Shahram Davari <[email-masked]>
To: "'Giles Heron'" <[email-masked]>, George Swallow <[email-masked]>
Cc: "'Scott Bradner'" <[email-masked]>, [email-masked]
Subject: RE: MPLS OAM & the IETF
Date: Thu, 7 Mar 2002 08:05:45 -0800 

Giles,

> Agreed.
> 
> I'm not sure which of Scott's options this corresponds to, though!  I 
> don't want to see the IETF working on MPLS OAM as per option 2, but 
> option 1 seems to be a step down the road of allowing the ITU to 
> "co-own" MPLS?
> 

It seems that developing non-IP OAM tools for MPLS is not in the spirit of IETF. However, it seems that many operators want functions more than ping and trace-route for their MPLS networks that are used to carry their legacy traffic.

Y.1711 and future ITU recommendations would possibly use MPLS data-plane to carry the MPLS OAM packets, but that doesn't mean that ITU will co-own the MPLS. Everybody knows that the MPLS data-plane as well as MPLS IP-based control-plane and MPLS IP-based management-plane are owned by IETF.

Besides any need by ITU for extensions to IETF standards will formally go through IETF channels, and therefore be under IETF control.

Therefore I think if there is a clear delineation of work and procedures for the cooperation, then most of your concerns could be addressed.

Yours,
-Shahram 

Delivery-date: Thu, 07 Mar 2002 07:58:36 -0800
From: Shahram Davari <[email-masked]>
To: "'John Drake'" <[email-masked]>, "'George Swallow'" <[email-masked]>
Cc: "'Scott Bradner'" <[email-masked]>, [email-masked]
Subject: RE: MPLS OAM & the IETF 
Date: Thu, 7 Mar 2002 07:58:00 -0800 

George,

I have to disagree with you here. I don't think defining a non-IP based OAM for MPLS is in-line with what you described as "redefining core functions".

-Shahram

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 10:42 AM
> To: 'George Swallow'; Shahram Davari
> Cc: 'Scott Bradner'; [email-masked]
> Subject: RE: MPLS OAM & the IETF 
> 
> 
> George,
> 
> A very sensible view.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 9:26 AM
> To: Shahram Davari
> Cc: 'Scott Bradner'; [email-masked]; [email-masked]
> Subject: Re: MPLS OAM & the IETF 
> 
> 
> > Could you please clarify option (1) a bit more? If this route is
> > taken, still cooperation is needed between ITU and IETF. For example
> > ITU may need MPLS signaling extensions. Also in some cases packet
> > processing may need to be aligned between ITU and IETF in order to
> > avoid conflicts. For example ITU may consider an MPLS 
> path-trace that
> > uses TTL expiration, which requires a TTL expired MPLS packet to be
> > forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL
> > expired packets to ICMP/GTTP module. There needs to be a 
> coordination
> > between IETF and ITU in order to find a common method which could
> > determine whether a packet should be forwarded to OAM or ICMP/GTTP
> > module.
> 
> It's precisely issues such as these that lead me to believe that it
> would be best if *only one* standards body owns a core technology.
> Certainly other bodies should be free to create applications, define
> extentions, and do implementation agreements.  But when it come to
> something a central as the basic forwarding plane, one group alone
> should handle it.
> 
> Allowing another body to redifine core functions WILL lead to
> interoperability problems.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 

Delivery-date: Thu, 07 Mar 2002 07:42:17 -0800
From: John Drake <[email-masked]>
To: 'George Swallow' <[email-masked]>, Shahram Davari <[email-masked]>
Cc: 'Scott Bradner' <[email-masked]>, [email-masked]
Subject: RE: MPLS OAM & the IETF 
Date: Thu, 7 Mar 2002 07:41:36 -0800 

George,

A very sensible view.

Thanks,

John

-----Original Message-----
From: George Swallow [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 9:26 AM
To: Shahram Davari
Cc: 'Scott Bradner'; [email-masked]; [email-masked]
Subject: Re: MPLS OAM & the IETF 

> Could you please clarify option (1) a bit more? If this route is
> taken, still cooperation is needed between ITU and IETF. For example
> ITU may need MPLS signaling extensions. Also in some cases packet
> processing may need to be aligned between ITU and IETF in order to
> avoid conflicts. For example ITU may consider an MPLS path-trace that
> uses TTL expiration, which requires a TTL expired MPLS packet to be
> forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL
> expired packets to ICMP/GTTP module. There needs to be a coordination
> between IETF and ITU in order to find a common method which could
> determine whether a packet should be forwarded to OAM or ICMP/GTTP
> module.

It's precisely issues such as these that lead me to believe that it
would be best if *only one* standards body owns a core technology.
Certainly other bodies should be free to create applications, define
extentions, and do implementation agreements.  But when it come to
something a central as the basic forwarding plane, one group alone
should handle it.

Allowing another body to redifine core functions WILL lead to
interoperability problems.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Thu, 07 Mar 2002 07:17:51 -0800
To: Scott Bradner <[email-masked]>
cc: [email-masked]
Subject: Re: MPLS OAM & the IETF 
Reply-To: [email-masked]
Date: Thu, 07 Mar 2002 10:15:07 -0500
From: Eric Rosen <[email-masked]>

Scott> My reading of the groups is  that one group, who are mostly concerned
Scott> with  the  transport of  IP  over  MPLS,  generally feel  that  tools
Scott> approximating the traditional "ping" and "traceroute" tools used on IP
Scott> networks are  sufficient.  A  second group seems  to feel  that those
Scott> tools do  not provide enough of a  view of the service  a customer is
Scott> getting  to be  sufficient and  that tools  approximating traditional
Scott> telephone system OAM tools are needed to get the complete picture. 

I would pick just two nits with this statement: 

- It's  not so  much that  the  first group  are concerned  mostly with  the
  transport of  IP over  MPLS, since  many in the  first group  are actively
  involved in the  PWE3 and L2VPN efforts.  It's that they  think of LSPs as
  being more like IP tunnels than like circuits. 

- The criteria  for something  falling  into the  category of  "traditional
  telephone  system OAM tools"  need to  be well  specified.  Every  time we
  propose  to work  on a  management tool,  we don't  want to  spend  a year
  debating whether it falls into that category or not. 

Assuming that we can specify  such criteria, the advantage of Scott's option
1 is that it excludes the  telco-style stuff from the IETF, thereby breaking
the logjams that we've been seeing in the this and other WGs.

While  option 2a  seems reasonable  at  first glance,  I don't  think it  is
implementable. 

In some ways, option 2b is  the most attractive; it doesn't prevent the IETF
from working on  anything, and doesn't constrain the IETF  in any way.  This
is in fact the status quo situation.  But it seems to be preventing progress
in the WGs.   Whether this is really a systemic problem,  or simply a matter
of personalities, is unclear.

So 2b  isn't working  out well, but  1 might  be overly constraining  to the
IETF. I  have to wonder  whether there is  something short of 1  which could
eliminate the WG logjams.  All we  really need to break the logjam right now
is a decision to pursue the ping and traceroute tools; maybe we don't need a
grandiose meta-chartering decision. 

Delivery-date: Thu, 07 Mar 2002 02:57:33 -0800
Date: Thu, 07 Mar 2002 10:58:26 +0000
From: Giles Heron <[email-masked]>
Organization: PacketExchange Ltd.
To: [email-masked]
CC: [email-masked]
Subject: Re: MPLS OAM & the IETF

personally I'm not too worried either way whether the IETF works on 
GMPLS or not.  But in any case I don't think anyone in the IETF was 
suggesting using GMPLS as a mechanism for changing the forwarding plane 
of SDH or OTNs?

Giles

[email-masked] wrote:

> Come on guys...you cannot say this and still allow IETF to countenance GMPLS
> work on SDH/OTNs.  It also presupposes one has agreement on some quite
> fundamental networking principles that *have* to embrace cnls, co/pkt-sw and
> co/cct-sw, and to date I am not comfortable I can 'trust' one body to create
> the required networking solutions I need.
> 
> regards, Neil
> <snip>
> Giles Heron wrote 06 March 2002 23:17
> 
>>George Swallow wrote:
>>
>>
>>>>Could you please clarify option (1) a bit more? If this route is
>>>>taken, still cooperation is needed between ITU and IETF. For example
>>>>ITU may need MPLS signaling extensions. Also in some cases packet
>>>>processing may need to be aligned between ITU and IETF in order to
>>>>avoid conflicts. For example ITU may consider an MPLS 
>>>>
>>path-trace that
>>
>>>>uses TTL expiration, which requires a TTL expired MPLS packet to be
>>>>forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL
>>>>expired packets to ICMP/GTTP module. There needs to be a 
>>>>
>>coordination
>>
>>>>between IETF and ITU in order to find a common method which could
>>>>determine whether a packet should be forwarded to OAM or ICMP/GTTP
>>>>module.
>>>>
>>>>
>>>It's precisely issues such as these that lead me to believe that it
>>>would be best if *only one* standards body owns a core technology.
>>>Certainly other bodies should be free to create applications, define
>>>extentions, and do implementation agreements.  But when it come to
>>>something a central as the basic forwarding plane, one group alone
>>>should handle it.
>>>
>>>Allowing another body to redifine core functions WILL lead to
>>>interoperability problems.
>>>
>>
>>Agreed.
>>
>>I'm not sure which of Scott's options this corresponds to, though!  I 
>>don't want to see the IETF working on MPLS OAM as per option 2, but 
>>option 1 seems to be a step down the road of allowing the ITU to 
>>"co-own" MPLS?
>>
>>Giles
>>
>>
> 
> 

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

Delivery-date: Thu, 07 Mar 2002 02:56:32 -0800
From: "Gibson, Mark" <[email-masked]>
To: [email-masked]
Subject: RE: MPLS OAM & the IETF
Date: Thu, 7 Mar 2002 10:49:00 -0000 

2a) 

So - please indicate your opinion on how the IETF should proceed

1 - split the tasks between the IETF and the ITU-T
2 - IETF produce standards track documents covering both areas
  2a - trying to work with the ITU-T to produce common technology
  2b - in competition with the ITU-T

In any case, it would be good to provide feedback to the ITU-T on Y.1711 if
you see anything that looks broken.

Delivery-date: Thu, 07 Mar 2002 02:40:35 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: MPLS OAM & the IETF
Date: Thu, 7 Mar 2002 10:34:16 -0000 

Come on guys...you cannot say this and still allow IETF to countenance GMPLS
work on SDH/OTNs.  It also presupposes one has agreement on some quite
fundamental networking principles that *have* to embrace cnls, co/pkt-sw and
co/cct-sw, and to date I am not comfortable I can 'trust' one body to create
the required networking solutions I need.

regards, Neil
<snip>
Giles Heron wrote 06 March 2002 23:17
> George Swallow wrote:
> 
> >>Could you please clarify option (1) a bit more? If this route is
> >>taken, still cooperation is needed between ITU and IETF. For example
> >>ITU may need MPLS signaling extensions. Also in some cases packet
> >>processing may need to be aligned between ITU and IETF in order to
> >>avoid conflicts. For example ITU may consider an MPLS 
> path-trace that
> >>uses TTL expiration, which requires a TTL expired MPLS packet to be
> >>forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL
> >>expired packets to ICMP/GTTP module. There needs to be a 
> coordination
> >>between IETF and ITU in order to find a common method which could
> >>determine whether a packet should be forwarded to OAM or ICMP/GTTP
> >>module.
> >>
> > 
> > It's precisely issues such as these that lead me to believe that it
> > would be best if *only one* standards body owns a core technology.
> > Certainly other bodies should be free to create applications, define
> > extentions, and do implementation agreements.  But when it come to
> > something a central as the basic forwarding plane, one group alone
> > should handle it.
> > 
> > Allowing another body to redifine core functions WILL lead to
> > interoperability problems.
> 
> 
> Agreed.
> 
> I'm not sure which of Scott's options this corresponds to, though!  I 
> don't want to see the IETF working on MPLS OAM as per option 2, but 
> option 1 seems to be a step down the road of allowing the ITU to 
> "co-own" MPLS?
> 
> Giles
> 

Delivery-date: Thu, 07 Mar 2002 02:40:32 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 7 Mar 2002 10:34:04 -0000 

Thanks George.....I accept/agree.

neil

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: 06 March 2002 18:41
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02 
> 
> 
> Neil -
> 
> > Thanks Ping.....nice to see a positive response from a 
> specific manufacturer
> > to our concerns as operators on this.  This is a really 
> good positive step
> > IMO. Its a shame other manufacturers have discounted 
> Y.1710, as what Enrique
> 
> Unlike the ITU, members of the IETF act as individuals.  It is
> inappropriate to generalize the remarks of one person to an entire
> company.  Further I believe that Tom was confused between Y.1710 and
> Y.1711.
> 
> Y.1710 is a reasonable document.  Mostly great stuff that any vendor
> wanting to sell to carriers should take very seriously.  As do I.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 

Delivery-date: Thu, 07 Mar 2002 00:12:25 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 7 Mar 2002 08:10:41 -0000 

Hi John...see below.

regards, Neil

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: 07 March 2002 04:39
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> Neil,
> 
> I asked a simple question and expected a simple answer.  
> Instead, you send
> this example of incoherence raised to an arm form.
NH=> It's not incoherent to me and many others.  Not sure I would class it
as an 'art form' its just compelling logic to me.
> 
> Since you raised the specter of GMPLS, 
NH=> Interesting choice of word to describe GMPLS.....have you seen the
future? ;-)
> did you consider that 
> we could just
> as easily take the fault detection/isolation procedures of GMPLS and
> re-apply them to MPLS? 
NH=> But that's exactly what I said!  That is, it is the *principles* of
having defect detection/handling in the data-plane that is the thing that is
invariant/common, not the 1 size fits all *specific* mechanism which is
attempted to be force-fed to all layers.  And 2 of the most
important/fundamantal principles here are:
-	decoupled from any client/server technologies (ie the layer
violation issue....absolutely critical for data-plane protocol evolation)
-	decoupled from any control or management plane protocols (or indeed
the data plane on which these protocols run....since in many cct-sw/co
technologies this is *not* congruent topologically (and certainly not
functionally) with the data-plane of the traffic).  Again absolutely
critical for protocol evolution (all planes).
The rest then follows as I explained.

So...to re-interate the key message.....the thing that is *common* are the
principles, the actual mechanism has variations dependent on transfer mode
(ie cnls vs co) and (for co) whether cct-sw or pkt sw.  If you are stuggling
still to grasp the point I am making think about the control-plane and the
GMPLS example you mention.  The basic (network) function is
'find/route/connect' and this applies to all network layers (OAM addresses
the 'maintain' part of these basic functions that also applies to all layer
networks).  So we need addressing/routing (applies to both cnls/co) and
signalling (for co) facets for all layer networks.  The actual choice of
addressing, routing protocol and signalling protocol is purely a matter of
'fit for purpose', there are lots of options and there will be ongoing
development in each.  So the only thing that is enduring is the
'find/route/connect' principle and the functions they cover, not some
specific protocol embodiment that is current today.  Now if you are asking
me whether the actual protocols chosen for deploying a control-plane for
SDH/OTN are 'fit for purpose' that is a different question that raises both
(i) commercial and (ii) technical issues that need careful
consideration.....and I don't want to get into that one here.  

> Thanks,
> 
> John
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 4:08 PM
> To: John Drake; [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> No problem John......really glad you asked this question as 
> the answer is
> dead easy:
> 
> The simple/one-liner answer is to ask you to read 
> Y.1710.....I wrote this
> after a conversation Maartin Vissers and I had a few years 
> ago (on a bus in
> Turin or somewhere) where we effectively said:
> -	the network problems are effectively the same 
> irrespective of the
> technology, ie find/route/connect/maintain
> -	there are some differences dependent on transfer mode, 
> ie cnls is
> different to co, and in co there are some differnces wrt to cct-sw vs
> pkt-sw....but in essence, the 'network' problems are invariant
> -	and focusssing in the OAM aspects one can lay down some 
> principles
> that are largely technology independent and quite 
> generic....ergo Y.1710.
> 
> However, assuming one has never read Y.1710 the arguments follow this
> general reasoning:
> 
> -	1st define the defects specific to the layer 
> network/technology of
> interest....now clearly these are different in specifics 
> whether one is
> considering an OTN trail, a SDH VC-4 trail, an ATM VP trails 
> or an MPLS LSP
> trail (etc)........but they all clearly embrace:
> 	* simple breaks within/below the layer of interest
> 	* swapped/misconfigured trails
> 	* mismerged trails (these can only happen with co pkt 
> modes *and*
> relative addressing, ie labels....cnls pkts use *absolute* 
> addressing, ie
> each pkt carries a trail-trace by definition (ie source 
> address), which is a
> generic requirement as noted below and so complies).
> 
> -	2nd, since we know the data-plane trails carrying the 
> *traffic* can
> be totally decoupled from the data-plane trails carrying control
> (signalling/routing) or management plane protocols then each 
> data-plane must
> have its own defect detection/handling mechanisms which are (i) not
> dependent on any other specific client/server layer networks 
> (essential for
> technology compatibility/evolution....aka layer violations) 
> and (ii) not
> dependent on any specific control/mananagent-plane protocols (or their
> data-plane), inc none, for similar reasons....very obvious in 
> cct-sw/GMPLS
> applications IMO;
> 
> -	3rd, given above, its obvious that the data-plane (be 
> it carrying
> traffic/control/management protocols, which can be in 
> orthogonal data-plane
> network embodiments  please note) must carry its own OAM
> mechanisms.....again, very obvious in the case of cct-sw (esp 
> OTN), but same
> applies to pkt-sw.  Not so true in case of cnls.....where one can ask
> certain (higher level) control (say) plane protocols to proxy 
> for data-plane
> OAM.  The generic solution is here it to send some 
> 'trail-trace' identifier
> periodically source/sink......this is exactly what is done in 
> SDH VCs for
> example, and same should be done in pkt networks, ie same 
> generic principle.
> And as I noted above, cnls protocols like IP carry a trail-trace (ie
> absolute source address) in each/every pkt since the 
> addressing is absolute
> not relative (assuming globally unique addressing of 
> course).....so IP also
> fits the model for this aspect.
> 
> 
> -	4th, then define the entry/exit criteria for each defect inc the
> consequent actions one needs for each....some obvious ones being:
> 	* let's not have multiple client layer alarm storms 
> above the level
> of the defect (esp since these can be geograhically/organisationally
> disperse)...so we need some form of FDI (Forward Defect 
> Indication) for
> this.  So again this is a generic function, aka AIS in SDH/OTN.
> 	* some local alarm is needed....again pretty generic.
> 	* its useful to tell the source of far end failures in 
> some cases
> (ie single-ended both-direction monitoring of 
> QoS/availability SLAs say, or
> N:M prot-sw).....so this requires a generic BDI (Backward 
> Derect Indication)
> of some kind that mirrors the FDI.
> 	* with swapped/mismerged connections traffic 
> suppression is in order
> to protect the customer information integrity....again quite generic.
> 
> -	5th, in CO networks (be they pkt or cct-sw) 
> availabililty is the key
> perf metric.  So we can define this based on defect 
> persistence.  QoS metric
> measurements only makes sense when in the 'available' 
> state.....so if you
> want to offer/measure availability/QoS SLAs you need to pay 
> attention to
> this point.
> BTW - In Y.1711 I have drawn out the near-end/far-end 
> processing for LSPs
> wrt availability state to help people since this is the hard 
> bit.....though
> the actual protocol is trivial, ie its only 1 
> keepalive/trail-trace (CV) pkt
> in the up-state, and 2 pkts (FDI/BDI) in the down-state.  I 
> simply don't
> know where those who scream 'too complex' against this get it 
> from....I
> suspect they have never read and/or understood it.
> 
> So John, to return to your question.  SDH and OTNs frame 
> structures have the
> above concepts defined in them you will find and embody the 
> principles I
> outlined....all I have done is do the same for MPLS.  It's 
> got zero to do
> with any control-plane (or management-plane) protocols for 
> very obvious (esp
> here) reasons.
> 
> In summary, I would say what we have proposed for MPLS OAM is 
> actually very
> generic and not technology specific.....and so IMO is actually more
> in-keeping with the spirit of CCAMPs as a title (ie 
> 'common').  However, I
> can't take GTTP and say I can apply it to GMPLS......since its the
> *principles* that are enduring, not trying to force one 
> specific technology
> embodiment to fit all layers.
> 
> And that's about it....Neil
> 
> 
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: 05 March 2002 19:40
> > To: [email-masked]'; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: draft-bonica-tunneltrace-02 
> > 
> > 
> > Neil,
> > 
> > As a related question, would you please explain how your OAM 
> > proposal fits
> > against GMPLS?
> > 
> > Thanks,
> > 
> > John
<snipped>

Delivery-date: Wed, 06 Mar 2002 20:43:25 -0800
From: John Drake <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Wed, 6 Mar 2002 20:39:20 -0800 

Neil,

I asked a simple question and expected a simple answer.  Instead, you send
this example of incoherence raised to an arm form.  

Since you raised the specter of GMPLS, did you consider that we could just
as easily take the fault detection/isolation procedures of GMPLS and
re-apply them to MPLS? 

Thanks,

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 05, 2002 4:08 PM
To: John Drake; [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 

No problem John......really glad you asked this question as the answer is
dead easy:

The simple/one-liner answer is to ask you to read Y.1710.....I wrote this
after a conversation Maartin Vissers and I had a few years ago (on a bus in
Turin or somewhere) where we effectively said:
-	the network problems are effectively the same irrespective of the
technology, ie find/route/connect/maintain
-	there are some differences dependent on transfer mode, ie cnls is
different to co, and in co there are some differnces wrt to cct-sw vs
pkt-sw....but in essence, the 'network' problems are invariant
-	and focusssing in the OAM aspects one can lay down some principles
that are largely technology independent and quite generic....ergo Y.1710.

However, assuming one has never read Y.1710 the arguments follow this
general reasoning:

-	1st define the defects specific to the layer network/technology of
interest....now clearly these are different in specifics whether one is
considering an OTN trail, a SDH VC-4 trail, an ATM VP trails or an MPLS LSP
trail (etc)........but they all clearly embrace:
	* simple breaks within/below the layer of interest
	* swapped/misconfigured trails
	* mismerged trails (these can only happen with co pkt modes *and*
relative addressing, ie labels....cnls pkts use *absolute* addressing, ie
each pkt carries a trail-trace by definition (ie source address), which is a
generic requirement as noted below and so complies).

-	2nd, since we know the data-plane trails carrying the *traffic* can
be totally decoupled from the data-plane trails carrying control
(signalling/routing) or management plane protocols then each data-plane must
have its own defect detection/handling mechanisms which are (i) not
dependent on any other specific client/server layer networks (essential for
technology compatibility/evolution....aka layer violations) and (ii) not
dependent on any specific control/mananagent-plane protocols (or their
data-plane), inc none, for similar reasons....very obvious in cct-sw/GMPLS
applications IMO;

-	3rd, given above, its obvious that the data-plane (be it carrying
traffic/control/management protocols, which can be in orthogonal data-plane
network embodiments  please note) must carry its own OAM
mechanisms.....again, very obvious in the case of cct-sw (esp OTN), but same
applies to pkt-sw.  Not so true in case of cnls.....where one can ask
certain (higher level) control (say) plane protocols to proxy for data-plane
OAM.  The generic solution is here it to send some 'trail-trace' identifier
periodically source/sink......this is exactly what is done in SDH VCs for
example, and same should be done in pkt networks, ie same generic principle.
And as I noted above, cnls protocols like IP carry a trail-trace (ie
absolute source address) in each/every pkt since the addressing is absolute
not relative (assuming globally unique addressing of course).....so IP also
fits the model for this aspect.

-	4th, then define the entry/exit criteria for each defect inc the
consequent actions one needs for each....some obvious ones being:
	* let's not have multiple client layer alarm storms above the level
of the defect (esp since these can be geograhically/organisationally
disperse)...so we need some form of FDI (Forward Defect Indication) for
this.  So again this is a generic function, aka AIS in SDH/OTN.
	* some local alarm is needed....again pretty generic.
	* its useful to tell the source of far end failures in some cases
(ie single-ended both-direction monitoring of QoS/availability SLAs say, or
N:M prot-sw).....so this requires a generic BDI (Backward Derect Indication)
of some kind that mirrors the FDI.
	* with swapped/mismerged connections traffic suppression is in order
to protect the customer information integrity....again quite generic.

-	5th, in CO networks (be they pkt or cct-sw) availabililty is the key
perf metric.  So we can define this based on defect persistence.  QoS metric
measurements only makes sense when in the 'available' state.....so if you
want to offer/measure availability/QoS SLAs you need to pay attention to
this point.
BTW - In Y.1711 I have drawn out the near-end/far-end processing for LSPs
wrt availability state to help people since this is the hard bit.....though
the actual protocol is trivial, ie its only 1 keepalive/trail-trace (CV) pkt
in the up-state, and 2 pkts (FDI/BDI) in the down-state.  I simply don't
know where those who scream 'too complex' against this get it from....I
suspect they have never read and/or understood it.

So John, to return to your question.  SDH and OTNs frame structures have the
above concepts defined in them you will find and embody the principles I
outlined....all I have done is do the same for MPLS.  It's got zero to do
with any control-plane (or management-plane) protocols for very obvious (esp
here) reasons.

In summary, I would say what we have proposed for MPLS OAM is actually very
generic and not technology specific.....and so IMO is actually more
in-keeping with the spirit of CCAMPs as a title (ie 'common').  However, I
can't take GTTP and say I can apply it to GMPLS......since its the
*principles* that are enduring, not trying to force one specific technology
embodiment to fit all layers.

And that's about it....Neil

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: 05 March 2002 19:40
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> Neil,
> 
> As a related question, would you please explain how your OAM 
> proposal fits
> against GMPLS?
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 11:32 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> Eric...can you please explain how GMPLS fits against this 
> statement please?
> 
> regards, Neil
> 
> > -----Original Message-----
> > From: Eric Rosen [mailto:[email-masked]]
> > Sent: 05 March 2002 14:52
> > To: Shahram Davari
> > Cc: 'Thomas D. Nadeau'; [email-masked]
> > Subject: Re: draft-bonica-tunneltrace-02 
> > 
> > 
> > 
> > Shahram> What is  the difference between ATM,  FR, or any  CO 
> > technology and
> > Shahram> MPLS 
> > 
> > Well, for  one thing, MPLS  isn't a CO  technology.  It's got 
> > lots  of stuff
> > that doesn't really  make sense from a CO perspective.   Of 
> > course, when the
> > CO  guys  run  across  these  features  (multipoint-to-point, 
> >  php,  liberal
> > retention, independent  mode, equal  cost load balancing,  
> > dynamic rerouting
> > with no signaling,  ttl, lack of packet sequencing,  IP 
> > control plane, etc.,
> > etc.) they assume that those features are there by mistake!
> > 
> > This misconception  that MPLS  is a CO  technology, shared  
> > as it is  by the
> > "pure  IP" crowd and  by the  ITU/ATM crowd,  is the  source 
> > of  much wasted
> > time.  
> > 
> > MPLS is  actually an IP-derived technology that  facilitates 
> > the application
> > of  certain   circuit-like  characteristics  to  IP  
> > networks.    As  an  IP
> > technology,  the usual  IP diagnostic  tools, such  as ping  
> > and traceroute,
> > should be applicable.   That's what this whole useless  
> > discussion is about.
> > One  the one  side are  people  who think  that IP  networks 
> > are  inherently
> > unmanageable (after all, they don't  follow ITU standards), 
> > and on the other
> > side are people who think that the IP-based paradigms are the best. 
> > 
> > It is true that  MPLS can be used to provide something  which 
> > is very like a
> > CO network,  but it  doesn't have to  be used  this way, and  
> > usually isn't.
> > Those of use  who are not particularly interested in  CO 
> > networks just don't
> > want to be saddled with the  legacy CO mechanisms.  
> > Presumably, if all these
> > legacy CO mechanisms were  so great there would not be such  
> > a great rush to
> > IP. 
> > 
> > 
> > 
> > 
> > 
> 

Delivery-date: Wed, 06 Mar 2002 15:23:49 -0800
Date: Wed, 06 Mar 2002 16:57:16 -0600
From: John Fee <[email-masked]>
Subject: FW: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
To: [email-masked]
Cc: [email-masked], [email-masked]

[ post by non-subscriber ]

I vote #3.

Regards,

John Fee
WCOM
----

-----Original Message-----
From: Yong Xue [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 9:32 AM
To: [email-masked]; Curtis Brownmiller
Cc: Yong Xue
Subject: Fwd: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

Take this and reply to 'ccamp-wg ' <[email-masked]>

>-----Original Message-----
>From: Wijnen, Bert (Bert) [mailto:[email-masked]]
>Sent: Tuesday, February 26, 2002 10:37 AM
>To: ccamp-wg
>Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
>
>
>CCAMP WG members,
>
>before we start down another many 100s of emails re-discussing
>the same topic....
>
>PLEASE express your support for one of the 3 options that Kireeti
>posed to the WG. Don't elaborate... just help the WG chair(s) to
>figure out the (rough) consensus of the WG. The choices formulated
>by Kireeti:
>
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
>Thanks
>Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

Delivery-date: Wed, 06 Mar 2002 15:17:59 -0800
Date: Wed, 06 Mar 2002 23:16:55 +0000
From: Giles Heron <[email-masked]>
Organization: PacketExchange Ltd.
To: George Swallow <[email-masked]>
CC: Shahram Davari <[email-masked]>, 'Scott Bradner' <[email-masked]>, [email-masked]
Subject: Re: MPLS OAM & the IETF

George Swallow wrote:

>>Could you please clarify option (1) a bit more? If this route is
>>taken, still cooperation is needed between ITU and IETF. For example
>>ITU may need MPLS signaling extensions. Also in some cases packet
>>processing may need to be aligned between ITU and IETF in order to
>>avoid conflicts. For example ITU may consider an MPLS path-trace that
>>uses TTL expiration, which requires a TTL expired MPLS packet to be
>>forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL
>>expired packets to ICMP/GTTP module. There needs to be a coordination
>>between IETF and ITU in order to find a common method which could
>>determine whether a packet should be forwarded to OAM or ICMP/GTTP
>>module.
>>
> 
> It's precisely issues such as these that lead me to believe that it
> would be best if *only one* standards body owns a core technology.
> Certainly other bodies should be free to create applications, define
> extentions, and do implementation agreements.  But when it come to
> something a central as the basic forwarding plane, one group alone
> should handle it.
> 
> Allowing another body to redifine core functions WILL lead to
> interoperability problems.

Agreed.

I'm not sure which of Scott's options this corresponds to, though!  I 
don't want to see the IETF working on MPLS OAM as per option 2, but 
option 1 seems to be a step down the road of allowing the ITU to 
"co-own" MPLS?

Giles

> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
> 
> 
> 

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

Delivery-date: Wed, 06 Mar 2002 13:26:20 -0800
Date: Wed, 06 Mar 2002 15:57:24 -0500
From: Igor Faynberg <[email-masked]>
To: Scott Bradner <[email-masked]>, [email-masked]
Subject: RE: MPLS OAM & the IETF

Scott Bradner wrote:
[ post by non-subscriber ]

> So - please indicate your opinion on how the IETF should proceed
> 
> 1 - split the tasks between the IETF and the ITU-T
> 2 - IETF produce standards track documents covering both areas
>   2a - trying to work with the ITU-T to produce common technology
>   2b - in competition with the ITU-T

I would support option 1 (although it is not necessarily in conflict
with option 2a in that it will involve working with the ITU-T to produce
common technology, in my opinion).

Thanks to Scott for the precise summary of the issues!

Igor Faynberg

Envelope-to: [email-masked]
Delivery-date: Wed, 06 Mar 2002 10:42:19 -0800
Message-Id: <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-bonica-tunneltrace-02 
Date: Wed, 06 Mar 2002 13:40:36 -0500
From: George Swallow <[email-masked]>

Neil -

> Thanks Ping.....nice to see a positive response from a specific manufacturer
> to our concerns as operators on this.  This is a really good positive step
> IMO. Its a shame other manufacturers have discounted Y.1710, as what Enrique

Unlike the ITU, members of the IETF act as individuals.  It is
inappropriate to generalize the remarks of one person to an entire
company.  Further I believe that Tom was confused between Y.1710 and
Y.1711.

Y.1710 is a reasonable document.  Mostly great stuff that any vendor
wanting to sell to carriers should take very seriously.  As do I.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Envelope-to: [email-masked]
Delivery-date: Wed, 06 Mar 2002 09:53:32 -0800
Date: Wed, 6 Mar 2002 12:52:55 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: MPLS OAM & the IETF

> Are these kind of cooperations considered in option 1?

please advise

----

>From [email-masked]  Wed Mar  6 11:35:12 2002
From: Shahram Davari <[email-masked]>
To: "'Scott  Bradner'" <[email-masked]>, [email-masked]
Subject: RE: MPLS OAM & the IETF
Date: Wed, 6 Mar 2002 08:34:58 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain

Scott,

Could you please clarify option (1) a bit more? If this route is taken, still cooperation is needed between ITU and IETF. For example ITU may need MPLS signaling extensions. Also in some cases packet processing may need to be aligned between ITU and IETF in order to avoid conflicts. For example ITU may consider an MPLS path-trace that uses TTL expiration, which requires a TTL expired MPLS packet to be forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL expired packets to ICMP/GTTP module. There needs to be a coordination between IETF and ITU in order to find a common method which could determine whether a packet should be forwarded to OAM or ICMP/GTTP module.

Are these kind of cooperations considered in option 1?

Shahram

> -----Original Message-----
> From: Scott Bradner [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 10:34 AM
> To: [email-masked]
> Subject: MPLS OAM & the IETF
> 
> 
> subject:   MPLS OAM & the IETF
> 
> The result of the MPLS OAM BOF in Salt Lake City has been 
> confirmed over
> the last few days in the mailing list thread 
> "draft-bonica-tunneltrace-02."
> 
> 
> That result was and is that there are at least two quite 
> different views on
> the type of OAM tools and technologies needed for MPLS networks.  
> 
> My reading of the groups is that one group, who are mostly 
> concerned with
> the transport of IP over MPLS, generally feel that tools 
> approximating the
> traditional "ping" and "traceroute" tools used on IP networks are
> sufficient.  A second group seems to feel that those tools do 
> not provide
> enough of a view of the service a customer is getting to be 
> sufficient and
> that tools approximating traditional telephone system OAM 
> tools are needed
> to get the complete picture.
> 
> Meanwhile, the ITU-T has been working in this area and has a 
> document in
> their equivalent of the IETF Last-Call. Brian Moore, the 
> ITU-T Study Group
> 13 chair, kindly arraigned for the ITU-T document (known as 
> Y.1711) to be
> put on an ftp site so interested IETF folk can take a look at 
> what they
> have done.  The URL is 
> http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.ht
ml (IETF folk
have to register to use the FTP site.)

It seems to me that there are two options on what we (the IETF) could do at
this point.

0/ you think I do not understand the issue

1/ split the tasks:  The IETF focus on the ping/traceroute mechanisms and
cede to the ITU-T work on the more telco-like OAM.  In this option the IETF
would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an
MPLS reserved label value for use by the ITU-T to identify Y.1711
information.

2/ The IETF work on a suite of technologies ranging from the
ping/traceroute-like mechanisms to the more telephone system OAM ones.  The
IETF could try to figure out how to do this in conjunction with the ITU,
though it is a bit late for that considering the state of Y.1711, or be in
competition with the ITU-T.  

So - please indicate your opinion on how the IETF should proceed

1 - split the tasks between the IETF and the ITU-T
2 - IETF produce standards track documents covering both areas
  2a - trying to work with the ITU-T to produce common technology
  2b - in competition with the ITU-T

In any case, it would be good to provide feedback to the ITU-T on Y.1711 if
you see anything that looks broken.

Scott (with sub-ip AD hat on)

Delivery-date: Wed, 06 Mar 2002 09:38:49 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-02.txt
Date: Wed, 06 Mar 2002 12:37:36 -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 Multi-Protocol Label Switching (GMPLS) 
                          Architecture
	Author(s)	: E. Mannie et al.
	Filename	: draft-ietf-ccamp-gmpls-architecture-02.txt
	Pages		: 56
	Date		: 05-Mar-02
	
Future data and transmission networks will consist of elements such 
as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), 
photonic cross-connects (PXCs), optical cross-connects (OXCs), etc 
that will use Generalized MPLS (GMPLS) to dynamically provision 
resources and to provide network survivability using protection and 
restoration techniques.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-02.txt

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

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

--OtherAccess--

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Wed, 06 Mar 2002 09:26:54 -0800
Message-Id: <[email-masked]>
To: Shahram Davari <[email-masked]>
cc: "'Scott Bradner'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: MPLS OAM & the IETF 
Date: Wed, 06 Mar 2002 12:25:49 -0500
From: George Swallow <[email-masked]>

> Could you please clarify option (1) a bit more? If this route is
> taken, still cooperation is needed between ITU and IETF. For example
> ITU may need MPLS signaling extensions. Also in some cases packet
> processing may need to be aligned between ITU and IETF in order to
> avoid conflicts. For example ITU may consider an MPLS path-trace that
> uses TTL expiration, which requires a TTL expired MPLS packet to be
> forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL
> expired packets to ICMP/GTTP module. There needs to be a coordination
> between IETF and ITU in order to find a common method which could
> determine whether a packet should be forwarded to OAM or ICMP/GTTP
> module.

It's precisely issues such as these that lead me to believe that it
would be best if *only one* standards body owns a core technology.
Certainly other bodies should be free to create applications, define
extentions, and do implementation agreements.  But when it come to
something a central as the basic forwarding plane, one group alone
should handle it.

Allowing another body to redifine core functions WILL lead to
interoperability problems.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Wed, 06 Mar 2002 08:36:03 -0800
From: Shahram Davari <[email-masked]>
To: "'Scott  Bradner'" <[email-masked]>, [email-masked]
Subject: RE: MPLS OAM & the IETF
Date: Wed, 6 Mar 2002 08:34:58 -0800 

Scott,

Could you please clarify option (1) a bit more? If this route is taken, still cooperation is needed between ITU and IETF. For example ITU may need MPLS signaling extensions. Also in some cases packet processing may need to be aligned between ITU and IETF in order to avoid conflicts. For example ITU may consider an MPLS path-trace that uses TTL expiration, which requires a TTL expired MPLS packet to be forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL expired packets to ICMP/GTTP module. There needs to be a coordination between IETF and ITU in order to find a common method which could determine whether a packet should be forwarded to OAM or ICMP/GTTP module.

Are these kind of cooperations considered in option 1?

Shahram

> -----Original Message-----
> From: Scott Bradner [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 10:34 AM
> To: [email-masked]
> Subject: MPLS OAM & the IETF
> 
> 
> subject:   MPLS OAM & the IETF
> 
> The result of the MPLS OAM BOF in Salt Lake City has been 
> confirmed over
> the last few days in the mailing list thread 
> "draft-bonica-tunneltrace-02."
> 
> 
> That result was and is that there are at least two quite 
> different views on
> the type of OAM tools and technologies needed for MPLS networks.  
> 
> My reading of the groups is that one group, who are mostly 
> concerned with
> the transport of IP over MPLS, generally feel that tools 
> approximating the
> traditional "ping" and "traceroute" tools used on IP networks are
> sufficient.  A second group seems to feel that those tools do 
> not provide
> enough of a view of the service a customer is getting to be 
> sufficient and
> that tools approximating traditional telephone system OAM 
> tools are needed
> to get the complete picture.
> 
> Meanwhile, the ITU-T has been working in this area and has a 
> document in
> their equivalent of the IETF Last-Call. Brian Moore, the 
> ITU-T Study Group
> 13 chair, kindly arraigned for the ITU-T document (known as 
> Y.1711) to be
> put on an ftp site so interested IETF folk can take a look at 
> what they
> have done.  The URL is 
> http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.ht
ml (IETF folk
have to register to use the FTP site.)

It seems to me that there are two options on what we (the IETF) could do at
this point.

0/ you think I do not understand the issue

1/ split the tasks:  The IETF focus on the ping/traceroute mechanisms and
cede to the ITU-T work on the more telco-like OAM.  In this option the IETF
would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an
MPLS reserved label value for use by the ITU-T to identify Y.1711
information.

2/ The IETF work on a suite of technologies ranging from the
ping/traceroute-like mechanisms to the more telephone system OAM ones.  The
IETF could try to figure out how to do this in conjunction with the ITU,
though it is a bit late for that considering the state of Y.1711, or be in
competition with the ITU-T.  

So - please indicate your opinion on how the IETF should proceed

1 - split the tasks between the IETF and the ITU-T
2 - IETF produce standards track documents covering both areas
  2a - trying to work with the ITU-T to produce common technology
  2b - in competition with the ITU-T

In any case, it would be good to provide feedback to the ITU-T on Y.1711 if
you see anything that looks broken.

Scott (with sub-ip AD hat on)

Delivery-date: Wed, 06 Mar 2002 08:09:41 -0800
From: [email-masked]
Date: Wed, 6 Mar 2002 10:07:42 -0600
Subject: RE: MPLS OAM & the IETF
TO: [email-masked], [email-masked]

2a is ideal.  If that  doesn't work (for several reasons :-) ), 1 is 
acceptable.

Ananth

[snip]
>1 - split the tasks between the IETF and the ITU-T
>2 - IETF produce standards track documents covering both areas
>  2a - trying to work with the ITU-T to produce common technology
>  2b - in competition with the ITU-T

Delivery-date: Wed, 06 Mar 2002 07:59:50 -0800
Date: Wed, 06 Mar 2002 10:58:52 -0500
To: "David Allan"<[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
Cc: Shahram Davari <[email-masked]>, "'Ron Bonica'" <[email-masked]>, [email-masked], [email-masked]

>Tom & co...
>
>I have to admit I am not finding some of these arguments to be 
>consistent......
>
>If traceroute is an excellent example of a protocol that works, why not 
>simply re-use it. Genericize Ron's proposal for MPLS extensions to ICMP 
>and you're done. No more justification or requirements required.
>
>If the intent is to fix shortcomings with traceroute by inventing a new 
>protocol, then all bets should be off, because you are saying the working 
>example of a good solution is broken or lacking in some way. And the 
>requirements document should cover in detail the problems to be solved (or 
>re-solved as the case may be e.g. broadcast filtering etc.). In this 
>regard I would consider the requirements document to be seriously lacking.
>
>Now process wise, if the intent is to have the cart before the horse (or 
>it is that way accidentally or for some historical reasons), why are not 
>the requirements and the solution proposed as WG documents 
>simultaneously?...they are joined at the hip anyway. If the actual binding 
>is not so simple, then the specific dependencies between the two should be 
>eliminated before this is a genuine "work item".

         I think that this thread has made it clear that Ron's requirements 
document should be
a WG document in either case, since there is a clear need to capture these 
requirements
in an IETF document, regardless of whether you agree with the current 
working of the
requirements. If you do not, then we should (and have) discuss changing 
them.  As a WG document
we can work towards constructively specifying the requirements so that we 
can make solutions
work for the working group. The GTTP document proposes one solution to the 
requirements in
the document. If you think you have a better solution, feel free to post a 
draft with the details. 8)

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Envelope-to: [email-masked]
Delivery-date: Wed, 06 Mar 2002 07:42:31 -0800
Message-Id: <[email-masked]>
To: Giles Heron <[email-masked]>
cc: David Allan <[email-masked]>, [email-masked], Shahram Davari <[email-masked]>, "'Thomas D. Nadeau'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Well off the original thread topic... draft-bonica-tunneltrace-02 
Date: Wed, 06 Mar 2002 10:42:10 -0500
From: George Swallow <[email-masked]>

> >  > 2)  MPLS VPN (RFC2547).  I won't go into the pros and cons of
> >  > this right
> >  > now ;-)
> > 
> > Current implementation is MPLS but I don't think there is a sustainable 
> > dependency there...LDP permits the undelying MPLS network to behave like 
> > an IP network. Seems to me they should be interchangable.
> 
> 
> they are - the above issues notwithstanding.

Which is a very good argument at to why IP based OAM tools are a good
idea.  Maybe even a *requirement*.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Wed, 06 Mar 2002 07:38:41 -0800
From: "David Allan"<[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>, Shahram Davari <[email-masked]>
Cc: "'Ron Bonica'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 6 Mar 2002 10:38:15 -0500 

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

------_=_NextPart_001_01C1C524.EEC46F30
Content-Type: text/plain;
	charset="iso-8859-1"

Tom & co...

I have to admit I am not finding some of these arguments to be
consistent......

If traceroute is an excellent example of a protocol that works, why not
simply re-use it. Genericize Ron's proposal for MPLS extensions to ICMP and
you're done. No more justification or requirements required.

If the intent is to fix shortcomings with traceroute by inventing a new
protocol, then all bets should be off, because you are saying the working
example of a good solution is broken or lacking in some way. And the
requirements document should cover in detail the problems to be solved (or
re-solved as the case may be e.g. broadcast filtering etc.). In this regard
I would consider the requirements document to be seriously lacking.

Now process wise, if the intent is to have the cart before the horse (or it
is that way accidentally or for some historical reasons), why are not the
requirements and the solution proposed as WG documents
simultaneously?...they are joined at the hip anyway. If the actual binding
is not so simple, then the specific dependencies between the two should be
eliminated before this is a genuine "work item".

my last two cents
Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 3:56 PM
> To: Shahram Davari
> Cc: 'Ron Bonica'; [email-masked]; Allan, David [CAR:NS00:EXCH];
> [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> At 12:25 PM 3/5/2002 -0800, Shahram Davari wrote:
> >Ron,
> >
> > > We should not be surprised that
> > > the enhanced
> > > route tracing application resembles the current "traceroute"
> > > in that a) it
> > > is based upon probes and responses, b) UDP carries its PDUs,
> > > and c) it is
> > > stateless.
> > >
> >
> >I am not surprised at all. What you are suggesting is
> >your desire to resemble the IP traceroute. But this is only
> >a desire and there is no technical reason why it should or it
> >should not resemble the IP traceroute.
> 
>          Sure there is; IP traceroute works.  This is one of 
> the best reasons
> in my mind.
> 
>          --Tom
> 
> 
> >A requirements document should leave the door open for other
> >innovative ideas, unless you can prove that the traceroute-like
> >mechanism is the BEST.
> >
> >-Shahram
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 
> 

------_=_NextPart_001_01C1C524.EEC46F30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: draft-bonica-tunneltrace-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Tom &amp; co...</FONT>
</P>

<P><FONT SIZE=3D2>I have to admit I am not finding some of these =
arguments to be consistent......</FONT>
</P>

<P><FONT SIZE=3D2>If traceroute is an excellent example of a protocol =
that works, why not simply re-use it. Genericize Ron's proposal for =
MPLS extensions to ICMP and you're done. No more justification or =
requirements required.</FONT></P>

<P><FONT SIZE=3D2>If the intent is to fix shortcomings with traceroute =
by inventing a new protocol, then all bets should be off, because you =
are saying the working example of a good solution is broken or lacking =
in some way. And the requirements document should cover in detail the =
problems to be solved (or re-solved as the case may be e.g. broadcast =
filtering etc.). In this regard I would consider the requirements =
document to be seriously lacking.</FONT></P>

<P><FONT SIZE=3D2>Now process wise, if the intent is to have the cart =
before the horse (or it is that way accidentally or for some historical =
reasons), why are not the requirements and the solution proposed as WG =
documents simultaneously?...they are joined at the hip anyway. If the =
actual binding is not so simple, then the specific dependencies between =
the two should be eliminated before this is a genuine &quot;work =
item&quot;.</FONT></P>

<P><FONT SIZE=3D2>my last two cents</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Thomas D. Nadeau [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, March 05, 2002 3:56 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Shahram Davari</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Ron Bonica'; [email-masked]; Allan, =
David [CAR:NS00:EXCH];</FONT>
<BR><FONT SIZE=3D2>&gt; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: draft-bonica-tunneltrace-02</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 12:25 PM 3/5/2002 -0800, Shahram Davari =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Ron,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; We should not be surprised =
that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the enhanced</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; route tracing application resembles =
the current &quot;traceroute&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; in that a) it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; is based upon probes and responses, =
b) UDP carries its PDUs,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; and c) it is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; stateless.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I am not surprised at all. What you are =
suggesting is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;your desire to resemble the IP traceroute. =
But this is only</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;a desire and there is no technical reason =
why it should or it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;should not resemble the IP =
traceroute.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Sure there is; IP traceroute works.&nbsp; This is one of </FONT>
<BR><FONT SIZE=3D2>&gt; the best reasons</FONT>
<BR><FONT SIZE=3D2>&gt; in my mind.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--Tom</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;A requirements document should leave the =
door open for other</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;innovative ideas, unless you can prove that =
the traceroute-like</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;mechanism is the BEST.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;-Shahram</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; ----------</FONT>
<BR><FONT SIZE=3D2>&gt; Mathematics is the supreme nostalgia of our =
time. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C524.EEC46F30--

Envelope-to: [email-masked]
Delivery-date: Wed, 06 Mar 2002 07:38:12 -0800
Date: Wed, 6 Mar 2002 10:33:52 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: MPLS OAM & the IETF

subject:   MPLS OAM & the IETF

The result of the MPLS OAM BOF in Salt Lake City has been confirmed over
the last few days in the mailing list thread "draft-bonica-tunneltrace-02."

That result was and is that there are at least two quite different views on
the type of OAM tools and technologies needed for MPLS networks.  

My reading of the groups is that one group, who are mostly concerned with
the transport of IP over MPLS, generally feel that tools approximating the
traditional "ping" and "traceroute" tools used on IP networks are
sufficient.  A second group seems to feel that those tools do not provide
enough of a view of the service a customer is getting to be sufficient and
that tools approximating traditional telephone system OAM tools are needed
to get the complete picture.

Meanwhile, the ITU-T has been working in this area and has a document in
their equivalent of the IETF Last-Call. Brian Moore, the ITU-T Study Group
13 chair, kindly arraigned for the ITU-T document (known as Y.1711) to be
put on an ftp site so interested IETF folk can take a look at what they
have done.  The URL is 
http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.html (IETF folk
have to register to use the FTP site.)

It seems to me that there are two options on what we (the IETF) could do at
this point.

0/ you think I do not understand the issue

1/ split the tasks:  The IETF focus on the ping/traceroute mechanisms and
cede to the ITU-T work on the more telco-like OAM.  In this option the IETF
would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an
MPLS reserved label value for use by the ITU-T to identify Y.1711
information.

2/ The IETF work on a suite of technologies ranging from the
ping/traceroute-like mechanisms to the more telephone system OAM ones.  The
IETF could try to figure out how to do this in conjunction with the ITU,
though it is a bit late for that considering the state of Y.1711, or be in
competition with the ITU-T.  

So - please indicate your opinion on how the IETF should proceed

1 - split the tasks between the IETF and the ITU-T
2 - IETF produce standards track documents covering both areas
  2a - trying to work with the ITU-T to produce common technology
  2b - in competition with the ITU-T

In any case, it would be good to provide feedback to the ITU-T on Y.1711 if
you see anything that looks broken.

Scott (with sub-ip AD hat on)

Delivery-date: Wed, 06 Mar 2002 04:58:10 -0800
From: "Mannie, Eric" <[email-masked]>
To: [email-masked]
Subject: Re-published SDH/SONET drafts
Date: Wed, 6 Mar 2002 13:55:05 +0100 

Dear All,

FYI,

I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt

The two SDH/SONET drafts have been re-published as they were sent in
December on the CCAMP mailing list in agreement with the WG chairs (i.e.
before the discussion that just occurred on the CCAMP mailing list). They
were published to have a common basis for discussion, to reflect the changes
that were requested during the last IETF, and simply to be available in the
directory of internet-drafts.

Kind regards,

Eric

Delivery-date: Wed, 06 Mar 2002 03:19:45 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-02.txt
Date: Wed, 06 Mar 2002 06:19:07 -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 Multi-Protocol Label Switching (GMPLS) 
                          Architecture
	Author(s)	: E. Mannie et al.
	Filename	: draft-ietf-ccamp-gmpls-architecture-02.txt
	Pages		: 56
	Date		: 05-Mar-02
	
Future data and transmission networks will consist of elements such 
as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), 
photonic cross-connects (PXCs), optical cross-connects (OXCs), etc 
that will use Generalized MPLS (GMPLS) to dynamically provision 
resources and to provide network survivability using protection and 
restoration techniques.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-02.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 06 Mar 2002 03:19:40 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt
Date: Wed, 06 Mar 2002 06:19:03 -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		: GMPLS Extensions to Control Non-Standard SONET and SDH
                          Features
	Author(s)	: E. Mannie et al.
	Filename	: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt
	Pages		: 12
	Date		: 05-Mar-02
	
This document is a companion to the GMPLS signaling extensions to 
control SONET and SDH document [GMPLS-SONET-SDH] that defines the 
SONET/SDH technology specific information needed when using GMPLS 
signaling. 
This informational document defines GMPLS signaling extensions to 
control three optional non-standard (i.e. proprietary) SONET and 
SDH features: arbitrary concatenation, per byte transparency and 
the virtual concatenation of contiguously concatenated signals.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-sonet-sdh-extensions-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: Wed, 06 Mar 2002 03:19:37 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
Date: Wed, 06 Mar 2002 06:18:58 -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		: GMPLS Extensions for SONET and SDH Control
	Author(s)	: P. Ashwood-Smith et al.
	Filename	: draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
	Pages		: 19
	Date		: 05-Mar-02
	
This document is a companion to the Generalized MPLS signaling 
documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP].  It defines 
the SONET/SDH technology specific information needed when using 
GMPLS signaling.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-sonet-sdh-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, 06 Mar 2002 03:00:29 -0800
From: Sasha Vainshtein <[email-masked]>
To: 'Scott  Bradner' <[email-masked]>, [email-masked],  [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: WG document status
Date: Wed, 6 Mar 2002 12:49:43 +0200 

Scott,
Thank you for clarification.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Scott Bradner [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 6:23 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: WG document status
> 
> 
> > Does not RFC 2026 overrule the previous requirements, 
> 
> the pp in 2026 you note gives the IESG (backing up a AD for example)
> flexibility to support the type of thing that the routing AD did
> 
> from 2026 sec 4.1.1
>    The IESG may require implementation and/or operational experience
>    prior to granting Proposed Standard status to a specification that
>    materially affects the core Internet protocols or that specifies
>    behavior that may have significant operational impact on the 
>    Internet.
> 
> Scott
> 

Delivery-date: Tue, 05 Mar 2002 16:22:59 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: AdSpec Object usage in GMPLS
Date: Tue, 05 Mar 2002 15:43:31 -0700

[ post by non-subscriber ]

Hi All,
          Can someone please explain the usage of AdSpec object in
establishment of LSC/FSC/TDM LSP in GMPLS-RSVP-TE ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Delivery-date: Tue, 05 Mar 2002 16:08:13 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Wed, 6 Mar 2002 00:07:36 -0000 

No problem John......really glad you asked this question as the answer is
dead easy:

The simple/one-liner answer is to ask you to read Y.1710.....I wrote this
after a conversation Maartin Vissers and I had a few years ago (on a bus in
Turin or somewhere) where we effectively said:
-	the network problems are effectively the same irrespective of the
technology, ie find/route/connect/maintain
-	there are some differences dependent on transfer mode, ie cnls is
different to co, and in co there are some differnces wrt to cct-sw vs
pkt-sw....but in essence, the 'network' problems are invariant
-	and focusssing in the OAM aspects one can lay down some principles
that are largely technology independent and quite generic....ergo Y.1710.

However, assuming one has never read Y.1710 the arguments follow this
general reasoning:

-	1st define the defects specific to the layer network/technology of
interest....now clearly these are different in specifics whether one is
considering an OTN trail, a SDH VC-4 trail, an ATM VP trails or an MPLS LSP
trail (etc)........but they all clearly embrace:
	* simple breaks within/below the layer of interest
	* swapped/misconfigured trails
	* mismerged trails (these can only happen with co pkt modes *and*
relative addressing, ie labels....cnls pkts use *absolute* addressing, ie
each pkt carries a trail-trace by definition (ie source address), which is a
generic requirement as noted below and so complies).

-	2nd, since we know the data-plane trails carrying the *traffic* can
be totally decoupled from the data-plane trails carrying control
(signalling/routing) or management plane protocols then each data-plane must
have its own defect detection/handling mechanisms which are (i) not
dependent on any other specific client/server layer networks (essential for
technology compatibility/evolution....aka layer violations) and (ii) not
dependent on any specific control/mananagent-plane protocols (or their
data-plane), inc none, for similar reasons....very obvious in cct-sw/GMPLS
applications IMO;

-	3rd, given above, its obvious that the data-plane (be it carrying
traffic/control/management protocols, which can be in orthogonal data-plane
network embodiments  please note) must carry its own OAM
mechanisms.....again, very obvious in the case of cct-sw (esp OTN), but same
applies to pkt-sw.  Not so true in case of cnls.....where one can ask
certain (higher level) control (say) plane protocols to proxy for data-plane
OAM.  The generic solution is here it to send some 'trail-trace' identifier
periodically source/sink......this is exactly what is done in SDH VCs for
example, and same should be done in pkt networks, ie same generic principle.
And as I noted above, cnls protocols like IP carry a trail-trace (ie
absolute source address) in each/every pkt since the addressing is absolute
not relative (assuming globally unique addressing of course).....so IP also
fits the model for this aspect.

-	4th, then define the entry/exit criteria for each defect inc the
consequent actions one needs for each....some obvious ones being:
	* let's not have multiple client layer alarm storms above the level
of the defect (esp since these can be geograhically/organisationally
disperse)...so we need some form of FDI (Forward Defect Indication) for
this.  So again this is a generic function, aka AIS in SDH/OTN.
	* some local alarm is needed....again pretty generic.
	* its useful to tell the source of far end failures in some cases
(ie single-ended both-direction monitoring of QoS/availability SLAs say, or
N:M prot-sw).....so this requires a generic BDI (Backward Derect Indication)
of some kind that mirrors the FDI.
	* with swapped/mismerged connections traffic suppression is in order
to protect the customer information integrity....again quite generic.

-	5th, in CO networks (be they pkt or cct-sw) availabililty is the key
perf metric.  So we can define this based on defect persistence.  QoS metric
measurements only makes sense when in the 'available' state.....so if you
want to offer/measure availability/QoS SLAs you need to pay attention to
this point.
BTW - In Y.1711 I have drawn out the near-end/far-end processing for LSPs
wrt availability state to help people since this is the hard bit.....though
the actual protocol is trivial, ie its only 1 keepalive/trail-trace (CV) pkt
in the up-state, and 2 pkts (FDI/BDI) in the down-state.  I simply don't
know where those who scream 'too complex' against this get it from....I
suspect they have never read and/or understood it.

So John, to return to your question.  SDH and OTNs frame structures have the
above concepts defined in them you will find and embody the principles I
outlined....all I have done is do the same for MPLS.  It's got zero to do
with any control-plane (or management-plane) protocols for very obvious (esp
here) reasons.

In summary, I would say what we have proposed for MPLS OAM is actually very
generic and not technology specific.....and so IMO is actually more
in-keeping with the spirit of CCAMPs as a title (ie 'common').  However, I
can't take GTTP and say I can apply it to GMPLS......since its the
*principles* that are enduring, not trying to force one specific technology
embodiment to fit all layers.

And that's about it....Neil

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: 05 March 2002 19:40
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> Neil,
> 
> As a related question, would you please explain how your OAM 
> proposal fits
> against GMPLS?
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 11:32 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> Eric...can you please explain how GMPLS fits against this 
> statement please?
> 
> regards, Neil
> 
> > -----Original Message-----
> > From: Eric Rosen [mailto:[email-masked]]
> > Sent: 05 March 2002 14:52
> > To: Shahram Davari
> > Cc: 'Thomas D. Nadeau'; [email-masked]
> > Subject: Re: draft-bonica-tunneltrace-02 
> > 
> > 
> > 
> > Shahram> What is  the difference between ATM,  FR, or any  CO 
> > technology and
> > Shahram> MPLS 
> > 
> > Well, for  one thing, MPLS  isn't a CO  technology.  It's got 
> > lots  of stuff
> > that doesn't really  make sense from a CO perspective.   Of 
> > course, when the
> > CO  guys  run  across  these  features  (multipoint-to-point, 
> >  php,  liberal
> > retention, independent  mode, equal  cost load balancing,  
> > dynamic rerouting
> > with no signaling,  ttl, lack of packet sequencing,  IP 
> > control plane, etc.,
> > etc.) they assume that those features are there by mistake!
> > 
> > This misconception  that MPLS  is a CO  technology, shared  
> > as it is  by the
> > "pure  IP" crowd and  by the  ITU/ATM crowd,  is the  source 
> > of  much wasted
> > time.  
> > 
> > MPLS is  actually an IP-derived technology that  facilitates 
> > the application
> > of  certain   circuit-like  characteristics  to  IP  
> > networks.    As  an  IP
> > technology,  the usual  IP diagnostic  tools, such  as ping  
> > and traceroute,
> > should be applicable.   That's what this whole useless  
> > discussion is about.
> > One  the one  side are  people  who think  that IP  networks 
> > are  inherently
> > unmanageable (after all, they don't  follow ITU standards), 
> > and on the other
> > side are people who think that the IP-based paradigms are the best. 
> > 
> > It is true that  MPLS can be used to provide something  which 
> > is very like a
> > CO network,  but it  doesn't have to  be used  this way, and  
> > usually isn't.
> > Those of use  who are not particularly interested in  CO 
> > networks just don't
> > want to be saddled with the  legacy CO mechanisms.  
> > Presumably, if all these
> > legacy CO mechanisms were  so great there would not be such  
> > a great rush to
> > IP. 
> > 
> > 
> > 
> > 
> > 
> 

Delivery-date: Tue, 05 Mar 2002 16:08:10 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Wed, 6 Mar 2002 00:07:40 -0000 

So do mine.

Ours are documented in Y.1710 where are your documented?

regards, Neil

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: 05 March 2002 19:42
> To: neil.2.harrison
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> 
> >Tom...I suspect Enrique is saying this because that is the 
> only place he is
> >aware that they are written down and, since this is from the ITU, by
> >definition must have operator agreement.  Can you please 
> provide us with a
> >reference to the requirements documents that you are working to?
> 
>          My requirements come from my customers' operational 
> departments.
> 
>          --Tom
> 
> 
> 
> >thanks & regards, Neil
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau [mailto:[email-masked]]
> > > Sent: 05 March 2002 17:01
> > > To: Cuevas, Enrique G, ALASO
> > > Cc: David Allan; Shahram Davari; ccamp
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > >
> > >          Why are we still discussing Y.1710? I thought that this
> > > was the IETF. The following seem to comply with the operational
> > > OAM requirements I am hearing from operators.
> > >
> > >           LSP "ping",
> > >           LSP Traceroute
> > >           MIBs
> > >
> > >          Others may be required.
> > >
> > >          --Tom
> > >
> > >
> > > >Could you provide us with a matrix (comply/does not comply)
> > > of the tools
> > > >you are
> > > >talking about vs. the requirements given in Y.1710?
> > > >
> > > >Enrique
> > > >_______________
> > > >[email-masked]
> > > >Tel. (732)-420-3252
> > > >
> > > >
> > > > >-----Original Message-----
> > > > >From: Thomas D. Nadeau [mailto:[email-masked]]
> > > > >Sent: Tuesday, March 05, 2002 9:07 AM
> > > > >To: David Allan
> > > > >Cc: Shahram Davari; [email-masked]
> > > > >Subject: RE: draft-bonica-tunneltrace-02
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >>Your statement that requirements support the tools/mechanisms
> > > > >that work
> > > > >>today is the nib of my concern. Basically the 
> requirments step is
> > > > >>redundant at that point. We are now in a tight 
> embrace where the
> > > > >>requirements justify the solution and the solution 
> dictates the
> > > > >>requirements. Suggesting the requirements is a WG work item
> > > > >would appear
> > > > >>to be an oxymoron.
> > > > >
> > > > >         As I mentioned, some of the tools have 
> already been worked
> > > > >out, so yes, the cart is before the horse in some 
> cases. However,
> > > > >I don't think that this is necessarily a problem.
> > > > >
> > > > >         --Tom
> > > > >
> > > > >
> > > > >
> > > > >>Dave
> > > > >>
> > > > >> > -----Original Message-----
> > > > >> > From: Thomas D. Nadeau
> > > > >> [<mailto:[email-masked]>mailto:[email-masked]]
> > > > >> > Sent: Monday, March 04, 2002 5:47 PM
> > > > >> > To: Shahram Davari
> > > > >> > Cc: [email-masked]
> > > > >> > Subject: RE: draft-bonica-tunneltrace-02
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > >Thanks for your positive response. With regards to the
> > > > >> > protocol requirements,
> > > > >> > >which ones do you think MUST be there and why?
> > > > >> >
> > > > >> >          I think that the protocol requirements for those
> > > > >> > solutions that
> > > > >> > currently
> > > > >> > exist should be in there.  I understand your point about
> > > > >> > reverse engineering the tools, but unfortunately the
> > > > >> > requirement writing effort
> > > > >> > started after we had some solutions working. Therefore
> > > > >> > protocol requirements
> > > > >> > do matter because they support the 
> tools/mechanisms that work
> > > > >> > today. No
> > > > >> > need to obviate those things at this point.
> > > > >> >
> > > > >> > >In my view protocol requirements should not unnecessarily
> > > > >> > restrict the
> > > > >> > >solution,
> > > > >> > >unless they violate application requirements.
> > > > >> >
> > > > >> >          I think that protocol requirements should 
> be in line
> > > > >> > with the
> > > > >> > application
> > > > >> > requirements that have come from operational folks 
> working at
> > > > >> > SPs.  However,
> > > > >> > application requirements should fit within 
> existing protocols
> > > > >> > as much as
> > > > >> > possible (to promote reuse of existing software/tools).
> > > > >We should not
> > > > >> > be forced to reinvent the wheel just for the sake 
> of doing so.
> > > > >> >
> > > > >> >          --Tom
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > >-Shahram
> > > > >> > >
> > > > >> > > > -----Original Message-----
> > > > >> > > > From: Thomas D. Nadeau
> > > > >> [<mailto:[email-masked]>mailto:[email-masked]]
> > > > >> > > > Sent: Monday, March 04, 2002 4:25 PM
> > > > >> > > > To: Shahram Davari
> > > > >> > > > Cc: [email-masked]
> > > > >> > > > Subject: RE: draft-bonica-tunneltrace-02
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > >I think instead of debating whether Y.1711 is 
> better than
> > > > >> > > > LSP-ping/GTTP or
> > > > >> > > > >vice versa, it would be more
> > > > >> > > > >constructive to identify and document the 
> applicability of
> > > > >> > > > each proposal
> > > > >> > > > >for various tunneling applications.
> > > > >> > > >
> > > > >> > > >          This sounds like a move in the right 
> direction.
> > > > >> > > >
> > > > >> > > > >For this particular draft my suggestion at 
> this stage is
> > > > >> > > > that the Bonica's
> > > > >> > > > >requirement draft be revised to:
> > > > >> > > > >
> > > > >> > > > >1) Add text (or at least a place holder) for 
> additional
> > > > >> > > > security issues
> > > > >> > > > >raised on the list.
> > > > >> > > > >2) Add backward compatibility, simplicity and
> > > scalability as
> > > > >> > > > requirements.
> > > > >> > > >
> > > > >> > > >          I can go along with those.
> > > > >> > > >
> > > > >> > > > >3) Remove the protocol requirements section, since any
> > > > >> > > > requirement here
> > > > >> > > > >will be viewed as a reverse engineering of 
> some solution.
> > > > >> > > >
> > > > >> > > >          Although this might sound reasonable 
> to some, I
> > > > >> > > > think that some
> > > > >> > > > may object to this
> > > > >> > > > since the protocol requirements are viewed by some as
> > > > >> > > > fundamental to the
> > > > >> > > > requirements
> > > > >> > > > of any particular solution.  In the flurry of 
> emails on the
> > > > >> > > > topic, I have
> > > > >> > > > not been able to
> > > > >> > > > keep track of what the consensus on this might 
> be (either
> > > > >> > > > way). Perhaps Ron
> > > > >> > > > has been keeping
> > > > >> > > > track?
> > > > >> > > >
> > > > >> > > > >Then any offered solution should have text to 
> show to what
> > > > >> > > > extent they
> > > > >> > > > >fulfill the
> > > > >> > > > >requirements, and what is their applicability and
> > > > >restrictions.
> > > > >> > > >
> > > > >> > > >          Sounds reasonable.
> > > > >> > > >
> > > > >> > > >          --Tom
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > --------------------------------------------------------------
> > > > >> > > > ----------
> > > > >> > > > Mathematics is the supreme nostalgia of our time.
> > > > >> > > >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > 
> --------------------------------------------------------------
> > > > >> > ----------
> > > > >> > Mathematics is the supreme nostalgia of our time.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >
> > > > >
> > > > >
> > > > >---------------------------------------------------------------
> > > > >---------
> > > > >Mathematics is the supreme nostalgia of our time.
> > > > >
> > > > >
> > >
> > >
> > >
> > > --------------------------------------------------------------
> > > ----------
> > > Mathematics is the supreme nostalgia of our time.
> > >
> > >
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 

Delivery-date: Tue, 05 Mar 2002 16:02:41 -0800
From: "Karmakar, Soumen" <[email-masked]>
To: [email-masked]
Subject: Adspec object in Path (GMPLS)
Date: Tue, 5 Mar 2002 16:02:17 -0800 

Hi All,
           Is the inclusion of AdSpec object allowed in GMPLS RSVP-TE Path
message for establishing the LSC/FSC/TDM LSP ? If yes then what is the usage
of this one ? 

Delivery-date: Tue, 05 Mar 2002 15:58:32 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: AdSpec Object in GMPLS
Date: Tue, 05 Mar 2002 11:43:27 -0700

[ post by non-subscriber ]

Hi All,
         Does GMPLS extensions to RSVP-TE support AdSpec Object ? If
yes then what is its usage in GMPLS ?

Regards,
manoj.

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Delivery-date: Tue, 05 Mar 2002 15:32:40 -0800
From: "Naidu, Venkata" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, [email-masked]
Subject: RE: Unnumbered support with ISIS - using exiting TLV
Date: Tue, 5 Mar 2002 18:31:57 -0500 

Yakov:

-> To support unnumbered links the current GMPLS ISIS routing spec
-> defines new TLV, Link Identifier, to be carried in ISIS Hellos. It
-> was pointed out that ISIS already has an existing mechanism to
-> exchange link identifiers - see draft-ietf-isis-3way-05.txt. So,
-> unless there are specific technical objections, I would suggest we
-> replace Link Identifier TLV with the mechanism described in
-> draft-ietf-isis-3way-05.txt

  AFAIK, ISIS 3-Way handshake is optional and It is fully
  interoperable with systems that do not support the extension.
  I think we are making a dependency here - ISIS Unnumbered extensions
 (for (G)MPLS-TE purpose and not for normal hop-by-hop routing)  
  will be supported only with 3-way handshake extensions. If that 
  is not a big problem, I completely agree with your proposal.

Venkata.

Delivery-date: Tue, 05 Mar 2002 15:14:22 -0800
From: Shahram Davari <[email-masked]>
To: "'Eric Gray'" <[email-masked]>
Cc: "'Ron Bonica'" <[email-masked]>, [email-masked], David Allan <[email-masked]>, "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Tue, 5 Mar 2002 15:13:52 -0800 

Eric,

I think it all depends on the meaning of requirement. Here
is the Webster dictionary meaning of requirements:

"something essential to the existence or occurrence of something else"

Based on this definition could you please explain why it is essential 
to have a solution that looks a certain way?

-Shahram

> -----Original Message-----
> From: Eric Gray [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 5:06 PM
> To: Shahram Davari
> Cc: 'Ron Bonica'; [email-masked]; David Allan; 'Thomas D. Nadeau';
> [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02
> 
> 
> Shahram,
> 
>     On the contrary, it is quite reasonable to propose scoping
> requirements such as "tab B it should fit into slot A" in any
> proposal for requirements that are intended ever to be filled.
> Resemblance to existing tools is a very good example of an
> appropriate scoping requirement proposal.  What I saw Ron
> commenting on was a similar scoping proposal which might
> not be as likely of success in this forum.
> 
> You wrote:
> 
> >Ron,
> >
> >>We should not be surprised that 
> >>the enhanced
> >>route tracing application resembles the current "traceroute" 
> >>in that a) it
> >>is based upon probes and responses, b) UDP carries its PDUs, 
> >>and c) it is
> >>stateless.
> >>
> >
> >I am not surprised at all. What you are suggesting is 
> >your desire to resemble the IP traceroute. But this is only
> >a desire and there is no technical reason why it should or it
> >should not resemble the IP traceroute. 
> >
> >A requirements document should leave the door open for other
> >innovative ideas, unless you can prove that the traceroute-like 
> >mechanism is the BEST.
> >
> >-Shahram  
> >
> 
> 
> 

Delivery-date: Tue, 05 Mar 2002 15:11:08 -0800
To: [email-masked]
Subject: Unnumbered support with ISIS - using exiting TLV
Date: Tue, 05 Mar 2002 15:10:04 -0800
From: Yakov Rekhter <[email-masked]>

Folks,

To support unnumbered links the current GMPLS ISIS routing spec
defines new TLV, Link Identifier, to be carried in ISIS Hellos. It
was pointed out that ISIS already has an existing mechanism to
exchange link identifiers - see draft-ietf-isis-3way-05.txt. So,
unless there are specific technical objections, I would suggest we
replace Link Identifier TLV with the mechanism described in
draft-ietf-isis-3way-05.txt

Yakov,

Delivery-date: Tue, 05 Mar 2002 14:45:00 -0800
Date: Tue, 05 Mar 2002 17:43:58 -0500
To: [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
Cc: [email-masked], [email-masked]

>Agreed Enrique.....I have asked Tom to point us to where similar
>requirements that he says he is working to (or more accurately, that he
>'hears') are defined.  You/I know they exist in Y.1710...since we agreed
>them with other operators.....but Tom may have additional ones.  I am sure
>we would like to see them now.
>BTW - I find it rather sad that operator defined requirements in ITU are
>somehow deemed worthless in IETF.....at least in Tom's view.

         Neil puts words in my mouth. I never said that the requirements
were worthless. I said that a) they are not defined here in the IETF, and we
need a set defined here that we can work to. I don't think that the IETF
works towards requirements defined elsewhere. I am also not
hearing the same Y.1710 requirements from all of the operators I am
working with.

         --Tom

>regards, Neil
>
> > -----Original Message-----
> > From: Cuevas, Enrique G, ALASO [mailto:[email-masked]]
> > Sent: 05 March 2002 17:48
> > To: Ping Pan
> > Cc: Thomas D. Nadeau; ccamp
> > Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> > Ping,
> > Here are some functions to consider. I am sure others can add
> > to this list.
> >
> > 1) We need a function that can detect defects automatically
> > and trigger corrective actions This function should also
> > support statically configured MPLS networks.
> > 2) We need a function to detect not only LSP breaks and
> > miss-routing but also defects such as LSP replication into
> > another LSP.
> > 3) We need a function to immediately suppress the user
> > traffic at the egress PE when an LSP is routed-routed.
> > 4) To support PWE3 applications, we need a function to
> > generate AIS for the tunneled circuits at the egress PE, when
> > a defect is detected in the MPLS network.
> > 5) We need a function to measure LSP performance accurately.
> > 6)
> >
> > Enrique
> > _______________
> > [email-masked]
> > Tel. (732)-420-3252
> >
> >
> > >-----Original Message-----
> > >From: Ping Pan [mailto:[email-masked]]
> > >Sent: Tuesday, March 05, 2002 10:15 AM
> > >To: Cuevas, Enrique G, ALASO
> > >Cc: Thomas D. Nadeau; [email-masked]
> > >Subject: Re: draft-bonica-tunneltrace-02
> > >
> > >
> > >The proposed stuff:
> > >  - a tool that can "ping" through a LSP,
> > >  - a tool that can do traceroute to a LSP
> > >  - a set of MIBs that can provide info on data traffic.
> > >
> > >They are not some projects dreamt by some bored developers. They are
> > >required by our customers. Now, as a person who works for a
> > provider,
> > >would you please forget about XUZ standard from XYZ
> > organization for a
> > >moment, :-) and tell us what other functionality that we
> > >should consider?
> > >
> > >Thank you!
> > >
> > >- Ping
> > >
> > >Cuevas, Enrique G, ALASO wrote:
> > >
> > >> Tom,
> > >> Could you provide us with a matrix (comply/does not comply)
> > >of the tools you are talking
> > >
> > >> about vs. the requirements given in Y.1710?
> > >>
> > >> Enrique
> > >
> > >
> >

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Tue, 05 Mar 2002 14:27:45 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Tue, 5 Mar 2002 22:26:41 -0000 

Thanks Ping.....nice to see a positive response from a specific manufacturer
to our concerns as operators on this.  This is a really good positive step
IMO. Its a shame other manufacturers have discounted Y.1710, as what Enrique
is saying here is simply a summary of some of the requirements stuff in
there.

regards, Neil 

> -----Original Message-----
> From: Ping Pan [mailto:[email-masked]]
> Sent: 05 March 2002 18:07
> To: Cuevas, Enrique G, ALASO
> Cc: Thomas D. Nadeau; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02
> 
> 
> Cuevas, Enrique G, ALASO wrote:
> 
> > Ping,
> > Here are some functions to consider. I am sure others can 
> add to this list.
> > 
> > 1) We need a function that can detect defects automatically 
> and trigger corrective actions.
> 
> 
> OK.
> 
> 
> > 2) We need a function to detect not only LSP breaks and 
> miss-routing but also defects such as 
> 
> > LSP replication into another LSP.
> 
> 
> OK. Good thinking...
> 
> 
> > 3) We need a function to immediately suppress the user 
> traffic at the egress PE when an LSP 
> 
> > is routed-routed. 
> 
> 
> Actually, this is up to the NOC operators.
> 
> 
> > 4) To support PWE3 applications, we need a function to 
> generate AIS for the tunneled circuits 
> 
> > at the egress PE, when a defect is detected in the MPLS network.
> 
> 
> In fact, the detection mechanism should go beyond 
> protocol-level (RSVP 
> and LDP) probing. All MPLS applications, such as 
> L2-VPN/L3-VPN, should 
> be able to check the connectivity of their circuits.
> 
> > 5) We need a function to measure LSP performance accurately.
> 
> 
> OK. 
> 
> 
> > 6)
> > 
> 
> 
> And, 6) We need more useful input like you have provided. :-)
> 
> Many thanks!
> 
> - Ping
> 
> 
> 

Delivery-date: Tue, 05 Mar 2002 14:27:42 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Tue, 5 Mar 2002 22:26:43 -0000 

> 
> I  understand that  you don't  think that  MPLS, viewed  as 
> an  IP tunneling
> protocol,  is worthwhile.
NH=> This sentence does not make sense Eric.  MPLS is a layer network (proof
by existence if you like), whether you would like it to be viewed as such or
not.  It may carry an IP client or it may not......that is irrelevant.  The
network object that we operators need to manage is the LSP.....inc those
instantiated without any control-plane assistance.  We are seeking
as-generic-as-possible a solution, whereas you appear to only a advocate a
restrictive solution.

   But that's  not the  question.  
> The  question is
> whether  a traceroute  tool that  works through  IP tunnels  
> (including MPLS
> tunnels)  is  worth  standardizing.
NH=> You argument does not compute Eric.  You are arguing for a generic tool
(any server technology) but that view clearly breaks once you consider
GMPLS....or more accurately SDH VCs or OTN trails.  GTTP does not compute
here as I hope you agree....however the *principles* of fault-managing the
data-plane trail do (any layer).....and it is these principles that are
truly generic, not the attempt to force some single mechanism across all
(technology) layers.
BTW - I know you find the concept of layered networks hard to swallow/accept
but I can't help you on that one.....you will just have to either accept it
or (we will all have to) live with the problem that you can't.

   This  question doesn't  
> seem  to  have
> anything to do  with CO networks.  Thus I don't  understand 
> why a discussion
> of  CO networking  is even  relevant to  the discussion  of  
> the tunneltrace
> requirements. 
NH=> This is an example of what I mean with us having to live your problem.
> 
> Dave> I  would  also  similarly  invert  the "saddled  with  
> CO  mechanisms"
> Dave> statement as it would appear that bringing some CO 
> properties to IP is
> Dave> what MPLS is all about. 
> 
> Certainly MPLS facilitates the bringing of some CO properties 
> to IP.
NH=> Is this a 1st step to realisation there is life outside the cnls world?

  One of
> the ideas of MPLS was to be  able to bring the (few) good 
> properties without
> also bringing the (much larger  number of) bad properties.
NH=> This smacks of .....'I know its true deep down, but boy does it hurt me
to admit it'.  As I pointed out to you in an earlier mail, our whole
industry is totally dependent on having a cct-sw/CO technology *somewhere*
below IP.......you can't connect IP transfer-mode boxes together without it
(and if I may add your company has done very well on this very principle!).
Why not just face it Eric?  MPLS can/does create new data-plane trail
entities....you may pretend this is not what they are, but we operators
still have to manage them on this basis (ie they have functions/behaviours
that are not based on IP...or any other layer network.....and as such
require their own mtce processes).
  
> Another idea was
> to do this  while using an IP  control plane.  So I hope  you 
> can understand
> why  "let's do  OAM  the way  it  is done  in CO  networks",  
> and "let's  do
> something that  doesn't require IP", is  an argument that  
> does not resonate
> very well with many of us.
NH=> I can understand this view from someone like yourself with an IETF hat
on....but to be honest it does not compute with GMPLS as I hope you can
honestly agree.  So where does one draw the cnls/co line?  I actually don't
think you need to draw any line *providing* we agree on the
principles.....it is these that are enduring (ie the set of 'network
problems' that are common to all cnls/co technologies), rather than trying
to bludgeon a '1-size-fits-all mechanism' through (when it clearly does
not).  I can also understand other views here.  When I discount the
regligion, these simple facts remaim for MPLS:
-	MPLS does create new layer networks.....has to by definition of new
OH/functionality.  I mean would LDP, CR-LDP or RSVT-TE for example exist in
an IP-only network?  Does IP issue labels?, etc  
-	MPLS can carry payloads other than IP......PWE3 is working on just
such behaviour.
-	MPLS LSPs can have failure modes that are not relevant to any client
layer or any server layer (nor should their 'behaviour' be dependent on any
control-plane or management-plane protocols in use at peer/client/server
layers).
We therefore need tools to manage the defect detection/handling of MPLS
failures that are generic and not a function of what appears above/below
MPLS, nor how the LSPs are instantiated.  This seems intuitively obvious to
me and other like-minded operators/manufacturers.   

Delivery-date: Tue, 05 Mar 2002 14:27:39 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Tue, 5 Mar 2002 22:26:40 -0000 

Agreed Enrique.....I have asked Tom to point us to where similar
requirements that he says he is working to (or more accurately, that he
'hears') are defined.  You/I know they exist in Y.1710...since we agreed
them with other operators.....but Tom may have additional ones.  I am sure
we would like to see them now.
BTW - I find it rather sad that operator defined requirements in ITU are
somehow deemed worthless in IETF.....at least in Tom's view.

regards, Neil

> -----Original Message-----
> From: Cuevas, Enrique G, ALASO [mailto:[email-masked]]
> Sent: 05 March 2002 17:48
> To: Ping Pan
> Cc: Thomas D. Nadeau; ccamp
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> Ping,
> Here are some functions to consider. I am sure others can add 
> to this list.
> 
> 1) We need a function that can detect defects automatically 
> and trigger corrective actions This function should also 
> support statically configured MPLS networks.
> 2) We need a function to detect not only LSP breaks and 
> miss-routing but also defects such as LSP replication into 
> another LSP.
> 3) We need a function to immediately suppress the user 
> traffic at the egress PE when an LSP is routed-routed. 
> 4) To support PWE3 applications, we need a function to 
> generate AIS for the tunneled circuits at the egress PE, when 
> a defect is detected in the MPLS network.
> 5) We need a function to measure LSP performance accurately.
> 6)
> 
> Enrique
> _______________
> [email-masked]
> Tel. (732)-420-3252
> 
> 
> >-----Original Message-----
> >From: Ping Pan [mailto:[email-masked]]
> >Sent: Tuesday, March 05, 2002 10:15 AM
> >To: Cuevas, Enrique G, ALASO
> >Cc: Thomas D. Nadeau; [email-masked]
> >Subject: Re: draft-bonica-tunneltrace-02
> >
> >
> >The proposed stuff:
> >  - a tool that can "ping" through a LSP,
> >  - a tool that can do traceroute to a LSP
> >  - a set of MIBs that can provide info on data traffic.
> >
> >They are not some projects dreamt by some bored developers. They are 
> >required by our customers. Now, as a person who works for a 
> provider, 
> >would you please forget about XUZ standard from XYZ 
> organization for a 
> >moment, :-) and tell us what other functionality that we 
> >should consider?
> >
> >Thank you!
> >
> >- Ping
> >
> >Cuevas, Enrique G, ALASO wrote:
> >
> >> Tom,
> >> Could you provide us with a matrix (comply/does not comply) 
> >of the tools you are talking 
> >
> >> about vs. the requirements given in Y.1710?
> >> 
> >> Enrique
> >
> >
> 

Delivery-date: Tue, 05 Mar 2002 14:06:32 -0800
Date: Tue, 05 Mar 2002 17:06:01 -0500
From: Eric Gray <[email-masked]>
To: Shahram Davari <[email-masked]>
Cc: 'Ron Bonica' <[email-masked]>, [email-masked], David Allan <[email-masked]>, "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

Shahram,

    On the contrary, it is quite reasonable to propose scoping
requirements such as "tab B it should fit into slot A" in any
proposal for requirements that are intended ever to be filled.
Resemblance to existing tools is a very good example of an
appropriate scoping requirement proposal.  What I saw Ron
commenting on was a similar scoping proposal which might
not be as likely of success in this forum.

You wrote:

>Ron,
>
>>We should not be surprised that 
>>the enhanced
>>route tracing application resembles the current "traceroute" 
>>in that a) it
>>is based upon probes and responses, b) UDP carries its PDUs, 
>>and c) it is
>>stateless.
>>
>
>I am not surprised at all. What you are suggesting is 
>your desire to resemble the IP traceroute. But this is only
>a desire and there is no technical reason why it should or it
>should not resemble the IP traceroute. 
>
>A requirements document should leave the door open for other
>innovative ideas, unless you can prove that the traceroute-like 
>mechanism is the BEST.
>
>-Shahram  
>

Delivery-date: Tue, 05 Mar 2002 14:06:28 -0800
Date: Tue, 05 Mar 2002 22:06:37 +0000
From: Giles Heron <[email-masked]>
Organization: PacketExchange Ltd.
To: David Allan <[email-masked]>
CC: [email-masked], Shahram Davari <[email-masked]>, "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]
Subject: Re: Well off the original thread topic... draft-bonica-tunneltrace-02

David Allan wrote:

> Hi Giles...long time no hear...;-)

yeah, I've been resisting the temptation join the melee.  Don't always 
succeed of course... ;-)

> Another thread I have my regrets about....comments in line...
> 
> <snip>
>  >
>  > Actually there are other things you can do with "just" LDP that you
>  > can't do with IP.
>  >
>  > 1)  draft-martini etc.  Sure, IP equivalents of this are now being
>  > defined (UTI^H^H^H L2TPv3 et al) but they aren't as widely available,
>  > and are much less efficient encapsulation-wise (as they require an IP
>  > header plus a tunnel header instead of a couple of labels).
> 
> If you're discussing:
> - i) using extended LDP adjacencies to hand out PW labels
> - ii) the relative effy. of MPLS labels vs. IP headers
> no argument, but that is somewhat orthogonal to the discussion of the 
> value that LDP-DU tied to routing may or may not provide.

In fact it is the use of LDP-DU (or RSVP-TE) to hand out the tunnel 
label that gives us efficiency wrt L2TPv3 et al (and also seems to give 
us the availability of code - few of the vendors support L2TPv3 or 
draft-martini over GRE at this point - though of course practical issues 
like availability of code should be kept out of IETF discussions...)

>  > 2)  MPLS VPN (RFC2547).  I won't go into the pros and cons of
>  > this right
>  > now ;-)
> 
> Current implementation is MPLS but I don't think there is a sustainable 
> dependency there...LDP permits the undelying MPLS network to behave like 
> an IP network. Seems to me they should be interchangable.

they are - the above issues notwithstanding.

>  > 3)  BGP free network core.  This may improve stability
>  > (though there's
>  > certainly a strong argument that BGP is less destabilising than LDP
>  > right now) and security (the core doesn't need to know how to
>  > get to the
>  > Internet.)  Also this allows you to layer multiple distinct
>  > IP backbones
>  > over one MPLS core.
> 
> Left that one out of my analysis, not sure how simple LDP helps here. I 
> thought you LSP meshed your BGP speakers (which would be explicit 
> routes) and eliminated IGP.

Yes, you LSP mesh the BGP speakers over LDP-DU tunnels using the IGP 
that is carried through the core.  So the core doesn't need to know 
about the BGP routes.

>  > > It is when I get into topology manipulation independent of dynamic IP
>  > > routing that MPLS starts to add value and to claim this is not
>  > > connection oriented use of MPLS forwarding IMHO smacks of the same
>  > > "tunnel"/"layer" semantic debate that can also be said to
>  > waste much time.
>  >
>  > this is your view.  And it is certainly one view.  But it isn't
>  > necessarily the only valid view ;-)
> 
> The "topology manipulation" part or the "terminology part" ? ;-)

the "starts to add value" part - I think :)

Giles

> later
> Dave
>  
>  
> 

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

Delivery-date: Tue, 05 Mar 2002 13:12:34 -0800
From: "David Allan"<[email-masked]>
To: Giles Heron <[email-masked]>
Cc: [email-masked], Shahram Davari <[email-masked]>, "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]
Subject: Well off the original thread topic... draft-bonica-tunneltrace-02
Date: Tue, 5 Mar 2002 16:11:35 -0500 

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

------_=_NextPart_001_01C1C48A.55035FE0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Giles...long time no hear...;-)

Another thread I have my regrets about....comments in line...

<snip>
> 
> Actually there are other things you can do with "just" LDP that you 
> can't do with IP.
> 
> 1)  draft-martini etc.  Sure, IP equivalents of this are now being 
> defined (UTI^H^H^H L2TPv3 et al) but they aren't as widely available, 
> and are much less efficient encapsulation-wise (as they require an IP 
> header plus a tunnel header instead of a couple of labels).

If you're discussing:
- i) using extended LDP adjacencies to hand out PW labels
- ii) the relative effy. of MPLS labels vs. IP headers
no argument, but that is somewhat orthogonal to the discussion of the value
that LDP-DU tied to routing may or may not provide.

> 
> 2)  MPLS VPN (RFC2547).  I won't go into the pros and cons of 
> this right 
> now ;-)

Current implementation is MPLS but I don't think there is a sustainable
dependency there...LDP permits the undelying MPLS network to behave like an
IP network. Seems to me they should be interchangable.

> 3)  BGP free network core.  This may improve stability 
> (though there's 
> certainly a strong argument that BGP is less destabilising than LDP 
> right now) and security (the core doesn't need to know how to 
> get to the 
> Internet.)  Also this allows you to layer multiple distinct 
> IP backbones 
> over one MPLS core.

Left that one out of my analysis, not sure how simple LDP helps here. I
thought you LSP meshed your BGP speakers (which would be explicit routes)
and eliminated IGP.

> > It is when I get into topology manipulation independent of dynamic IP 
> > routing that MPLS starts to add value and to claim this is not 
> > connection oriented use of MPLS forwarding IMHO smacks of the same 
> > "tunnel"/"layer" semantic debate that can also be said to 
> waste much time.
> 
> this is your view.  And it is certainly one view.  But it isn't 
> necessarily the only valid view ;-)

The "topology manipulation" part or the "terminology part" ? ;-)

later
Dave

------_=_NextPart_001_01C1C48A.55035FE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>Well off the original thread topic... =
draft-bonica-tunneltrace-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Giles...long time no hear...;-)</FONT>
</P>

<P><FONT SIZE=3D2>Another thread I have my regrets about....comments in =
line...</FONT>
</P>

<P><FONT SIZE=3D2>&lt;snip&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Actually there are other things you can do with =
&quot;just&quot; LDP that you </FONT>
<BR><FONT SIZE=3D2>&gt; can't do with IP.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1)&nbsp; draft-martini etc.&nbsp; Sure, IP =
equivalents of this are now being </FONT>
<BR><FONT SIZE=3D2>&gt; defined (UTI^H^H^H L2TPv3 et al) but they =
aren't as widely available, </FONT>
<BR><FONT SIZE=3D2>&gt; and are much less efficient encapsulation-wise =
(as they require an IP </FONT>
<BR><FONT SIZE=3D2>&gt; header plus a tunnel header instead of a couple =
of labels).</FONT>
</P>

<P><FONT SIZE=3D2>If you're discussing:</FONT>
<BR><FONT SIZE=3D2>- i) using extended LDP adjacencies to hand out PW =
labels</FONT>
<BR><FONT SIZE=3D2>- ii) the relative effy. of MPLS labels vs. IP =
headers</FONT>
<BR><FONT SIZE=3D2>no argument, but that is somewhat orthogonal to the =
discussion of the value that LDP-DU tied to routing may or may not =
provide.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2)&nbsp; MPLS VPN (RFC2547).&nbsp; I won't go =
into the pros and cons of </FONT>
<BR><FONT SIZE=3D2>&gt; this right </FONT>
<BR><FONT SIZE=3D2>&gt; now ;-)</FONT>
</P>

<P><FONT SIZE=3D2>Current implementation is MPLS but I don't think =
there is a sustainable dependency there...LDP permits the undelying =
MPLS network to behave like an IP network. Seems to me they should be =
interchangable.</FONT></P>

<P><FONT SIZE=3D2>&gt; 3)&nbsp; BGP free network core.&nbsp; This may =
improve stability </FONT>
<BR><FONT SIZE=3D2>&gt; (though there's </FONT>
<BR><FONT SIZE=3D2>&gt; certainly a strong argument that BGP is less =
destabilising than LDP </FONT>
<BR><FONT SIZE=3D2>&gt; right now) and security (the core doesn't need =
to know how to </FONT>
<BR><FONT SIZE=3D2>&gt; get to the </FONT>
<BR><FONT SIZE=3D2>&gt; Internet.)&nbsp; Also this allows you to layer =
multiple distinct </FONT>
<BR><FONT SIZE=3D2>&gt; IP backbones </FONT>
<BR><FONT SIZE=3D2>&gt; over one MPLS core.</FONT>
</P>

<P><FONT SIZE=3D2>Left that one out of my analysis, not sure how simple =
LDP helps here. I thought you LSP meshed your BGP speakers (which would =
be explicit routes) and eliminated IGP.</FONT></P>

<P><FONT SIZE=3D2>&gt; &gt; It is when I get into topology manipulation =
independent of dynamic IP </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; routing that MPLS starts to add value and =
to claim this is not </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; connection oriented use of MPLS forwarding =
IMHO smacks of the same </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;tunnel&quot;/&quot;layer&quot; =
semantic debate that can also be said to </FONT>
<BR><FONT SIZE=3D2>&gt; waste much time.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; this is your view.&nbsp; And it is certainly =
one view.&nbsp; But it isn't </FONT>
<BR><FONT SIZE=3D2>&gt; necessarily the only valid view ;-)</FONT>
</P>

<P><FONT SIZE=3D2>The &quot;topology manipulation&quot; part or the =
&quot;terminology part&quot; ? ;-)</FONT>
</P>

<P><FONT SIZE=3D2>later</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C48A.55035FE0--

Delivery-date: Tue, 05 Mar 2002 12:57:16 -0800
Date: Tue, 05 Mar 2002 15:55:32 -0500
To: Shahram Davari <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
Cc: "'Ron Bonica'" <[email-masked]>, [email-masked], David Allan <[email-masked]>, [email-masked]

At 12:25 PM 3/5/2002 -0800, Shahram Davari wrote:
>Ron,
>
> > We should not be surprised that
> > the enhanced
> > route tracing application resembles the current "traceroute"
> > in that a) it
> > is based upon probes and responses, b) UDP carries its PDUs,
> > and c) it is
> > stateless.
> >
>
>I am not surprised at all. What you are suggesting is
>your desire to resemble the IP traceroute. But this is only
>a desire and there is no technical reason why it should or it
>should not resemble the IP traceroute.

         Sure there is; IP traceroute works.  This is one of the best reasons
in my mind.

         --Tom

>A requirements document should leave the door open for other
>innovative ideas, unless you can prove that the traceroute-like
>mechanism is the BEST.
>
>-Shahram

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Tue, 05 Mar 2002 12:26:31 -0800
From: Shahram Davari <[email-masked]>
To: "'Ron Bonica'" <[email-masked]>, [email-masked], David Allan <[email-masked]>
Cc: "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Tue, 5 Mar 2002 12:25:44 -0800 

Ron,

> We should not be surprised that 
> the enhanced
> route tracing application resembles the current "traceroute" 
> in that a) it
> is based upon probes and responses, b) UDP carries its PDUs, 
> and c) it is
> stateless.
> 

I am not surprised at all. What you are suggesting is 
your desire to resemble the IP traceroute. But this is only
a desire and there is no technical reason why it should or it
should not resemble the IP traceroute. 

A requirements document should leave the door open for other
innovative ideas, unless you can prove that the traceroute-like 
mechanism is the BEST.

-Shahram  

Delivery-date: Tue, 05 Mar 2002 12:13:53 -0800
Date: Tue, 05 Mar 2002 15:06:23 -0500
From: Ron Bonica <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
To: [email-masked], David Allan <[email-masked]>
Cc: Shahram Davari <[email-masked]>, "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]

Folks,

Eric has hit the nail on the head. The enhanced route-tracing application
described in draft-bonica is an IP debugging tool. Specifically, it traces
the path between any two points in an IP network. If one or more IP tunnels
(e.g., MPLS) support the traced path, the application can reveal tunnel
details.

The tool is admittedly IP-centric. It assumes the ubiquity of IP, but does
not assume that any particular tunneling technology has been deployed. This
is a safe assumption for those of us who will use the tool to maintain IP
networks.

Given this starting point, the protocol requirements enumerated by the draft
are a logical consequence. We should not be surprised that the enhanced
route tracing application resembles the current "traceroute" in that a) it
is based upon probes and responses, b) UDP carries its PDUs, and c) it is
stateless.

                                                         Ron
                                                   (speaking as individual
contributor)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Eric Rosen
> Sent: Tuesday, March 05, 2002 1:32 PM
> To: David Allan
> Cc: Shahram Davari; 'Thomas D. Nadeau'; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02
>
>
>
> I  understand that  you don't  think that  MPLS, viewed  as an
> IP tunneling
> protocol,  is worthwhile.   But that's  not the  question.  The
> question is
> whether  a traceroute  tool that  works through  IP tunnels
> (including MPLS
> tunnels)  is  worth  standardizing.   This  question doesn't
> seem  to  have
> anything to do  with CO networks.  Thus I don't  understand why a
> discussion
> of  CO networking  is even  relevant to  the discussion  of  the
> tunneltrace
> requirements.
>
>

Delivery-date: Tue, 05 Mar 2002 11:43:13 -0800
Date: Tue, 05 Mar 2002 14:42:17 -0500
To: <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02 
Cc: [email-masked]

>Tom...I suspect Enrique is saying this because that is the only place he is
>aware that they are written down and, since this is from the ITU, by
>definition must have operator agreement.  Can you please provide us with a
>reference to the requirements documents that you are working to?

         My requirements come from my customers' operational departments.

         --Tom

>thanks & regards, Neil
>
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:[email-masked]]
> > Sent: 05 March 2002 17:01
> > To: Cuevas, Enrique G, ALASO
> > Cc: David Allan; Shahram Davari; ccamp
> > Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> >
> >          Why are we still discussing Y.1710? I thought that this
> > was the IETF. The following seem to comply with the operational
> > OAM requirements I am hearing from operators.
> >
> >           LSP "ping",
> >           LSP Traceroute
> >           MIBs
> >
> >          Others may be required.
> >
> >          --Tom
> >
> >
> > >Could you provide us with a matrix (comply/does not comply)
> > of the tools
> > >you are
> > >talking about vs. the requirements given in Y.1710?
> > >
> > >Enrique
> > >_______________
> > >[email-masked]
> > >Tel. (732)-420-3252
> > >
> > >
> > > >-----Original Message-----
> > > >From: Thomas D. Nadeau [mailto:[email-masked]]
> > > >Sent: Tuesday, March 05, 2002 9:07 AM
> > > >To: David Allan
> > > >Cc: Shahram Davari; [email-masked]
> > > >Subject: RE: draft-bonica-tunneltrace-02
> > > >
> > > >
> > > >
> > > >
> > > >>Your statement that requirements support the tools/mechanisms
> > > >that work
> > > >>today is the nib of my concern. Basically the requirments step is
> > > >>redundant at that point. We are now in a tight embrace where the
> > > >>requirements justify the solution and the solution dictates the
> > > >>requirements. Suggesting the requirements is a WG work item
> > > >would appear
> > > >>to be an oxymoron.
> > > >
> > > >         As I mentioned, some of the tools have already been worked
> > > >out, so yes, the cart is before the horse in some cases. However,
> > > >I don't think that this is necessarily a problem.
> > > >
> > > >         --Tom
> > > >
> > > >
> > > >
> > > >>Dave
> > > >>
> > > >> > -----Original Message-----
> > > >> > From: Thomas D. Nadeau
> > > >> [<mailto:[email-masked]>mailto:[email-masked]]
> > > >> > Sent: Monday, March 04, 2002 5:47 PM
> > > >> > To: Shahram Davari
> > > >> > Cc: [email-masked]
> > > >> > Subject: RE: draft-bonica-tunneltrace-02
> > > >> >
> > > >> >
> > > >> >
> > > >> > >Thanks for your positive response. With regards to the
> > > >> > protocol requirements,
> > > >> > >which ones do you think MUST be there and why?
> > > >> >
> > > >> >          I think that the protocol requirements for those
> > > >> > solutions that
> > > >> > currently
> > > >> > exist should be in there.  I understand your point about
> > > >> > reverse engineering the tools, but unfortunately the
> > > >> > requirement writing effort
> > > >> > started after we had some solutions working. Therefore
> > > >> > protocol requirements
> > > >> > do matter because they support the tools/mechanisms that work
> > > >> > today. No
> > > >> > need to obviate those things at this point.
> > > >> >
> > > >> > >In my view protocol requirements should not unnecessarily
> > > >> > restrict the
> > > >> > >solution,
> > > >> > >unless they violate application requirements.
> > > >> >
> > > >> >          I think that protocol requirements should be in line
> > > >> > with the
> > > >> > application
> > > >> > requirements that have come from operational folks working at
> > > >> > SPs.  However,
> > > >> > application requirements should fit within existing protocols
> > > >> > as much as
> > > >> > possible (to promote reuse of existing software/tools).
> > > >We should not
> > > >> > be forced to reinvent the wheel just for the sake of doing so.
> > > >> >
> > > >> >          --Tom
> > > >> >
> > > >> >
> > > >> >
> > > >> > >-Shahram
> > > >> > >
> > > >> > > > -----Original Message-----
> > > >> > > > From: Thomas D. Nadeau
> > > >> [<mailto:[email-masked]>mailto:[email-masked]]
> > > >> > > > Sent: Monday, March 04, 2002 4:25 PM
> > > >> > > > To: Shahram Davari
> > > >> > > > Cc: [email-masked]
> > > >> > > > Subject: RE: draft-bonica-tunneltrace-02
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > >I think instead of debating whether Y.1711 is better than
> > > >> > > > LSP-ping/GTTP or
> > > >> > > > >vice versa, it would be more
> > > >> > > > >constructive to identify and document the applicability of
> > > >> > > > each proposal
> > > >> > > > >for various tunneling applications.
> > > >> > > >
> > > >> > > >          This sounds like a move in the right direction.
> > > >> > > >
> > > >> > > > >For this particular draft my suggestion at this stage is
> > > >> > > > that the Bonica's
> > > >> > > > >requirement draft be revised to:
> > > >> > > > >
> > > >> > > > >1) Add text (or at least a place holder) for additional
> > > >> > > > security issues
> > > >> > > > >raised on the list.
> > > >> > > > >2) Add backward compatibility, simplicity and
> > scalability as
> > > >> > > > requirements.
> > > >> > > >
> > > >> > > >          I can go along with those.
> > > >> > > >
> > > >> > > > >3) Remove the protocol requirements section, since any
> > > >> > > > requirement here
> > > >> > > > >will be viewed as a reverse engineering of some solution.
> > > >> > > >
> > > >> > > >          Although this might sound reasonable to some, I
> > > >> > > > think that some
> > > >> > > > may object to this
> > > >> > > > since the protocol requirements are viewed by some as
> > > >> > > > fundamental to the
> > > >> > > > requirements
> > > >> > > > of any particular solution.  In the flurry of emails on the
> > > >> > > > topic, I have
> > > >> > > > not been able to
> > > >> > > > keep track of what the consensus on this might be (either
> > > >> > > > way). Perhaps Ron
> > > >> > > > has been keeping
> > > >> > > > track?
> > > >> > > >
> > > >> > > > >Then any offered solution should have text to show to what
> > > >> > > > extent they
> > > >> > > > >fulfill the
> > > >> > > > >requirements, and what is their applicability and
> > > >restrictions.
> > > >> > > >
> > > >> > > >          Sounds reasonable.
> > > >> > > >
> > > >> > > >          --Tom
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > --------------------------------------------------------------
> > > >> > > > ----------
> > > >> > > > Mathematics is the supreme nostalgia of our time.
> > > >> > > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --------------------------------------------------------------
> > > >> > ----------
> > > >> > Mathematics is the supreme nostalgia of our time.
> > > >> >
> > > >> >
> > > >> >
> > > >
> > > >
> > > >
> > > >---------------------------------------------------------------
> > > >---------
> > > >Mathematics is the supreme nostalgia of our time.
> > > >
> > > >
> >
> >
> >
> > --------------------------------------------------------------
> > ----------
> > Mathematics is the supreme nostalgia of our time.
> >
> >

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Tue, 05 Mar 2002 11:40:26 -0800
From: John Drake <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Tue, 5 Mar 2002 11:39:52 -0800 

Neil,

As a related question, would you please explain how your OAM proposal fits
against GMPLS?

Thanks,

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 05, 2002 11:32 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 

Eric...can you please explain how GMPLS fits against this statement please?

regards, Neil

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: 05 March 2002 14:52
> To: Shahram Davari
> Cc: 'Thomas D. Nadeau'; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02 
> 
> 
> 
> Shahram> What is  the difference between ATM,  FR, or any  CO 
> technology and
> Shahram> MPLS 
> 
> Well, for  one thing, MPLS  isn't a CO  technology.  It's got 
> lots  of stuff
> that doesn't really  make sense from a CO perspective.   Of 
> course, when the
> CO  guys  run  across  these  features  (multipoint-to-point, 
>  php,  liberal
> retention, independent  mode, equal  cost load balancing,  
> dynamic rerouting
> with no signaling,  ttl, lack of packet sequencing,  IP 
> control plane, etc.,
> etc.) they assume that those features are there by mistake!
> 
> This misconception  that MPLS  is a CO  technology, shared  
> as it is  by the
> "pure  IP" crowd and  by the  ITU/ATM crowd,  is the  source 
> of  much wasted
> time.  
> 
> MPLS is  actually an IP-derived technology that  facilitates 
> the application
> of  certain   circuit-like  characteristics  to  IP  
> networks.    As  an  IP
> technology,  the usual  IP diagnostic  tools, such  as ping  
> and traceroute,
> should be applicable.   That's what this whole useless  
> discussion is about.
> One  the one  side are  people  who think  that IP  networks 
> are  inherently
> unmanageable (after all, they don't  follow ITU standards), 
> and on the other
> side are people who think that the IP-based paradigms are the best. 
> 
> It is true that  MPLS can be used to provide something  which 
> is very like a
> CO network,  but it  doesn't have to  be used  this way, and  
> usually isn't.
> Those of use  who are not particularly interested in  CO 
> networks just don't
> want to be saddled with the  legacy CO mechanisms.  
> Presumably, if all these
> legacy CO mechanisms were  so great there would not be such  
> a great rush to
> IP. 
> 
> 
> 
> 
> 

Delivery-date: Tue, 05 Mar 2002 11:33:12 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Tue, 5 Mar 2002 19:32:21 -0000 

Tom...I suspect Enrique is saying this because that is the only place he is
aware that they are written down and, since this is from the ITU, by
definition must have operator agreement.  Can you please provide us with a
reference to the requirements documents that you are working to?

thanks & regards, Neil

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: 05 March 2002 17:01
> To: Cuevas, Enrique G, ALASO
> Cc: David Allan; Shahram Davari; ccamp
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> 
>          Why are we still discussing Y.1710? I thought that this
> was the IETF. The following seem to comply with the operational
> OAM requirements I am hearing from operators.
> 
>           LSP "ping",
>           LSP Traceroute
>           MIBs
> 
>          Others may be required.
> 
>          --Tom
> 
> 
> >Could you provide us with a matrix (comply/does not comply) 
> of the tools 
> >you are
> >talking about vs. the requirements given in Y.1710?
> >
> >Enrique
> >_______________
> >[email-masked]
> >Tel. (732)-420-3252
> >
> >
> > >-----Original Message-----
> > >From: Thomas D. Nadeau [mailto:[email-masked]]
> > >Sent: Tuesday, March 05, 2002 9:07 AM
> > >To: David Allan
> > >Cc: Shahram Davari; [email-masked]
> > >Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > >
> > >
> > >>Your statement that requirements support the tools/mechanisms
> > >that work
> > >>today is the nib of my concern. Basically the requirments step is
> > >>redundant at that point. We are now in a tight embrace where the
> > >>requirements justify the solution and the solution dictates the
> > >>requirements. Suggesting the requirements is a WG work item
> > >would appear
> > >>to be an oxymoron.
> > >
> > >         As I mentioned, some of the tools have already been worked
> > >out, so yes, the cart is before the horse in some cases. However,
> > >I don't think that this is necessarily a problem.
> > >
> > >         --Tom
> > >
> > >
> > >
> > >>Dave
> > >>
> > >> > -----Original Message-----
> > >> > From: Thomas D. Nadeau
> > >> [<mailto:[email-masked]>mailto:[email-masked]]
> > >> > Sent: Monday, March 04, 2002 5:47 PM
> > >> > To: Shahram Davari
> > >> > Cc: [email-masked]
> > >> > Subject: RE: draft-bonica-tunneltrace-02
> > >> >
> > >> >
> > >> >
> > >> > >Thanks for your positive response. With regards to the
> > >> > protocol requirements,
> > >> > >which ones do you think MUST be there and why?
> > >> >
> > >> >          I think that the protocol requirements for those
> > >> > solutions that
> > >> > currently
> > >> > exist should be in there.  I understand your point about
> > >> > reverse engineering the tools, but unfortunately the
> > >> > requirement writing effort
> > >> > started after we had some solutions working. Therefore
> > >> > protocol requirements
> > >> > do matter because they support the tools/mechanisms that work
> > >> > today. No
> > >> > need to obviate those things at this point.
> > >> >
> > >> > >In my view protocol requirements should not unnecessarily
> > >> > restrict the
> > >> > >solution,
> > >> > >unless they violate application requirements.
> > >> >
> > >> >          I think that protocol requirements should be in line
> > >> > with the
> > >> > application
> > >> > requirements that have come from operational folks working at
> > >> > SPs.  However,
> > >> > application requirements should fit within existing protocols
> > >> > as much as
> > >> > possible (to promote reuse of existing software/tools).
> > >We should not
> > >> > be forced to reinvent the wheel just for the sake of doing so.
> > >> >
> > >> >          --Tom
> > >> >
> > >> >
> > >> >
> > >> > >-Shahram
> > >> > >
> > >> > > > -----Original Message-----
> > >> > > > From: Thomas D. Nadeau
> > >> [<mailto:[email-masked]>mailto:[email-masked]]
> > >> > > > Sent: Monday, March 04, 2002 4:25 PM
> > >> > > > To: Shahram Davari
> > >> > > > Cc: [email-masked]
> > >> > > > Subject: RE: draft-bonica-tunneltrace-02
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > >I think instead of debating whether Y.1711 is better than
> > >> > > > LSP-ping/GTTP or
> > >> > > > >vice versa, it would be more
> > >> > > > >constructive to identify and document the applicability of
> > >> > > > each proposal
> > >> > > > >for various tunneling applications.
> > >> > > >
> > >> > > >          This sounds like a move in the right direction.
> > >> > > >
> > >> > > > >For this particular draft my suggestion at this stage is
> > >> > > > that the Bonica's
> > >> > > > >requirement draft be revised to:
> > >> > > > >
> > >> > > > >1) Add text (or at least a place holder) for additional
> > >> > > > security issues
> > >> > > > >raised on the list.
> > >> > > > >2) Add backward compatibility, simplicity and 
> scalability as
> > >> > > > requirements.
> > >> > > >
> > >> > > >          I can go along with those.
> > >> > > >
> > >> > > > >3) Remove the protocol requirements section, since any
> > >> > > > requirement here
> > >> > > > >will be viewed as a reverse engineering of some solution.
> > >> > > >
> > >> > > >          Although this might sound reasonable to some, I
> > >> > > > think that some
> > >> > > > may object to this
> > >> > > > since the protocol requirements are viewed by some as
> > >> > > > fundamental to the
> > >> > > > requirements
> > >> > > > of any particular solution.  In the flurry of emails on the
> > >> > > > topic, I have
> > >> > > > not been able to
> > >> > > > keep track of what the consensus on this might be (either
> > >> > > > way). Perhaps Ron
> > >> > > > has been keeping
> > >> > > > track?
> > >> > > >
> > >> > > > >Then any offered solution should have text to show to what
> > >> > > > extent they
> > >> > > > >fulfill the
> > >> > > > >requirements, and what is their applicability and
> > >restrictions.
> > >> > > >
> > >> > > >          Sounds reasonable.
> > >> > > >
> > >> > > >          --Tom
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > 
> --------------------------------------------------------------
> > >> > > > ----------
> > >> > > > Mathematics is the supreme nostalgia of our time.
> > >> > > >
> > >> >
> > >> >
> > >> >
> > >> > --------------------------------------------------------------
> > >> > ----------
> > >> > Mathematics is the supreme nostalgia of our time.
> > >> >
> > >> >
> > >> >
> > >
> > >
> > >
> > >---------------------------------------------------------------
> > >---------
> > >Mathematics is the supreme nostalgia of our time.
> > >
> > >
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 
> 

Delivery-date: Tue, 05 Mar 2002 11:33:09 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Tue, 5 Mar 2002 19:32:22 -0000 

Eric...can you please explain how GMPLS fits against this statement please?

regards, Neil

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: 05 March 2002 14:52
> To: Shahram Davari
> Cc: 'Thomas D. Nadeau'; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02 
> 
> 
> 
> Shahram> What is  the difference between ATM,  FR, or any  CO 
> technology and
> Shahram> MPLS 
> 
> Well, for  one thing, MPLS  isn't a CO  technology.  It's got 
> lots  of stuff
> that doesn't really  make sense from a CO perspective.   Of 
> course, when the
> CO  guys  run  across  these  features  (multipoint-to-point, 
>  php,  liberal
> retention, independent  mode, equal  cost load balancing,  
> dynamic rerouting
> with no signaling,  ttl, lack of packet sequencing,  IP 
> control plane, etc.,
> etc.) they assume that those features are there by mistake!
> 
> This misconception  that MPLS  is a CO  technology, shared  
> as it is  by the
> "pure  IP" crowd and  by the  ITU/ATM crowd,  is the  source 
> of  much wasted
> time.  
> 
> MPLS is  actually an IP-derived technology that  facilitates 
> the application
> of  certain   circuit-like  characteristics  to  IP  
> networks.    As  an  IP
> technology,  the usual  IP diagnostic  tools, such  as ping  
> and traceroute,
> should be applicable.   That's what this whole useless  
> discussion is about.
> One  the one  side are  people  who think  that IP  networks 
> are  inherently
> unmanageable (after all, they don't  follow ITU standards), 
> and on the other
> side are people who think that the IP-based paradigms are the best. 
> 
> It is true that  MPLS can be used to provide something  which 
> is very like a
> CO network,  but it  doesn't have to  be used  this way, and  
> usually isn't.
> Those of use  who are not particularly interested in  CO 
> networks just don't
> want to be saddled with the  legacy CO mechanisms.  
> Presumably, if all these
> legacy CO mechanisms were  so great there would not be such  
> a great rush to
> IP. 
> 
> 
> 
> 
> 

Delivery-date: Tue, 05 Mar 2002 11:08:37 -0800
From: Shahram Davari <[email-masked]>
To: "'Ping Pan'" <[email-masked]>
Cc: "Cuevas, Enrique G, ALASO" <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Tue, 5 Mar 2002 11:07:19 -0800 

Ping

> 
> Again, what to do with user traffic is up to the operators.

I agree

>We, at best, provide some knobs to the operators.

I think this was the essence of Enrique's requested function.

> I am suggesting to have the flexibility to probe anything that the 
> operators want. That includes the applications they use 
> today, and the 
> applications that they may use in the future (yes, we update 
> our tools 
> whenever new application becomes available). Many may think this is a 
> moving target. So what? Our job is to make the operator's 
> life easier, 
> which in turn making their customer happy.

Could you please provide an example in the context of ATM over MPLS,
and how you intend to generate ATM AIS.

-Shahram

Delivery-date: Tue, 05 Mar 2002 10:53:18 -0800
Date: Tue, 05 Mar 2002 10:52:22 -0800
From: Ping Pan <[email-masked]>
To: Shahram Davari <[email-masked]>
CC: "Cuevas, Enrique G, ALASO" <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

Shahram Davari wrote:

> Ping,
> 
>>
>>Actually, this is up to the NOC operators.
>>
>>
> 
> The decision to suppress the traffic or not is up to the operator. But what tool is available to them in order to suppress 

> the traffic when a misrouting defect is detected?
> 

Again, what to do with user traffic is up to the operators. We, at best, 
provide some knobs to the operators. If the tools are available yet, 
they will be soon.

> 
>>>4) To support PWE3 applications, we need a function to 
>>>
>>generate AIS for the tunneled circuits 
>>
>>
>>>at the egress PE, when a defect is detected in the MPLS network.
>>>
>>
>>In fact, the detection mechanism should go beyond 
>>protocol-level (RSVP 
>>and LDP) probing. All MPLS applications, such as 
>>L2-VPN/L3-VPN, should 
>>be able to check the connectivity of their circuits.
>>
> 
> If I understand correctly, you are suggesting that connectivity check
> should be done at the circuit level not tunnel level. 
> 

I am suggesting to have the flexibility to probe anything that the 
operators want. That includes the applications they use today, and the 
applications that they may use in the future (yes, we update our tools 
whenever new application becomes available). Many may think this is a 
moving target. So what? Our job is to make the operator's life easier, 
which in turn making their customer happy.

- Ping

Delivery-date: Tue, 05 Mar 2002 10:36:54 -0800
From: Shahram Davari <[email-masked]>
To: "'Ping Pan'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>
Cc: "Thomas D. Nadeau" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Tue, 5 Mar 2002 10:36:35 -0800 

Ping,

> 
> > 3) We need a function to immediately suppress the user 
> traffic at the egress PE when an LSP 
> 
> > is routed-routed. 
> 
> 
> Actually, this is up to the NOC operators.
> 

The decision to suppress the traffic or not is up to the operator. But what tool is available to them in order to suppress the traffic when a misrouting defect is detected?

> 
> > 4) To support PWE3 applications, we need a function to 
> generate AIS for the tunneled circuits 
> 
> > at the egress PE, when a defect is detected in the MPLS network.
> 
> 
> In fact, the detection mechanism should go beyond 
> protocol-level (RSVP 
> and LDP) probing. All MPLS applications, such as 
> L2-VPN/L3-VPN, should 
> be able to check the connectivity of their circuits.

If I understand correctly, you are suggesting that connectivity check
should be done at the circuit level not tunnel level. 

Off course each tunneled circuit should have its own method of connectivity
check. But if you don't translate a connectivity loss in the tunnel level to those circuits , then an alarm storm will happen at the terminating point of those circuits, which could cause mass confusion.

-Shahram

Delivery-date: Tue, 05 Mar 2002 10:32:06 -0800
To: "David Allan" <[email-masked]>
cc: Shahram Davari <[email-masked]>, "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02 
Reply-To: [email-masked]
Date: Tue, 05 Mar 2002 13:31:35 -0500
From: Eric Rosen <[email-masked]>

I  understand that  you don't  think that  MPLS, viewed  as an  IP tunneling
protocol,  is worthwhile.   But that's  not the  question.  The  question is
whether  a traceroute  tool that  works through  IP tunnels  (including MPLS
tunnels)  is  worth  standardizing.   This  question doesn't  seem  to  have
anything to do  with CO networks.  Thus I don't  understand why a discussion
of  CO networking  is even  relevant to  the discussion  of  the tunneltrace
requirements. 

Dave> I  would  also  similarly  invert  the "saddled  with  CO  mechanisms"
Dave> statement as it would appear that bringing some CO properties to IP is
Dave> what MPLS is all about. 

Certainly MPLS facilitates the bringing of some CO properties to IP.  One of
the ideas of MPLS was to be  able to bring the (few) good properties without
also bringing the (much larger  number of) bad properties.  Another idea was
to do this  while using an IP  control plane.  So I hope  you can understand
why  "let's do  OAM  the way  it  is done  in CO  networks",  and "let's  do
something that  doesn't require IP", is  an argument that  does not resonate
very well with many of us.

Delivery-date: Tue, 05 Mar 2002 10:06:28 -0800
Date: Tue, 05 Mar 2002 10:07:10 -0800
From: Ping Pan <[email-masked]>
To: "Cuevas, Enrique G, ALASO" <[email-masked]>
CC: "Thomas D. Nadeau" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

Cuevas, Enrique G, ALASO wrote:

> Ping,
> Here are some functions to consider. I am sure others can add to this list.
> 
> 1) We need a function that can detect defects automatically and trigger corrective actions.

OK.

> 2) We need a function to detect not only LSP breaks and miss-routing but also defects such as 

> LSP replication into another LSP.

OK. Good thinking...

> 3) We need a function to immediately suppress the user traffic at the egress PE when an LSP 

> is routed-routed. 

Actually, this is up to the NOC operators.

> 4) To support PWE3 applications, we need a function to generate AIS for the tunneled circuits 

> at the egress PE, when a defect is detected in the MPLS network.

In fact, the detection mechanism should go beyond protocol-level (RSVP 
and LDP) probing. All MPLS applications, such as L2-VPN/L3-VPN, should 
be able to check the connectivity of their circuits.

> 5) We need a function to measure LSP performance accurately.

OK. 

> 6)
> 

And, 6) We need more useful input like you have provided. :-)

Many thanks!

- Ping

Delivery-date: Tue, 05 Mar 2002 09:49:35 -0800
content-class: urn:content-classes:message
Subject: RE: draft-bonica-tunneltrace-02
Date: Tue, 5 Mar 2002 12:47:45 -0500
From: "Cuevas, Enrique G, ALASO" <[email-masked]>
To: "Ping Pan" <[email-masked]>
Cc: "Thomas D. Nadeau" <[email-masked]>, <[email-masked]>

Ping,
Here are some functions to consider. I am sure others can add to this =
list.

1) We need a function that can detect defects automatically and trigger =
corrective actions This function should also support statically =
configured MPLS networks.
2) We need a function to detect not only LSP breaks and miss-routing but =
also defects such as LSP replication into another LSP.
3) We need a function to immediately suppress the user traffic at the =
egress PE when an LSP is routed-routed.=20
4) To support PWE3 applications, we need a function to generate AIS for =
the tunneled circuits at the egress PE, when a defect is detected in the =
MPLS network.
5) We need a function to measure LSP performance accurately.
6)

Enrique
_______________
[email-masked]
Tel. (732)-420-3252

>-----Original Message-----
>From: Ping Pan [mailto:[email-masked]]
>Sent: Tuesday, March 05, 2002 10:15 AM
>To: Cuevas, Enrique G, ALASO
>Cc: Thomas D. Nadeau; [email-masked]
>Subject: Re: draft-bonica-tunneltrace-02
>
>
>The proposed stuff:
>  - a tool that can "ping" through a LSP,
>  - a tool that can do traceroute to a LSP
>  - a set of MIBs that can provide info on data traffic.
>
>They are not some projects dreamt by some bored developers. They are=20
>required by our customers. Now, as a person who works for a provider,=20
>would you please forget about XUZ standard from XYZ organization for a=20
>moment, :-) and tell us what other functionality that we=20
>should consider?
>
>Thank you!
>
>- Ping
>
>Cuevas, Enrique G, ALASO wrote:
>
>> Tom,
>> Could you provide us with a matrix (comply/does not comply)=20
>of the tools you are talking=20
>
>> about vs. the requirements given in Y.1710?
>>=20
>> Enrique
>
>

Delivery-date: Tue, 05 Mar 2002 09:01:36 -0800
Date: Tue, 05 Mar 2002 12:00:53 -0500
To: "Cuevas, Enrique G, ALASO" <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02 
Cc: "David Allan" <[email-masked]>, "Shahram Davari" <[email-masked]>, <[email-masked]>

         Why are we still discussing Y.1710? I thought that this
was the IETF. The following seem to comply with the operational
OAM requirements I am hearing from operators.

          LSP "ping",
          LSP Traceroute
          MIBs

         Others may be required.

         --Tom

>Could you provide us with a matrix (comply/does not comply) of the tools 
>you are
>talking about vs. the requirements given in Y.1710?
>
>Enrique
>_______________
>[email-masked]
>Tel. (732)-420-3252
>
>
> >-----Original Message-----
> >From: Thomas D. Nadeau [mailto:[email-masked]]
> >Sent: Tuesday, March 05, 2002 9:07 AM
> >To: David Allan
> >Cc: Shahram Davari; [email-masked]
> >Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> >
> >
> >>Your statement that requirements support the tools/mechanisms
> >that work
> >>today is the nib of my concern. Basically the requirments step is
> >>redundant at that point. We are now in a tight embrace where the
> >>requirements justify the solution and the solution dictates the
> >>requirements. Suggesting the requirements is a WG work item
> >would appear
> >>to be an oxymoron.
> >
> >         As I mentioned, some of the tools have already been worked
> >out, so yes, the cart is before the horse in some cases. However,
> >I don't think that this is necessarily a problem.
> >
> >         --Tom
> >
> >
> >
> >>Dave
> >>
> >> > -----Original Message-----
> >> > From: Thomas D. Nadeau
> >> [<mailto:[email-masked]>mailto:[email-masked]]
> >> > Sent: Monday, March 04, 2002 5:47 PM
> >> > To: Shahram Davari
> >> > Cc: [email-masked]
> >> > Subject: RE: draft-bonica-tunneltrace-02
> >> >
> >> >
> >> >
> >> > >Thanks for your positive response. With regards to the
> >> > protocol requirements,
> >> > >which ones do you think MUST be there and why?
> >> >
> >> >          I think that the protocol requirements for those
> >> > solutions that
> >> > currently
> >> > exist should be in there.  I understand your point about
> >> > reverse engineering the tools, but unfortunately the
> >> > requirement writing effort
> >> > started after we had some solutions working. Therefore
> >> > protocol requirements
> >> > do matter because they support the tools/mechanisms that work
> >> > today. No
> >> > need to obviate those things at this point.
> >> >
> >> > >In my view protocol requirements should not unnecessarily
> >> > restrict the
> >> > >solution,
> >> > >unless they violate application requirements.
> >> >
> >> >          I think that protocol requirements should be in line
> >> > with the
> >> > application
> >> > requirements that have come from operational folks working at
> >> > SPs.  However,
> >> > application requirements should fit within existing protocols
> >> > as much as
> >> > possible (to promote reuse of existing software/tools).
> >We should not
> >> > be forced to reinvent the wheel just for the sake of doing so.
> >> >
> >> >          --Tom
> >> >
> >> >
> >> >
> >> > >-Shahram
> >> > >
> >> > > > -----Original Message-----
> >> > > > From: Thomas D. Nadeau
> >> [<mailto:[email-masked]>mailto:[email-masked]]
> >> > > > Sent: Monday, March 04, 2002 4:25 PM
> >> > > > To: Shahram Davari
> >> > > > Cc: [email-masked]
> >> > > > Subject: RE: draft-bonica-tunneltrace-02
> >> > > >
> >> > > >
> >> > > >
> >> > > > >I think instead of debating whether Y.1711 is better than
> >> > > > LSP-ping/GTTP or
> >> > > > >vice versa, it would be more
> >> > > > >constructive to identify and document the applicability of
> >> > > > each proposal
> >> > > > >for various tunneling applications.
> >> > > >
> >> > > >          This sounds like a move in the right direction.
> >> > > >
> >> > > > >For this particular draft my suggestion at this stage is
> >> > > > that the Bonica's
> >> > > > >requirement draft be revised to:
> >> > > > >
> >> > > > >1) Add text (or at least a place holder) for additional
> >> > > > security issues
> >> > > > >raised on the list.
> >> > > > >2) Add backward compatibility, simplicity and scalability as
> >> > > > requirements.
> >> > > >
> >> > > >          I can go along with those.
> >> > > >
> >> > > > >3) Remove the protocol requirements section, since any
> >> > > > requirement here
> >> > > > >will be viewed as a reverse engineering of some solution.
> >> > > >
> >> > > >          Although this might sound reasonable to some, I
> >> > > > think that some
> >> > > > may object to this
> >> > > > since the protocol requirements are viewed by some as
> >> > > > fundamental to the
> >> > > > requirements
> >> > > > of any particular solution.  In the flurry of emails on the
> >> > > > topic, I have
> >> > > > not been able to
> >> > > > keep track of what the consensus on this might be (either
> >> > > > way). Perhaps Ron
> >> > > > has been keeping
> >> > > > track?
> >> > > >
> >> > > > >Then any offered solution should have text to show to what
> >> > > > extent they
> >> > > > >fulfill the
> >> > > > >requirements, and what is their applicability and
> >restrictions.
> >> > > >
> >> > > >          Sounds reasonable.
> >> > > >
> >> > > >          --Tom
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --------------------------------------------------------------
> >> > > > ----------
> >> > > > Mathematics is the supreme nostalgia of our time.
> >> > > >
> >> >
> >> >
> >> >
> >> > --------------------------------------------------------------
> >> > ----------
> >> > Mathematics is the supreme nostalgia of our time.
> >> >
> >> >
> >> >
> >
> >
> >
> >---------------------------------------------------------------
> >---------
> >Mathematics is the supreme nostalgia of our time.
> >
> >

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Tue, 05 Mar 2002 09:00:11 -0800
From: [email-masked]
Date: Tue, 5 Mar 2002 10:57:12 -0600
Subject: RE: Re: WG document status
TO: [email-masked], [email-masked]

> 
> but in any case, if there are multiple interoperational 
> implementations,
> then documenting that fact does not seem like a bad idea
>

So does the lack of interoperable implementations hinder the process to 
progress this specific document (or other documents in CCAMP) as 
proposed standard? 

or will that be a requirement only when progressing it beyond proposed 
standard to draft standard and further? 

Ananth
 
> Scott
> 
> 

Envelope-to: [email-masked]
Delivery-date: Tue, 05 Mar 2002 08:44:18 -0800
Date: Tue, 5 Mar 2002 11:43:22 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Re: WG document status

> I think it would be good if our current ADs could give their
> view on this. Also whether the routing area requirements are
> applicable for the Sub-IP area.

there is not a general requirement to meet the extra routing area requirements
in the sub-ip area - but the last time there was a discussion in
the sub-ip directorate about the want to hold GMPLS to the routing
area requirements (even though the work is no longer in the routing area)
the feeling was that it would be good to do so 

but in any case, if there are multiple interoperational implementations,
then documenting that fact does not seem like a bad idea

Scott

Envelope-to: [email-masked]
Delivery-date: Tue, 05 Mar 2002 08:24:01 -0800
Date: Tue, 5 Mar 2002 11:23:20 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: WG document status
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

> Does not RFC 2026 overrule the previous requirements, 

the pp in 2026 you note gives the IESG (backing up a AD for example)
flexibility to support the type of thing that the routing AD did

from 2026 sec 4.1.1
   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the 
   Internet.

Scott

Envelope-to: [email-masked]
Delivery-date: Tue, 05 Mar 2002 08:15:26 -0800
Date: Tue, 5 Mar 2002 11:14:57 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: WG document status
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

> According to the IETF Standard Process for routing "two or more
> interoperable implementations must exist" when a protocol is advanced
> from a Proposed Standard to a Draft Standard, but this is *not* required
> when a protocol goes into a Proposed Standard.

that is correct as far as the Internet Standards Process goes but Bob
Hinden, as the routing AD in 1991, wanted to impose a harder barrier
for protocols in the routing area - I was not on the IESG at the time
but it is my understanding that this change was supported by the IESG
for the routing area, as far as I know, no other area directors have
put forth similar ideas

RFC 1264 was published to document this decision

Scott

Delivery-date: Tue, 05 Mar 2002 08:14:07 -0800
Date: Tue, 05 Mar 2002 17:13:45 +0100
From: Loa Andersson <[email-masked]>
To: Sasha Vainshtein <[email-masked]>
CC: "Lazer, Monica A, ALCNS" <[email-masked]>, Yakov Rekhter <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], "Brungard, Deborah A, ALASO" <[email-masked]>, "Afferton, Thomas S (Tom), ALCNS" <[email-masked]>, "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Subject: Re: WG document status

Sasha,

given that I haven't researched the process enough, this
may be just my own opinions.
But I think that 1264 is still valid, it came out of the
concern of the routing AD at the time that errors in routing
protocls might have much more drastic implications than an
error in an application.

I think it would be good if our current ADs could give their
view on this. Also whether the routing area requirements are
applicable for the Sub-IP area.

/Loa

Sasha Vainshtein wrote:

> Loa and all,
> Does not RFC 2026 overrule the previous requirements, 
> like RFC 1264? And it does not require (Section 4.1.1) 
> even a SINGLE implementation for a Proposed Standard 
> even if it states that "the IESG may require one and if 
> existence of implementation and operational experience 
> are both declared "highly desirable" and would "represent 
> a strong argument in favor of a Proposed Standard designation".
> 
> With best regards,
>                                    Sasha Vainshtein
> email:     [email-masked] <mailto:[email-masked]> 
> tel:       +972-3-7659993 (office)
>            +972-8-9254948 (res.)
>            +972-58-674833 (cell.)
>  
> 
> 
> 
>>-----Original Message-----
>>From: Loa Andersson [mailto:[email-masked]]
>>Sent: Tuesday, March 05, 2002 5:26 PM
>>To: Lazer, Monica A, ALCNS
>>Cc: Yakov Rekhter; Wijnen, Bert (Bert); [email-masked]; 
>>Brungard, Deborah A, ALASO; Afferton, Thomas S (Tom), ALCNS; 
>>Ash, Gerald R (Jerry), ALASO
>>Subject: Re: WG document status
>>
>>
>>All,
>>
>>hopefully someone can shed light on this, there seems to be a
>>contradiction somewhere, if "general" is intended to be understood
>>as applicable to Proposed, Draft and Standard equally, what is
>>the reason to have lesser requirements for Proposed and Draft.
>>
>>Or is that "general" is something that the end result and the "steps"
>>in 1264 is what we have to achieve on our way there?
>>
>>
>>For PS there is a requirement of at least two independently written
>>implementations, but not on interoperability? Is that it?
>>
>>/Loa
>>
>>Lazer, Monica A, ALCNS wrote:
>>
>>
>>>Yakov,
>>>Bert,
>>>
>>>
>>>
>>>>>Please note that in the RTG area (rfc1264) there is no requirement
>>>>>for a Proposed Standard to have (a) more than one 
>>>>>
>>implementation, and
>>
>>>>>(b) for these implementations to be interoperable.
>>>>>
>>>>>
>>>>Nowhere in the above there is a requirement for multiple 
>>>>
>>interoperable
>>
>>>>implementations. With this in mind, please take out the part about
>>>>"interoperability test results".
>>>>
>>>>
>>>RFC 1264 also says:
>>>
>>>"3.0 General Requirements
>>>
>>>   4) Generally, a number of interoperable implementations must
>>>      exist.  At least two must be written independently.
>>>
>>>5.0 Requirements for Draft Standard
>>>
>>>   3) Two or more interoperable implementations must exist. 
>>>
>> At least
>>
>>>      two must be written independently.
>>>
>>>6.0 Requirements for Standard
>>>
>>>   3) Three or more interoperable implementations must 
>>>
>>exist.  At least
>>
>>>      two must be written independently."
>>>
>>>We would like to insist on 2 or more interoperable 
>>>
>>implementations being a requirement.  Without 
>>interoperability, any proprietary protocol does just the 
>>same, so we don't need an RFC for that.
>>
>>>
>>>Monica A. Lazer
>>>Advanced Transport Technology and Architecture Planning
>>>
>>>(908) 234 8462
>>>[email-masked]
>>>
>>>
>>>
>>>
>>>
>>
>>-- 
>>Loa Andersson
>>Chief Architect,
>>Utfors Research, Architecture and Future Lab (URAX)
>>Utfors AB
>>Råsundavägen 12
>>Box 525, 169 29 Solna
>>Office          +46 8 5270 2000
>>Office direct   +46 8 5270 5038
>>Mobile          +46 70 848 5038
>>Email           [email-masked]
>>WWW             www.utfors.se
>>
>>
> 

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se

Delivery-date: Tue, 05 Mar 2002 08:07:32 -0800
From: Sasha Vainshtein <[email-masked]>
To: 'Loa Andersson' <[email-masked]>, "Lazer, Monica A, ALCNS" <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], "Brungard, Deborah A, ALASO" <[email-masked]>, "Afferton, Thomas S (Tom), ALCNS" <[email-masked]>, "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Subject: RE: WG document status
Date: Tue, 5 Mar 2002 17:59:21 +0200 

Loa and all,
Does not RFC 2026 overrule the previous requirements,=20
like RFC 1264? And it does not require (Section 4.1.1)=20
even a SINGLE implementation for a Proposed Standard=20
even if it states that "the IESG may require one and if=20
existence of implementation and operational experience=20
are both declared "highly desirable" and would "represent=20
a strong argument in favor of a Proposed Standard designation".

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]>=20
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)
=20

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 5:26 PM
> To: Lazer, Monica A, ALCNS
> Cc: Yakov Rekhter; Wijnen, Bert (Bert); [email-masked];=20
> Brungard, Deborah A, ALASO; Afferton, Thomas S (Tom), ALCNS;=20
> Ash, Gerald R (Jerry), ALASO
> Subject: Re: WG document status
>=20
>=20
> All,
>=20
> hopefully someone can shed light on this, there seems to be a
> contradiction somewhere, if "general" is intended to be understood
> as applicable to Proposed, Draft and Standard equally, what is
> the reason to have lesser requirements for Proposed and Draft.
>=20
> Or is that "general" is something that the end result and the "steps"
> in 1264 is what we have to achieve on our way there?
>=20
>=20
> For PS there is a requirement of at least two independently written
> implementations, but not on interoperability? Is that it?
>=20
> /Loa
>=20
> Lazer, Monica A, ALCNS wrote:
>=20
> > Yakov,
> > Bert,
> >=20
> >=20
> >>>Please note that in the RTG area (rfc1264) there is no requirement
> >>>for a Proposed Standard to have (a) more than one=20
> implementation, and
> >>>(b) for these implementations to be interoperable.
> >>>
> >=20
> >>Nowhere in the above there is a requirement for multiple=20
> interoperable
> >>implementations. With this in mind, please take out the part about
> >>"interoperability test results".
> >>
> >=20
> > RFC 1264 also says:
> >=20
> > "3.0 General Requirements
> >=20
> >    4) Generally, a number of interoperable implementations must
> >       exist.  At least two must be written independently.
> >=20
> > 5.0 Requirements for Draft Standard
> >=20
> >    3) Two or more interoperable implementations must exist.=20
>  At least
> >       two must be written independently.
> >=20
> > 6.0 Requirements for Standard
> >=20
> >    3) Three or more interoperable implementations must=20
> exist.  At least
> >       two must be written independently."
> >=20
> > We would like to insist on 2 or more interoperable=20
> implementations being a requirement.  Without=20
> interoperability, any proprietary protocol does just the=20
> same, so we don't need an RFC for that.
> >=20
> >=20
> > Monica A. Lazer
> > Advanced Transport Technology and Architecture Planning
> >=20
> > (908) 234 8462
> > [email-masked]
> >=20
> >=20
> >=20
> >=20
>=20
>=20
> --=20
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> R=E5sundav=E4gen 12
> Box 525, 169 29 Solna
> Office          +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile          +46 70 848 5038
> Email           [email-masked]
> WWW             www.utfors.se
>=20
>=20

Delivery-date: Tue, 05 Mar 2002 08:03:48 -0800
Date: Tue, 05 Mar 2002 16:04:48 +0000
From: Giles Heron <[email-masked]>
Organization: PacketExchange Ltd.
To: David Allan <[email-masked]>
CC: [email-masked], Shahram Davari <[email-masked]>, "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

David Allan wrote:

> Eric:
> 
> I would phrase it differently. MPLS has a dual nature which tends to be 
> a function of the control plane used.
> 
> Most of what you describe as non-CO stuff permits LSPs to mimic the 
> topology generated by IP routing with as ruthlessly simple an 
> implementation as possible, and that's OK, that was a design goal.
> 
> However if that were the only application of MPLS, I would delegate it 
> to being a useless appendage on the IP forwarding plane. It only adds 
> baggage and complexity to no net value. I require things like liberal 
> label retention, supporting additional protocols (LDP), and lots of 
> extra logic on the node to approach the reliability that IP routing by 
> itself would be capable of without MPLS. This is because it adds steps 
> after routing convergence so that MPLS can configure the forwarding 
> table to mimic what the routing protocols have told it and that may 
> include having to solicit new labels from neighbors, or remebering a lot 
> of extra labels it would not otherwise need "just in case".

Actually there are other things you can do with "just" LDP that you 
can't do with IP.

1)  draft-martini etc.  Sure, IP equivalents of this are now being 
defined (UTI^H^H^H L2TPv3 et al) but they aren't as widely available, 
and are much less efficient encapsulation-wise (as they require an IP 
header plus a tunnel header instead of a couple of labels).

2)  MPLS VPN (RFC2547).  I won't go into the pros and cons of this right 
now ;-)

3)  BGP free network core.  This may improve stability (though there's 
certainly a strong argument that BGP is less destabilising than LDP 
right now) and security (the core doesn't need to know how to get to the 
Internet.)  Also this allows you to layer multiple distinct IP backbones 
over one MPLS core.

> It is when I get into topology manipulation independent of dynamic IP 
> routing that MPLS starts to add value and to claim this is not 
> connection oriented use of MPLS forwarding IMHO smacks of the same 
> "tunnel"/"layer" semantic debate that can also be said to waste much time.

this is your view.  And it is certainly one view.  But it isn't 
necessarily the only valid view ;-)

> I would also similarly invert the "saddled with CO mechanisms" statement 
> as it would appear that bringing some CO properties to IP is what MPLS 
> is all about. Otherwise IP without MPLS would be just fine....

again, some may differ on this.

Giles

> cheers
> Dave
> 
>  > -----Original Message-----
>  > From: Eric Rosen [mailto:[email-masked]]
>  > Sent: Tuesday, March 05, 2002 9:52 AM
>  > To: Shahram Davari
>  > Cc: 'Thomas D. Nadeau'; [email-masked]
>  > Subject: Re: draft-bonica-tunneltrace-02
>  >
>  >
>  >
>  > Shahram> What is  the difference between ATM,  FR, or any  CO
>  > technology and
>  > Shahram> MPLS
>  >
>  > Well, for  one thing, MPLS  isn't a CO  technology.  It's got
>  > lots  of stuff
>  > that doesn't really  make sense from a CO perspective.   Of
>  > course, when the
>  > CO  guys  run  across  these  features  (multipoint-to-point,
>  >  php,  liberal
>  > retention, independent  mode, equal  cost load balancing, 
>  > dynamic rerouting
>  > with no signaling,  ttl, lack of packet sequencing,  IP
>  > control plane, etc.,
>  > etc.) they assume that those features are there by mistake!
>  >
>  > This misconception  that MPLS  is a CO  technology, shared 
>  > as it is  by the
>  > "pure  IP" crowd and  by the  ITU/ATM crowd,  is the  source
>  > of  much wasted
>  > time. 
>  >
>  > MPLS is  actually an IP-derived technology that  facilitates
>  > the application
>  > of  certain   circuit-like  characteristics  to  IP 
>  > networks.    As  an  IP
>  > technology,  the usual  IP diagnostic  tools, such  as ping 
>  > and traceroute,
>  > should be applicable.   That's what this whole useless 
>  > discussion is about.
>  > One  the one  side are  people  who think  that IP  networks
>  > are  inherently
>  > unmanageable (after all, they don't  follow ITU standards),
>  > and on the other
>  > side are people who think that the IP-based paradigms are the best.
>  >
>  > It is true that  MPLS can be used to provide something  which
>  > is very like a
>  > CO network,  but it  doesn't have to  be used  this way, and 
>  > usually isn't.
>  > Those of use  who are not particularly interested in  CO
>  > networks just don't
>  > want to be saddled with the  legacy CO mechanisms. 
>  > Presumably, if all these
>  > legacy CO mechanisms were  so great there would not be such 
>  > a great rush to
>  > IP.
>  >
>  >
>  >
>  >
>  >
>  >
> 

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

Delivery-date: Tue, 05 Mar 2002 08:03:46 -0800
To: Loa Andersson <[email-masked]>
cc: "Lazer, Monica A, ALCNS" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], "Brungard, Deborah A, ALASO" <[email-masked]>, "Afferton, Thomas S (Tom), ALCNS" <[email-masked]>, "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Subject: Re: WG document status 
Date: Tue, 05 Mar 2002 08:03:16 -0800
From: Yakov Rekhter <[email-masked]>

Loa,
  
> hopefully someone can shed light on this, there seems to be a
> contradiction somewhere, if "general" is intended to be understood
> as applicable to Proposed, Draft and Standard equally, what is
> the reason to have lesser requirements for Proposed and Draft.
> 
> Or is that "general" is something that the end result and the "steps"
> in 1264 is what we have to achieve on our way there?

the latter.

> For PS there is a requirement of at least two independently written
> implementations, but not on interoperability? Is that it?

Quoting from rfc1264:

 4.0 Requirements for Proposed Standard

 .....

   4) One or more implementations must exist.

It said quite clear that *one*, not "at least two" implementations
is sufficient for a Proposed Standard.

Yakov.

Delivery-date: Tue, 05 Mar 2002 07:58:36 -0800
To: "Lazer, Monica A, ALCNS" <[email-masked]>
cc: "Yakov Rekhter" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], "Brungard, Deborah A, ALASO" <[email-masked]>, "Afferton, Thomas S (Tom), ALCNS" <[email-masked]>, "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Subject: Re: WG document status 
Date: Tue, 05 Mar 2002 07:57:37 -0800
From: Yakov Rekhter <[email-masked]>

Monica,

> Yakov,
> Bert,
> 
> > > Please note that in the RTG area (rfc1264) there is no requirement
> > > for a Proposed Standard to have (a) more than one implementation, and
> > > (b) for these implementations to be interoperable.
> 
> > Nowhere in the above there is a requirement for multiple interoperable
> > implementations. With this in mind, please take out the part about
> > "interoperability test results".
> 
> RFC 1264 also says:
> 
> "3.0 General Requirements
> 
>    4) Generally, a number of interoperable implementations must
>       exist.  At least two must be written independently.
> 
> 5.0 Requirements for Draft Standard
> 
>    3) Two or more interoperable implementations must exist.  At least
>       two must be written independently.
> 
> 6.0 Requirements for Standard
> 
>    3) Three or more interoperable implementations must exist.  At least
>       two must be written independently."
> 
> We would like to insist on 2 or more interoperable implementations being 
> a requirement. Without interoperability, any proprietary protocol does 
> just the same, so we don't need an RFC for that.

According to the IETF Standard Process for routing "two or more
interoperable implementations must exist" when a protocol is advanced
from a Proposed Standard to a Draft Standard, but this is *not* required
when a protocol goes into a Proposed Standard. If the "we" that you
referring to in the above don't like this, then the "we" need to work on 
changing the rules of the IETF Standard Process.

Yakov. 

Delivery-date: Tue, 05 Mar 2002 07:47:42 -0800
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Tue, 5 Mar 2002 07:46:48 -0800 

Eric,

> I  don't agree  that  "backward compatibility"  is  a 
> requirement.   There's
> nothing inherently wrong  with a tool that requires  support 
> in the backbone
> for it to achieve its full effect.

By backward compatibility I mean:

"No wrong action (or mis-interpretation) would take place if a node does not support the trace-route."

Therefore requiring support in the entire backbone is fine, and has nothing to do with backward compatibility, as long as the application is designed properly.

> 
> The problem with "simplicity" as a  requirement is that it is 
> not objective.
> I've never seen  a dispute in which the proponents  of a 
> particular proposal
> didn't  claim that  their proposal  is simple  and all  other 
>  proposals are
> nightmarishly complicated.

I agree with you that simplicity is subjective. But my point was more of the following nature:

"A simpler protocol is preferred against a complex protocol". Off course if there is only one proposal, then this requirement won't be applied.

-Shahram 

Delivery-date: Tue, 05 Mar 2002 07:26:36 -0800
Date: Tue, 05 Mar 2002 16:26:03 +0100
From: Loa Andersson <[email-masked]>
To: "Lazer, Monica A, ALCNS" <[email-masked]>
CC: Yakov Rekhter <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], "Brungard, Deborah A, ALASO" <[email-masked]>, "Afferton, Thomas S (Tom), ALCNS" <[email-masked]>, "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Subject: Re: WG document status

All,

hopefully someone can shed light on this, there seems to be a
contradiction somewhere, if "general" is intended to be understood
as applicable to Proposed, Draft and Standard equally, what is
the reason to have lesser requirements for Proposed and Draft.

Or is that "general" is something that the end result and the "steps"
in 1264 is what we have to achieve on our way there?

For PS there is a requirement of at least two independently written
implementations, but not on interoperability? Is that it?

/Loa

Lazer, Monica A, ALCNS wrote:

> Yakov,
> Bert,
> 
> 
>>>Please note that in the RTG area (rfc1264) there is no requirement
>>>for a Proposed Standard to have (a) more than one implementation, and
>>>(b) for these implementations to be interoperable.
>>>
> 
>>Nowhere in the above there is a requirement for multiple interoperable
>>implementations. With this in mind, please take out the part about
>>"interoperability test results".
>>
> 
> RFC 1264 also says:
> 
> "3.0 General Requirements
> 
>    4) Generally, a number of interoperable implementations must
>       exist.  At least two must be written independently.
> 
> 5.0 Requirements for Draft Standard
> 
>    3) Two or more interoperable implementations must exist.  At least
>       two must be written independently.
> 
> 6.0 Requirements for Standard
> 
>    3) Three or more interoperable implementations must exist.  At least
>       two must be written independently."
> 
> We would like to insist on 2 or more interoperable implementations being a requirement.  Without interoperability, any proprietary protocol does just the same, so we don't need an RFC for that.
> 
> 
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
> 
> (908) 234 8462
> [email-masked]
> 
> 
> 
> 

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se

Delivery-date: Tue, 05 Mar 2002 07:18:07 -0800
From: "David Allan"<[email-masked]>
To: [email-masked], Shahram Davari <[email-masked]>
Cc: "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Tue, 5 Mar 2002 10:17:48 -0500 

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

------_=_NextPart_001_01C1C458.E90157B0
Content-Type: text/plain;
	charset="iso-8859-1"

Eric:

I would phrase it differently. MPLS has a dual nature which tends to be a
function of the control plane used. 

Most of what you describe as non-CO stuff permits LSPs to mimic the topology
generated by IP routing with as ruthlessly simple an implementation as
possible, and that's OK, that was a design goal. 

However if that were the only application of MPLS, I would delegate it to
being a useless appendage on the IP forwarding plane. It only adds baggage
and complexity to no net value. I require things like liberal label
retention, supporting additional protocols (LDP), and lots of extra logic on
the node to approach the reliability that IP routing by itself would be
capable of without MPLS. This is because it adds steps after routing
convergence so that MPLS can configure the forwarding table to mimic what
the routing protocols have told it and that may include having to solicit
new labels from neighbors, or remebering a lot of extra labels it would not
otherwise need "just in case".

It is when I get into topology manipulation independent of dynamic IP
routing that MPLS starts to add value and to claim this is not connection
oriented use of MPLS forwarding IMHO smacks of the same "tunnel"/"layer"
semantic debate that can also be said to waste much time.

I would also similarly invert the "saddled with CO mechanisms" statement as
it would appear that bringing some CO properties to IP is what MPLS is all
about. Otherwise IP without MPLS would be just fine....

cheers
Dave 

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 9:52 AM
> To: Shahram Davari
> Cc: 'Thomas D. Nadeau'; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02 
> 
> 
> 
> Shahram> What is  the difference between ATM,  FR, or any  CO 
> technology and
> Shahram> MPLS 
> 
> Well, for  one thing, MPLS  isn't a CO  technology.  It's got 
> lots  of stuff
> that doesn't really  make sense from a CO perspective.   Of 
> course, when the
> CO  guys  run  across  these  features  (multipoint-to-point, 
>  php,  liberal
> retention, independent  mode, equal  cost load balancing,  
> dynamic rerouting
> with no signaling,  ttl, lack of packet sequencing,  IP 
> control plane, etc.,
> etc.) they assume that those features are there by mistake!
> 
> This misconception  that MPLS  is a CO  technology, shared  
> as it is  by the
> "pure  IP" crowd and  by the  ITU/ATM crowd,  is the  source 
> of  much wasted
> time.  
> 
> MPLS is  actually an IP-derived technology that  facilitates 
> the application
> of  certain   circuit-like  characteristics  to  IP  
> networks.    As  an  IP
> technology,  the usual  IP diagnostic  tools, such  as ping  
> and traceroute,
> should be applicable.   That's what this whole useless  
> discussion is about.
> One  the one  side are  people  who think  that IP  networks 
> are  inherently
> unmanageable (after all, they don't  follow ITU standards), 
> and on the other
> side are people who think that the IP-based paradigms are the best. 
> 
> It is true that  MPLS can be used to provide something  which 
> is very like a
> CO network,  but it  doesn't have to  be used  this way, and  
> usually isn't.
> Those of use  who are not particularly interested in  CO 
> networks just don't
> want to be saddled with the  legacy CO mechanisms.  
> Presumably, if all these
> legacy CO mechanisms were  so great there would not be such  
> a great rush to
> IP. 
> 
> 
> 
> 
> 
> 

------_=_NextPart_001_01C1C458.E90157B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: draft-bonica-tunneltrace-02 </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Eric:</FONT>
</P>

<P><FONT SIZE=3D2>I would phrase it differently. MPLS has a dual nature =
which tends to be a function of the control plane used. </FONT>
</P>

<P><FONT SIZE=3D2>Most of what you describe as non-CO stuff permits =
LSPs to mimic the topology generated by IP routing with as ruthlessly =
simple an implementation as possible, and that's OK, that was a design =
goal. </FONT></P>

<P><FONT SIZE=3D2>However if that were the only application of MPLS, I =
would delegate it to being a useless appendage on the IP forwarding =
plane. It only adds baggage and complexity to no net value. I require =
things like liberal label retention, supporting additional protocols =
(LDP), and lots of extra logic on the node to approach the reliability =
that IP routing by itself would be capable of without MPLS. This is =
because it adds steps after routing convergence so that MPLS can =
configure the forwarding table to mimic what the routing protocols have =
told it and that may include having to solicit new labels from =
neighbors, or remebering a lot of extra labels it would not otherwise =
need &quot;just in case&quot;.</FONT></P>

<P><FONT SIZE=3D2>It is when I get into topology manipulation =
independent of dynamic IP routing that MPLS starts to add value and to =
claim this is not connection oriented use of MPLS forwarding IMHO =
smacks of the same &quot;tunnel&quot;/&quot;layer&quot; semantic debate =
that can also be said to waste much time.</FONT></P>

<P><FONT SIZE=3D2>I would also similarly invert the &quot;saddled with =
CO mechanisms&quot; statement as it would appear that bringing some CO =
properties to IP is what MPLS is all about. Otherwise IP without MPLS =
would be just fine....</FONT></P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Eric Rosen [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, March 05, 2002 9:52 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Shahram Davari</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Thomas D. Nadeau'; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: draft-bonica-tunneltrace-02 =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Shahram&gt; What is&nbsp; the difference =
between ATM,&nbsp; FR, or any&nbsp; CO </FONT>
<BR><FONT SIZE=3D2>&gt; technology and</FONT>
<BR><FONT SIZE=3D2>&gt; Shahram&gt; MPLS </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Well, for&nbsp; one thing, MPLS&nbsp; isn't a =
CO&nbsp; technology.&nbsp; It's got </FONT>
<BR><FONT SIZE=3D2>&gt; lots&nbsp; of stuff</FONT>
<BR><FONT SIZE=3D2>&gt; that doesn't really&nbsp; make sense from a CO =
perspective.&nbsp;&nbsp; Of </FONT>
<BR><FONT SIZE=3D2>&gt; course, when the</FONT>
<BR><FONT SIZE=3D2>&gt; CO&nbsp; guys&nbsp; run&nbsp; across&nbsp; =
these&nbsp; features&nbsp; (multipoint-to-point, </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; php,&nbsp; liberal</FONT>
<BR><FONT SIZE=3D2>&gt; retention, independent&nbsp; mode, equal&nbsp; =
cost load balancing,&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; dynamic rerouting</FONT>
<BR><FONT SIZE=3D2>&gt; with no signaling,&nbsp; ttl, lack of packet =
sequencing,&nbsp; IP </FONT>
<BR><FONT SIZE=3D2>&gt; control plane, etc.,</FONT>
<BR><FONT SIZE=3D2>&gt; etc.) they assume that those features are there =
by mistake!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This misconception&nbsp; that MPLS&nbsp; is a =
CO&nbsp; technology, shared&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; as it is&nbsp; by the</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;pure&nbsp; IP&quot; crowd and&nbsp; by =
the&nbsp; ITU/ATM crowd,&nbsp; is the&nbsp; source </FONT>
<BR><FONT SIZE=3D2>&gt; of&nbsp; much wasted</FONT>
<BR><FONT SIZE=3D2>&gt; time.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; MPLS is&nbsp; actually an IP-derived technology =
that&nbsp; facilitates </FONT>
<BR><FONT SIZE=3D2>&gt; the application</FONT>
<BR><FONT SIZE=3D2>&gt; of&nbsp; certain&nbsp;&nbsp; circuit-like&nbsp; =
characteristics&nbsp; to&nbsp; IP&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; networks.&nbsp;&nbsp;&nbsp; As&nbsp; an&nbsp; =
IP</FONT>
<BR><FONT SIZE=3D2>&gt; technology,&nbsp; the usual&nbsp; IP =
diagnostic&nbsp; tools, such&nbsp; as ping&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; and traceroute,</FONT>
<BR><FONT SIZE=3D2>&gt; should be applicable.&nbsp;&nbsp; That's what =
this whole useless&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; discussion is about.</FONT>
<BR><FONT SIZE=3D2>&gt; One&nbsp; the one&nbsp; side are&nbsp; =
people&nbsp; who think&nbsp; that IP&nbsp; networks </FONT>
<BR><FONT SIZE=3D2>&gt; are&nbsp; inherently</FONT>
<BR><FONT SIZE=3D2>&gt; unmanageable (after all, they don't&nbsp; =
follow ITU standards), </FONT>
<BR><FONT SIZE=3D2>&gt; and on the other</FONT>
<BR><FONT SIZE=3D2>&gt; side are people who think that the IP-based =
paradigms are the best. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It is true that&nbsp; MPLS can be used to =
provide something&nbsp; which </FONT>
<BR><FONT SIZE=3D2>&gt; is very like a</FONT>
<BR><FONT SIZE=3D2>&gt; CO network,&nbsp; but it&nbsp; doesn't have =
to&nbsp; be used&nbsp; this way, and&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; usually isn't.</FONT>
<BR><FONT SIZE=3D2>&gt; Those of use&nbsp; who are not particularly =
interested in&nbsp; CO </FONT>
<BR><FONT SIZE=3D2>&gt; networks just don't</FONT>
<BR><FONT SIZE=3D2>&gt; want to be saddled with the&nbsp; legacy CO =
mechanisms.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Presumably, if all these</FONT>
<BR><FONT SIZE=3D2>&gt; legacy CO mechanisms were&nbsp; so great there =
would not be such&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; a great rush to</FONT>
<BR><FONT SIZE=3D2>&gt; IP. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C458.E90157B0--

Delivery-date: Tue, 05 Mar 2002 07:15:36 -0800
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Tue, 5 Mar 2002 07:15:05 -0800 

Eric,

> Shahram> 2) TTL expired user packets will now be forwarded to 
> UDP module
> Shahram>    instead of being dropped. Which could overload 
> the UDP module in
> Shahram>    certain situations.  
> 
> TTL-expired user packets are not simply dropped today; they 
> are forwarded to
> the ICMP module  to cause the generation of an  ICMP message. 
>  Usually there
> is some sort of limit placed on the number of packets that 
> can be queued for
> ICMP processing, or the  number of such packets that can be  
> seen in a given
> amount of  time, etc.  The  marginal overhead to  see whether 
> a  packet that
> makes it through to ICMP processing  is a GTTP packet doesn't 
> seem like that
> big a deal.
> 

What about the TTL expired MPLS packets? Should it be forwarded to the
ICMP module too? How does the system find that this is a GTTP packet or 
a user packet (consider non-IP user payload)?

-Shahram

Delivery-date: Tue, 05 Mar 2002 07:14:29 -0800
Date: Tue, 05 Mar 2002 07:15:20 -0800
From: Ping Pan <[email-masked]>
To: "Cuevas, Enrique G, ALASO" <[email-masked]>
CC: "Thomas D. Nadeau" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

The proposed stuff:
  - a tool that can "ping" through a LSP,
  - a tool that can do traceroute to a LSP
  - a set of MIBs that can provide info on data traffic.

They are not some projects dreamt by some bored developers. They are 
required by our customers. Now, as a person who works for a provider, 
would you please forget about XUZ standard from XYZ organization for a 
moment, :-) and tell us what other functionality that we should consider?

Thank you!

- Ping

Cuevas, Enrique G, ALASO wrote:

> Tom,
> Could you provide us with a matrix (comply/does not comply) of the tools you are talking 

> about vs. the requirements given in Y.1710?
> 
> Enrique

Delivery-date: Tue, 05 Mar 2002 07:04:13 -0800
content-class: urn:content-classes:message
Subject: RE: WG document status 
Date: Tue, 5 Mar 2002 10:03:11 -0500
From: "Lazer, Monica A, ALCNS" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: <[email-masked]>, "Lazer, Monica A, ALCNS" <[email-masked]>, "Brungard, Deborah A, ALASO" <[email-masked]>, "Afferton, Thomas S (Tom), ALCNS" <[email-masked]>, "Brungard, Deborah A, ALASO" <[email-masked]>, "Ash, Gerald R (Jerry), ALASO" <[email-masked]>

Yakov,
Bert,

> > Please note that in the RTG area (rfc1264) there is no requirement
> > for a Proposed Standard to have (a) more than one implementation, =
and
> > (b) for these implementations to be interoperable.

> Nowhere in the above there is a requirement for multiple interoperable
> implementations. With this in mind, please take out the part about
> "interoperability test results".

RFC 1264 also says:

"3.0 General Requirements

   4) Generally, a number of interoperable implementations must
      exist.  At least two must be written independently.

5.0 Requirements for Draft Standard

   3) Two or more interoperable implementations must exist.  At least
      two must be written independently.

6.0 Requirements for Standard

   3) Three or more interoperable implementations must exist.  At least
      two must be written independently."

We would like to insist on 2 or more interoperable implementations being =
a requirement.  Without interoperability, any proprietary protocol does =
just the same, so we don't need an RFC for that.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

(908) 234 8462
[email-masked]

Delivery-date: Tue, 05 Mar 2002 07:03:02 -0800
To: Shahram Davari <[email-masked]>
cc: "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02 
Reply-To: [email-masked]
Date: Tue, 05 Mar 2002 10:02:41 -0500
From: Eric Rosen <[email-masked]>

SHahram>  2)  Add  backward  compatibility, simplicity  and  scalability  as
SHahram>    requirements.  

I  don't agree  that  "backward compatibility"  is  a requirement.   There's
nothing inherently wrong  with a tool that requires  support in the backbone
for it to achieve its full effect. 

The problem with "simplicity" as a  requirement is that it is not objective.
I've never seen  a dispute in which the proponents  of a particular proposal
didn't  claim that  their proposal  is simple  and all  other  proposals are
nightmarishly complicated. 

Scalability  is  also  useless  as  a  requirement  unless  we  specify  the
particular  set of  dimensions  that we  think  should be  able to  increase
without impacting  the usefulness of  the scheme.  Different opinions  as to
what these  dimensions are  often lead to  endless disputes about  whether a
particular scheme is scalable or not. 

Delivery-date: Tue, 05 Mar 2002 06:52:15 -0800
To: Shahram Davari <[email-masked]>
cc: "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02 
Reply-To: [email-masked]
Date: Tue, 05 Mar 2002 09:51:57 -0500
From: Eric Rosen <[email-masked]>

Shahram> What is  the difference between ATM,  FR, or any  CO technology and
Shahram> MPLS 

Well, for  one thing, MPLS  isn't a CO  technology.  It's got lots  of stuff
that doesn't really  make sense from a CO perspective.   Of course, when the
CO  guys  run  across  these  features  (multipoint-to-point,  php,  liberal
retention, independent  mode, equal  cost load balancing,  dynamic rerouting
with no signaling,  ttl, lack of packet sequencing,  IP control plane, etc.,
etc.) they assume that those features are there by mistake!

This misconception  that MPLS  is a CO  technology, shared  as it is  by the
"pure  IP" crowd and  by the  ITU/ATM crowd,  is the  source of  much wasted
time.  

MPLS is  actually an IP-derived technology that  facilitates the application
of  certain   circuit-like  characteristics  to  IP  networks.    As  an  IP
technology,  the usual  IP diagnostic  tools, such  as ping  and traceroute,
should be applicable.   That's what this whole useless  discussion is about.
One  the one  side are  people  who think  that IP  networks are  inherently
unmanageable (after all, they don't  follow ITU standards), and on the other
side are people who think that the IP-based paradigms are the best. 

It is true that  MPLS can be used to provide something  which is very like a
CO network,  but it  doesn't have to  be used  this way, and  usually isn't.
Those of use  who are not particularly interested in  CO networks just don't
want to be saddled with the  legacy CO mechanisms.  Presumably, if all these
legacy CO mechanisms were  so great there would not be such  a great rush to
IP. 

Delivery-date: Tue, 05 Mar 2002 06:49:37 -0800
From: Shahram Davari <[email-masked]>
To: "'Thomas D. Nadeau'" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Tue, 5 Mar 2002 06:48:15 -0800 

Tom,

Let's stick to the principles. A requirement draft, should set the stage for multiple competing proposals, so that the WG could choose from. Adding protocol requirements that are reverse engineered from a single solution, violates this basic principle.

I understand your point, that a solution that presumably works has been developed, and it would be costly for you to replace it. But such a cost should be expected when one develops a proprietary or pre-standard solution.

Besides removing the protocol requirements, will not disqualify your solution.   

Yours,
-Shahram

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Monday, March 04, 2002 5:47 PM
> To: Shahram Davari
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> 
> >Thanks for your positive response. With regards to the 
> protocol requirements,
> >which ones do you think MUST be there and why?
> 
>          I think that the protocol requirements for those 
> solutions that 
> currently
> exist should be in there.  I understand your point about
> reverse engineering the tools, but unfortunately the 
> requirement writing effort
> started after we had some solutions working. Therefore 
> protocol requirements
> do matter because they support the tools/mechanisms that work 
> today. No
> need to obviate those things at this point.
> 
> >In my view protocol requirements should not unnecessarily 
> restrict the 
> >solution,
> >unless they violate application requirements.
> 
>          I think that protocol requirements should be in line 
> with the 
> application
> requirements that have come from operational folks working at 
> SPs.  However,
> application requirements should fit within existing protocols 
> as much as
> possible (to promote reuse of existing software/tools).  We should not
> be forced to reinvent the wheel just for the sake of doing so.
> 
>          --Tom
> 
> 
> 
> >-Shahram
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau [mailto:[email-masked]]
> > > Sent: Monday, March 04, 2002 4:25 PM
> > > To: Shahram Davari
> > > Cc: [email-masked]
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > >
> > > >I think instead of debating whether Y.1711 is better than
> > > LSP-ping/GTTP or
> > > >vice versa, it would be more
> > > >constructive to identify and document the applicability of
> > > each proposal
> > > >for various tunneling applications.
> > >
> > >          This sounds like a move in the right direction.
> > >
> > > >For this particular draft my suggestion at this stage is
> > > that the Bonica's
> > > >requirement draft be revised to:
> > > >
> > > >1) Add text (or at least a place holder) for additional
> > > security issues
> > > >raised on the list.
> > > >2) Add backward compatibility, simplicity and scalability as
> > > requirements.
> > >
> > >          I can go along with those.
> > >
> > > >3) Remove the protocol requirements section, since any
> > > requirement here
> > > >will be viewed as a reverse engineering of some solution.
> > >
> > >          Although this might sound reasonable to some, I
> > > think that some
> > > may object to this
> > > since the protocol requirements are viewed by some as
> > > fundamental to the
> > > requirements
> > > of any particular solution.  In the flurry of emails on the
> > > topic, I have
> > > not been able to
> > > keep track of what the consensus on this might be (either
> > > way). Perhaps Ron
> > > has been keeping
> > > track?
> > >
> > > >Then any offered solution should have text to show to what
> > > extent they
> > > >fulfill the
> > > >requirements, and what is their applicability and restrictions.
> > >
> > >          Sounds reasonable.
> > >
> > >          --Tom
> > >
> > >
> > >
> > >
> > >
> > >
> > > --------------------------------------------------------------
> > > ----------
> > > Mathematics is the supreme nostalgia of our time.
> > >
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 

Delivery-date: Tue, 05 Mar 2002 06:36:57 -0800
content-class: urn:content-classes:message
Subject: RE: draft-bonica-tunneltrace-02 
Date: Tue, 5 Mar 2002 09:35:17 -0500
From: "Cuevas, Enrique G, ALASO" <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>, "David Allan" <[email-masked]>
Cc: "Shahram Davari" <[email-masked]>, <[email-masked]>

Tom,
Could you provide us with a matrix (comply/does not comply) of the tools =
you are talking about vs. the requirements given in Y.1710?

Enrique
_______________
[email-masked]
Tel. (732)-420-3252

>-----Original Message-----
>From: Thomas D. Nadeau [mailto:[email-masked]]
>Sent: Tuesday, March 05, 2002 9:07 AM
>To: David Allan
>Cc: Shahram Davari; [email-masked]
>Subject: RE: draft-bonica-tunneltrace-02=20
>
>
>
>
>>Your statement that requirements support the tools/mechanisms=20
>that work=20
>>today is the nib of my concern. Basically the requirments step is=20
>>redundant at that point. We are now in a tight embrace where the=20
>>requirements justify the solution and the solution dictates the=20
>>requirements. Suggesting the requirements is a WG work item=20
>would appear=20
>>to be an oxymoron.
>
>         As I mentioned, some of the tools have already been worked
>out, so yes, the cart is before the horse in some cases. However,
>I don't think that this is necessarily a problem.
>
>         --Tom
>
>
>
>>Dave
>>
>> > -----Original Message-----
>> > From: Thomas D. Nadeau=20
>> [<mailto:[email-masked]>mailto:[email-masked]]
>> > Sent: Monday, March 04, 2002 5:47 PM
>> > To: Shahram Davari
>> > Cc: [email-masked]
>> > Subject: RE: draft-bonica-tunneltrace-02
>> >
>> >
>> >
>> > >Thanks for your positive response. With regards to the
>> > protocol requirements,
>> > >which ones do you think MUST be there and why?
>> >
>> >          I think that the protocol requirements for those
>> > solutions that
>> > currently
>> > exist should be in there.  I understand your point about
>> > reverse engineering the tools, but unfortunately the
>> > requirement writing effort
>> > started after we had some solutions working. Therefore
>> > protocol requirements
>> > do matter because they support the tools/mechanisms that work
>> > today. No
>> > need to obviate those things at this point.
>> >
>> > >In my view protocol requirements should not unnecessarily
>> > restrict the
>> > >solution,
>> > >unless they violate application requirements.
>> >
>> >          I think that protocol requirements should be in line
>> > with the
>> > application
>> > requirements that have come from operational folks working at
>> > SPs.  However,
>> > application requirements should fit within existing protocols
>> > as much as
>> > possible (to promote reuse of existing software/tools). =20
>We should not
>> > be forced to reinvent the wheel just for the sake of doing so.
>> >
>> >          --Tom
>> >
>> >
>> >
>> > >-Shahram
>> > >
>> > > > -----Original Message-----
>> > > > From: Thomas D. Nadeau=20
>> [<mailto:[email-masked]>mailto:[email-masked]]
>> > > > Sent: Monday, March 04, 2002 4:25 PM
>> > > > To: Shahram Davari
>> > > > Cc: [email-masked]
>> > > > Subject: RE: draft-bonica-tunneltrace-02
>> > > >
>> > > >
>> > > >
>> > > > >I think instead of debating whether Y.1711 is better than
>> > > > LSP-ping/GTTP or
>> > > > >vice versa, it would be more
>> > > > >constructive to identify and document the applicability of
>> > > > each proposal
>> > > > >for various tunneling applications.
>> > > >
>> > > >          This sounds like a move in the right direction.
>> > > >
>> > > > >For this particular draft my suggestion at this stage is
>> > > > that the Bonica's
>> > > > >requirement draft be revised to:
>> > > > >
>> > > > >1) Add text (or at least a place holder) for additional
>> > > > security issues
>> > > > >raised on the list.
>> > > > >2) Add backward compatibility, simplicity and scalability as
>> > > > requirements.
>> > > >
>> > > >          I can go along with those.
>> > > >
>> > > > >3) Remove the protocol requirements section, since any
>> > > > requirement here
>> > > > >will be viewed as a reverse engineering of some solution.
>> > > >
>> > > >          Although this might sound reasonable to some, I
>> > > > think that some
>> > > > may object to this
>> > > > since the protocol requirements are viewed by some as
>> > > > fundamental to the
>> > > > requirements
>> > > > of any particular solution.  In the flurry of emails on the
>> > > > topic, I have
>> > > > not been able to
>> > > > keep track of what the consensus on this might be (either
>> > > > way). Perhaps Ron
>> > > > has been keeping
>> > > > track?
>> > > >
>> > > > >Then any offered solution should have text to show to what
>> > > > extent they
>> > > > >fulfill the
>> > > > >requirements, and what is their applicability and=20
>restrictions.
>> > > >
>> > > >          Sounds reasonable.
>> > > >
>> > > >          --Tom
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --------------------------------------------------------------
>> > > > ----------
>> > > > Mathematics is the supreme nostalgia of our time.
>> > > >
>> >
>> >
>> >
>> > --------------------------------------------------------------
>> > ----------
>> > Mathematics is the supreme nostalgia of our time.
>> >
>> >
>> >
>
>
>
>---------------------------------------------------------------
>---------
>Mathematics is the supreme nostalgia of our time.=20
>
>

Delivery-date: Tue, 05 Mar 2002 06:11:26 -0800
From: "David Allan"<[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>
Cc: Shahram Davari <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Tue, 5 Mar 2002 09:11:08 -0500 

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

------_=_NextPart_001_01C1C44F.98A0A590
Content-Type: text/plain;
	charset="iso-8859-1"

But the requirements still need to be independent of the solution if they
are to be requirements. If the whole goal of this exercise is simply to
document a-prioi solutions, then isn't that what informational RFCs are for.

Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 9:07 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: Shahram Davari; [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> 
> 
> >Your statement that requirements support the 
> tools/mechanisms that work 
> >today is the nib of my concern. Basically the requirments step is 
> >redundant at that point. We are now in a tight embrace where the 
> >requirements justify the solution and the solution dictates the 
> >requirements. Suggesting the requirements is a WG work item 
> would appear 
> >to be an oxymoron.
> 
>          As I mentioned, some of the tools have already been worked
> out, so yes, the cart is before the horse in some cases. However,
> I don't think that this is necessarily a problem.
> 
>          --Tom
> 
> 
> 
> >Dave
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau 
> > [<mailto:[email-masked]>mailto:[email-masked]]
> > > Sent: Monday, March 04, 2002 5:47 PM
> > > To: Shahram Davari
> > > Cc: [email-masked]
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > >
> > > >Thanks for your positive response. With regards to the
> > > protocol requirements,
> > > >which ones do you think MUST be there and why?
> > >
> > >          I think that the protocol requirements for those
> > > solutions that
> > > currently
> > > exist should be in there.  I understand your point about
> > > reverse engineering the tools, but unfortunately the
> > > requirement writing effort
> > > started after we had some solutions working. Therefore
> > > protocol requirements
> > > do matter because they support the tools/mechanisms that work
> > > today. No
> > > need to obviate those things at this point.
> > >
> > > >In my view protocol requirements should not unnecessarily
> > > restrict the
> > > >solution,
> > > >unless they violate application requirements.
> > >
> > >          I think that protocol requirements should be in line
> > > with the
> > > application
> > > requirements that have come from operational folks working at
> > > SPs.  However,
> > > application requirements should fit within existing protocols
> > > as much as
> > > possible (to promote reuse of existing software/tools).  
> We should not
> > > be forced to reinvent the wheel just for the sake of doing so.
> > >
> > >          --Tom
> > >
> > >
> > >
> > > >-Shahram
> > > >
> > > > > -----Original Message-----
> > > > > From: Thomas D. Nadeau 
> > [<mailto:[email-masked]>mailto:[email-masked]]
> > > > > Sent: Monday, March 04, 2002 4:25 PM
> > > > > To: Shahram Davari
> > > > > Cc: [email-masked]
> > > > > Subject: RE: draft-bonica-tunneltrace-02
> > > > >
> > > > >
> > > > >
> > > > > >I think instead of debating whether Y.1711 is better than
> > > > > LSP-ping/GTTP or
> > > > > >vice versa, it would be more
> > > > > >constructive to identify and document the applicability of
> > > > > each proposal
> > > > > >for various tunneling applications.
> > > > >
> > > > >          This sounds like a move in the right direction.
> > > > >
> > > > > >For this particular draft my suggestion at this stage is
> > > > > that the Bonica's
> > > > > >requirement draft be revised to:
> > > > > >
> > > > > >1) Add text (or at least a place holder) for additional
> > > > > security issues
> > > > > >raised on the list.
> > > > > >2) Add backward compatibility, simplicity and scalability as
> > > > > requirements.
> > > > >
> > > > >          I can go along with those.
> > > > >
> > > > > >3) Remove the protocol requirements section, since any
> > > > > requirement here
> > > > > >will be viewed as a reverse engineering of some solution.
> > > > >
> > > > >          Although this might sound reasonable to some, I
> > > > > think that some
> > > > > may object to this
> > > > > since the protocol requirements are viewed by some as
> > > > > fundamental to the
> > > > > requirements
> > > > > of any particular solution.  In the flurry of emails on the
> > > > > topic, I have
> > > > > not been able to
> > > > > keep track of what the consensus on this might be (either
> > > > > way). Perhaps Ron
> > > > > has been keeping
> > > > > track?
> > > > >
> > > > > >Then any offered solution should have text to show to what
> > > > > extent they
> > > > > >fulfill the
> > > > > >requirements, and what is their applicability and 
> restrictions.
> > > > >
> > > > >          Sounds reasonable.
> > > > >
> > > > >          --Tom
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --------------------------------------------------------------
> > > > > ----------
> > > > > Mathematics is the supreme nostalgia of our time.
> > > > >
> > >
> > >
> > >
> > > --------------------------------------------------------------
> > > ----------
> > > Mathematics is the supreme nostalgia of our time.
> > >
> > >
> > >
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 
> 

------_=_NextPart_001_01C1C44F.98A0A590
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: draft-bonica-tunneltrace-02 </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>But the requirements still need to be independent of =
the solution if they are to be requirements. If the whole goal of this =
exercise is simply to document a-prioi solutions, then isn't that what =
informational RFCs are for.</FONT></P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Thomas D. Nadeau [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, March 05, 2002 9:07 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Allan, David [CAR:NS00:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Shahram Davari; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: draft-bonica-tunneltrace-02 =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Your statement that requirements support =
the </FONT>
<BR><FONT SIZE=3D2>&gt; tools/mechanisms that work </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;today is the nib of my concern. Basically =
the requirments step is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;redundant at that point. We are now in a =
tight embrace where the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;requirements justify the solution and the =
solution dictates the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;requirements. Suggesting the requirements =
is a WG work item </FONT>
<BR><FONT SIZE=3D2>&gt; would appear </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;to be an oxymoron.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; As =
I mentioned, some of the tools have already been worked</FONT>
<BR><FONT SIZE=3D2>&gt; out, so yes, the cart is before the horse in =
some cases. However,</FONT>
<BR><FONT SIZE=3D2>&gt; I don't think that this is necessarily a =
problem.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--Tom</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Dave</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Thomas D. Nadeau </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [&lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&gt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Monday, March 04, 2002 5:47 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: Shahram Davari</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: RE: =
draft-bonica-tunneltrace-02</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;Thanks for your positive =
response. With regards to the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; protocol requirements,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;which ones do you think MUST be =
there and why?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think that =
the protocol requirements for those</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; solutions that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; currently</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; exist should be in there.&nbsp; I =
understand your point about</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; reverse engineering the tools, but =
unfortunately the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; requirement writing effort</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; started after we had some solutions =
working. Therefore</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; protocol requirements</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; do matter because they support the =
tools/mechanisms that work</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; today. No</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; need to obviate those things at this =
point.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;In my view protocol requirements =
should not unnecessarily</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; restrict the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;solution,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;unless they violate application =
requirements.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think that =
protocol requirements should be in line</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; with the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; application</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; requirements that have come from =
operational folks working at</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; SPs.&nbsp; However,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; application requirements should fit =
within existing protocols</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; as much as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; possible (to promote reuse of =
existing software/tools).&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; We should not</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; be forced to reinvent the wheel just =
for the sake of doing so.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --Tom</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;-Shahram</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; From: Thomas D. Nadeau =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [&lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&gt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Sent: Monday, March 04, =
2002 4:25 PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; To: Shahram Davari</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Cc: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Subject: RE: =
draft-bonica-tunneltrace-02</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;I think instead of =
debating whether Y.1711 is better than</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; LSP-ping/GTTP or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;vice versa, it would be =
more</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;constructive to =
identify and document the applicability of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; each proposal</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;for various tunneling =
applications.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This sounds =
like a move in the right direction.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;For this particular =
draft my suggestion at this stage is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; that the Bonica's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;requirement draft be =
revised to:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;1) Add text (or at =
least a place holder) for additional</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; security issues</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;raised on the =
list.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;2) Add backward =
compatibility, simplicity and scalability as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; requirements.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I can go =
along with those.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;3) Remove the protocol =
requirements section, since any</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; requirement here</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;will be viewed as a =
reverse engineering of some solution.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Although =
this might sound reasonable to some, I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; think that some</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; may object to this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; since the protocol =
requirements are viewed by some as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; fundamental to the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; requirements</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; of any particular =
solution.&nbsp; In the flurry of emails on the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; topic, I have</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; not been able to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; keep track of what the =
consensus on this might be (either</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; way). Perhaps Ron</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; has been keeping</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; track?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;Then any offered =
solution should have text to show to what</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; extent they</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;fulfill the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;requirements, and what =
is their applicability and </FONT>
<BR><FONT SIZE=3D2>&gt; restrictions.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sounds =
reasonable.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --Tom</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; =
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; ----------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Mathematics is the supreme =
nostalgia of our time.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ----------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Mathematics is the supreme nostalgia =
of our time.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; ----------</FONT>
<BR><FONT SIZE=3D2>&gt; Mathematics is the supreme nostalgia of our =
time. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C44F.98A0A590--

Delivery-date: Tue, 05 Mar 2002 06:08:09 -0800
Date: Tue, 05 Mar 2002 09:06:58 -0500
To: "David Allan"<[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02 
Cc: Shahram Davari <[email-masked]>, [email-masked]

>Your statement that requirements support the tools/mechanisms that work 
>today is the nib of my concern. Basically the requirments step is 
>redundant at that point. We are now in a tight embrace where the 
>requirements justify the solution and the solution dictates the 
>requirements. Suggesting the requirements is a WG work item would appear 
>to be an oxymoron.

         As I mentioned, some of the tools have already been worked
out, so yes, the cart is before the horse in some cases. However,
I don't think that this is necessarily a problem.

         --Tom

>Dave
>
> > -----Original Message-----
> > From: Thomas D. Nadeau 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Monday, March 04, 2002 5:47 PM
> > To: Shahram Davari
> > Cc: [email-masked]
> > Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> >
> > >Thanks for your positive response. With regards to the
> > protocol requirements,
> > >which ones do you think MUST be there and why?
> >
> >          I think that the protocol requirements for those
> > solutions that
> > currently
> > exist should be in there.  I understand your point about
> > reverse engineering the tools, but unfortunately the
> > requirement writing effort
> > started after we had some solutions working. Therefore
> > protocol requirements
> > do matter because they support the tools/mechanisms that work
> > today. No
> > need to obviate those things at this point.
> >
> > >In my view protocol requirements should not unnecessarily
> > restrict the
> > >solution,
> > >unless they violate application requirements.
> >
> >          I think that protocol requirements should be in line
> > with the
> > application
> > requirements that have come from operational folks working at
> > SPs.  However,
> > application requirements should fit within existing protocols
> > as much as
> > possible (to promote reuse of existing software/tools).  We should not
> > be forced to reinvent the wheel just for the sake of doing so.
> >
> >          --Tom
> >
> >
> >
> > >-Shahram
> > >
> > > > -----Original Message-----
> > > > From: Thomas D. Nadeau 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > > > Sent: Monday, March 04, 2002 4:25 PM
> > > > To: Shahram Davari
> > > > Cc: [email-masked]
> > > > Subject: RE: draft-bonica-tunneltrace-02
> > > >
> > > >
> > > >
> > > > >I think instead of debating whether Y.1711 is better than
> > > > LSP-ping/GTTP or
> > > > >vice versa, it would be more
> > > > >constructive to identify and document the applicability of
> > > > each proposal
> > > > >for various tunneling applications.
> > > >
> > > >          This sounds like a move in the right direction.
> > > >
> > > > >For this particular draft my suggestion at this stage is
> > > > that the Bonica's
> > > > >requirement draft be revised to:
> > > > >
> > > > >1) Add text (or at least a place holder) for additional
> > > > security issues
> > > > >raised on the list.
> > > > >2) Add backward compatibility, simplicity and scalability as
> > > > requirements.
> > > >
> > > >          I can go along with those.
> > > >
> > > > >3) Remove the protocol requirements section, since any
> > > > requirement here
> > > > >will be viewed as a reverse engineering of some solution.
> > > >
> > > >          Although this might sound reasonable to some, I
> > > > think that some
> > > > may object to this
> > > > since the protocol requirements are viewed by some as
> > > > fundamental to the
> > > > requirements
> > > > of any particular solution.  In the flurry of emails on the
> > > > topic, I have
> > > > not been able to
> > > > keep track of what the consensus on this might be (either
> > > > way). Perhaps Ron
> > > > has been keeping
> > > > track?
> > > >
> > > > >Then any offered solution should have text to show to what
> > > > extent they
> > > > >fulfill the
> > > > >requirements, and what is their applicability and restrictions.
> > > >
> > > >          Sounds reasonable.
> > > >
> > > >          --Tom
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --------------------------------------------------------------
> > > > ----------
> > > > Mathematics is the supreme nostalgia of our time.
> > > >
> >
> >
> >
> > --------------------------------------------------------------
> > ----------
> > Mathematics is the supreme nostalgia of our time.
> >
> >
> >

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Tue, 05 Mar 2002 05:42:12 -0800
From: "David Allan"<[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>, Shahram Davari <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Tue, 5 Mar 2002 08:36:53 -0500 

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

------_=_NextPart_001_01C1C44A.CFA8BA50
Content-Type: text/plain;
	charset="iso-8859-1"

Tom:

Your statement that requirements support the tools/mechanisms that work
today is the nib of my concern. Basically the requirments step is redundant
at that point. We are now in a tight embrace where the requirements justify
the solution and the solution dictates the requirements. Suggesting the
requirements is a WG work item would appear to be an oxymoron.

Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Monday, March 04, 2002 5:47 PM
> To: Shahram Davari
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> 
> >Thanks for your positive response. With regards to the 
> protocol requirements,
> >which ones do you think MUST be there and why?
> 
>          I think that the protocol requirements for those 
> solutions that 
> currently
> exist should be in there.  I understand your point about
> reverse engineering the tools, but unfortunately the 
> requirement writing effort
> started after we had some solutions working. Therefore 
> protocol requirements
> do matter because they support the tools/mechanisms that work 
> today. No
> need to obviate those things at this point.
> 
> >In my view protocol requirements should not unnecessarily 
> restrict the 
> >solution,
> >unless they violate application requirements.
> 
>          I think that protocol requirements should be in line 
> with the 
> application
> requirements that have come from operational folks working at 
> SPs.  However,
> application requirements should fit within existing protocols 
> as much as
> possible (to promote reuse of existing software/tools).  We should not
> be forced to reinvent the wheel just for the sake of doing so.
> 
>          --Tom
> 
> 
> 
> >-Shahram
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau [mailto:[email-masked]]
> > > Sent: Monday, March 04, 2002 4:25 PM
> > > To: Shahram Davari
> > > Cc: [email-masked]
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > >
> > > >I think instead of debating whether Y.1711 is better than
> > > LSP-ping/GTTP or
> > > >vice versa, it would be more
> > > >constructive to identify and document the applicability of
> > > each proposal
> > > >for various tunneling applications.
> > >
> > >          This sounds like a move in the right direction.
> > >
> > > >For this particular draft my suggestion at this stage is
> > > that the Bonica's
> > > >requirement draft be revised to:
> > > >
> > > >1) Add text (or at least a place holder) for additional
> > > security issues
> > > >raised on the list.
> > > >2) Add backward compatibility, simplicity and scalability as
> > > requirements.
> > >
> > >          I can go along with those.
> > >
> > > >3) Remove the protocol requirements section, since any
> > > requirement here
> > > >will be viewed as a reverse engineering of some solution.
> > >
> > >          Although this might sound reasonable to some, I
> > > think that some
> > > may object to this
> > > since the protocol requirements are viewed by some as
> > > fundamental to the
> > > requirements
> > > of any particular solution.  In the flurry of emails on the
> > > topic, I have
> > > not been able to
> > > keep track of what the consensus on this might be (either
> > > way). Perhaps Ron
> > > has been keeping
> > > track?
> > >
> > > >Then any offered solution should have text to show to what
> > > extent they
> > > >fulfill the
> > > >requirements, and what is their applicability and restrictions.
> > >
> > >          Sounds reasonable.
> > >
> > >          --Tom
> > >
> > >
> > >
> > >
> > >
> > >
> > > --------------------------------------------------------------
> > > ----------
> > > Mathematics is the supreme nostalgia of our time.
> > >
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 
> 
> 

------_=_NextPart_001_01C1C44A.CFA8BA50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: draft-bonica-tunneltrace-02 </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Tom:</FONT>
</P>

<P><FONT SIZE=3D2>Your statement that requirements support the =
tools/mechanisms that work today is the nib of my concern. Basically =
the requirments step is redundant at that point. We are now in a tight =
embrace where the requirements justify the solution and the solution =
dictates the requirements. Suggesting the requirements is a WG work =
item would appear to be an oxymoron.</FONT></P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Thomas D. Nadeau [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, March 04, 2002 5:47 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Shahram Davari</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: draft-bonica-tunneltrace-02 =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Thanks for your positive response. With =
regards to the </FONT>
<BR><FONT SIZE=3D2>&gt; protocol requirements,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;which ones do you think MUST be there and =
why?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I =
think that the protocol requirements for those </FONT>
<BR><FONT SIZE=3D2>&gt; solutions that </FONT>
<BR><FONT SIZE=3D2>&gt; currently</FONT>
<BR><FONT SIZE=3D2>&gt; exist should be in there.&nbsp; I understand =
your point about</FONT>
<BR><FONT SIZE=3D2>&gt; reverse engineering the tools, but =
unfortunately the </FONT>
<BR><FONT SIZE=3D2>&gt; requirement writing effort</FONT>
<BR><FONT SIZE=3D2>&gt; started after we had some solutions working. =
Therefore </FONT>
<BR><FONT SIZE=3D2>&gt; protocol requirements</FONT>
<BR><FONT SIZE=3D2>&gt; do matter because they support the =
tools/mechanisms that work </FONT>
<BR><FONT SIZE=3D2>&gt; today. No</FONT>
<BR><FONT SIZE=3D2>&gt; need to obviate those things at this =
point.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;In my view protocol requirements should not =
unnecessarily </FONT>
<BR><FONT SIZE=3D2>&gt; restrict the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;solution,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;unless they violate application =
requirements.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I =
think that protocol requirements should be in line </FONT>
<BR><FONT SIZE=3D2>&gt; with the </FONT>
<BR><FONT SIZE=3D2>&gt; application</FONT>
<BR><FONT SIZE=3D2>&gt; requirements that have come from operational =
folks working at </FONT>
<BR><FONT SIZE=3D2>&gt; SPs.&nbsp; However,</FONT>
<BR><FONT SIZE=3D2>&gt; application requirements should fit within =
existing protocols </FONT>
<BR><FONT SIZE=3D2>&gt; as much as</FONT>
<BR><FONT SIZE=3D2>&gt; possible (to promote reuse of existing =
software/tools).&nbsp; We should not</FONT>
<BR><FONT SIZE=3D2>&gt; be forced to reinvent the wheel just for the =
sake of doing so.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--Tom</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;-Shahram</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Thomas D. Nadeau [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Monday, March 04, 2002 4:25 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: Shahram Davari</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: RE: =
draft-bonica-tunneltrace-02</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;I think instead of debating =
whether Y.1711 is better than</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; LSP-ping/GTTP or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;vice versa, it would be =
more</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;constructive to identify and =
document the applicability of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; each proposal</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;for various tunneling =
applications.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This sounds =
like a move in the right direction.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;For this particular draft my =
suggestion at this stage is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; that the Bonica's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;requirement draft be revised =
to:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;1) Add text (or at least a place =
holder) for additional</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; security issues</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;raised on the list.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;2) Add backward compatibility, =
simplicity and scalability as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; requirements.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I can go =
along with those.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;3) Remove the protocol =
requirements section, since any</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; requirement here</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;will be viewed as a reverse =
engineering of some solution.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Although =
this might sound reasonable to some, I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; think that some</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; may object to this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; since the protocol requirements are =
viewed by some as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; fundamental to the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; requirements</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; of any particular solution.&nbsp; In =
the flurry of emails on the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; topic, I have</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; not been able to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; keep track of what the consensus on =
this might be (either</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; way). Perhaps Ron</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; has been keeping</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; track?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;Then any offered solution should =
have text to show to what</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; extent they</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;fulfill the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;requirements, and what is their =
applicability and restrictions.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sounds =
reasonable.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --Tom</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ----------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Mathematics is the supreme nostalgia =
of our time.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; ----------</FONT>
<BR><FONT SIZE=3D2>&gt; Mathematics is the supreme nostalgia of our =
time. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C44A.CFA8BA50--

Delivery-date: Mon, 04 Mar 2002 15:04:32 -0800
Date: Mon, 04 Mar 2002 17:47:15 -0500
To: Shahram Davari <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02 
Cc: [email-masked]

>Thanks for your positive response. With regards to the protocol requirements,
>which ones do you think MUST be there and why?

         I think that the protocol requirements for those solutions that 
currently
exist should be in there.  I understand your point about
reverse engineering the tools, but unfortunately the requirement writing effort
started after we had some solutions working. Therefore protocol requirements
do matter because they support the tools/mechanisms that work today. No
need to obviate those things at this point.

>In my view protocol requirements should not unnecessarily restrict the 
>solution,
>unless they violate application requirements.

         I think that protocol requirements should be in line with the 
application
requirements that have come from operational folks working at SPs.  However,
application requirements should fit within existing protocols as much as
possible (to promote reuse of existing software/tools).  We should not
be forced to reinvent the wheel just for the sake of doing so.

         --Tom

>-Shahram
>
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:[email-masked]]
> > Sent: Monday, March 04, 2002 4:25 PM
> > To: Shahram Davari
> > Cc: [email-masked]
> > Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> >
> > >I think instead of debating whether Y.1711 is better than
> > LSP-ping/GTTP or
> > >vice versa, it would be more
> > >constructive to identify and document the applicability of
> > each proposal
> > >for various tunneling applications.
> >
> >          This sounds like a move in the right direction.
> >
> > >For this particular draft my suggestion at this stage is
> > that the Bonica's
> > >requirement draft be revised to:
> > >
> > >1) Add text (or at least a place holder) for additional
> > security issues
> > >raised on the list.
> > >2) Add backward compatibility, simplicity and scalability as
> > requirements.
> >
> >          I can go along with those.
> >
> > >3) Remove the protocol requirements section, since any
> > requirement here
> > >will be viewed as a reverse engineering of some solution.
> >
> >          Although this might sound reasonable to some, I
> > think that some
> > may object to this
> > since the protocol requirements are viewed by some as
> > fundamental to the
> > requirements
> > of any particular solution.  In the flurry of emails on the
> > topic, I have
> > not been able to
> > keep track of what the consensus on this might be (either
> > way). Perhaps Ron
> > has been keeping
> > track?
> >
> > >Then any offered solution should have text to show to what
> > extent they
> > >fulfill the
> > >requirements, and what is their applicability and restrictions.
> >
> >          Sounds reasonable.
> >
> >          --Tom
> >
> >
> >
> >
> >
> >
> > --------------------------------------------------------------
> > ----------
> > Mathematics is the supreme nostalgia of our time.
> >

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Mon, 04 Mar 2002 14:25:07 -0800
From: "David Allan"<[email-masked]>
To: George Swallow <[email-masked]>
Cc: [email-masked]
Subject: RE: Y1711 applicability...was draft-bonica-tunneltrace-02 
Date: Mon, 4 Mar 2002 17:23:39 -0500 

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

------_=_NextPart_001_01C1C3CB.3BEFC030
Content-Type: text/plain;
	charset="iso-8859-1"

Hi George:

> Since the overwhelming majority of MPLS deployed today does not use
> explicit routing, this does seriously limit the applicability.

Limited applicability does not seem to manifest itself in a corresponding
lack of interest. The recovery framework and many drafts have proposed
various protection and reliability schemes that presupposed similar
functionality. There has been lots of focus on local protection schemes
(e.g. bypass tunnels in draft-swallow) that have similar limited
applicability. 

> Further for the explicitly routed p2p case we have a solution that
> leverages IP OAM.  
> 
Yup, and we've discussed the technical merits endlessly....

rgds
Dave

------_=_NextPart_001_01C1C3CB.3BEFC030
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Y1711 applicability...was draft-bonica-tunneltrace-02 =
</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi George:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Since the overwhelming majority of MPLS deployed =
today does not use</FONT>
<BR><FONT SIZE=3D2>&gt; explicit routing, this does seriously limit the =
applicability.</FONT>
</P>

<P><FONT SIZE=3D2>Limited applicability does not seem to manifest =
itself in a corresponding lack of interest. The recovery framework and =
many drafts have proposed various protection and reliability schemes =
that presupposed similar functionality. There has been lots of focus on =
local protection schemes (e.g. bypass tunnels in draft-swallow) that =
have similar limited applicability. </FONT></P>

<P><FONT SIZE=3D2>&gt; Further for the explicitly routed p2p case we =
have a solution that</FONT>
<BR><FONT SIZE=3D2>&gt; leverages IP OAM.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>Yup, and we've discussed the technical merits =
endlessly....</FONT>
</P>

<P><FONT SIZE=3D2>rgds</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C3CB.3BEFC030--

Envelope-to: [email-masked]
Delivery-date: Mon, 04 Mar 2002 14:09:09 -0800
Message-Id: <[email-masked]>
To: "David Allan" <[email-masked]>
cc: [email-masked]
Subject: Re: Y1711 applicability...was draft-bonica-tunneltrace-02 
Date: Mon, 04 Mar 2002 17:08:55 -0500
From: George Swallow <[email-masked]>

> Y.1711 simply provides some defect detection/handling tools that can be
> implemented on LERs for explicitly routed p2p LSPs regardless of payload,

Since the overwhelming majority of MPLS deployed today does not use
explicit routing, this does seriously limit the applicability.
Further for the explicitly routed p2p case we have a solution that
leverages IP OAM.  

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Mon, 04 Mar 2002 14:08:36 -0800
From: Shahram Davari <[email-masked]>
To: "'Thomas D. Nadeau'" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Mon, 4 Mar 2002 14:07:52 -0800 

Tom,

Thanks for your positive response. With regards to the protocol requirements, which ones do you think MUST be there and why? 

In my view protocol requirements should not unnecessarily restrict the solution, unless they violate application requirements.

-Shahram

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Monday, March 04, 2002 4:25 PM
> To: Shahram Davari
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> 
> >I think instead of debating whether Y.1711 is better than 
> LSP-ping/GTTP or 
> >vice versa, it would be more
> >constructive to identify and document the applicability of 
> each proposal 
> >for various tunneling applications.
> 
>          This sounds like a move in the right direction.
> 
> >For this particular draft my suggestion at this stage is 
> that the Bonica's 
> >requirement draft be revised to:
> >
> >1) Add text (or at least a place holder) for additional 
> security issues 
> >raised on the list.
> >2) Add backward compatibility, simplicity and scalability as 
> requirements.
> 
>          I can go along with those.
> 
> >3) Remove the protocol requirements section, since any 
> requirement here 
> >will be viewed as a reverse engineering of some solution.
> 
>          Although this might sound reasonable to some, I 
> think that some 
> may object to this
> since the protocol requirements are viewed by some as 
> fundamental to the 
> requirements
> of any particular solution.  In the flurry of emails on the 
> topic, I have 
> not been able to
> keep track of what the consensus on this might be (either 
> way). Perhaps Ron 
> has been keeping
> track?
> 
> >Then any offered solution should have text to show to what 
> extent they 
> >fulfill the
> >requirements, and what is their applicability and restrictions.
> 
>          Sounds reasonable.
> 
>          --Tom
> 
> 
> 
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 

Delivery-date: Mon, 04 Mar 2002 13:33:38 -0800
Date: Mon, 04 Mar 2002 16:25:24 -0500
To: Shahram Davari <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02 
Cc: [email-masked]

>I think instead of debating whether Y.1711 is better than LSP-ping/GTTP or 
>vice versa, it would be more
>constructive to identify and document the applicability of each proposal 
>for various tunneling applications.

         This sounds like a move in the right direction.

>For this particular draft my suggestion at this stage is that the Bonica's 
>requirement draft be revised to:
>
>1) Add text (or at least a place holder) for additional security issues 
>raised on the list.
>2) Add backward compatibility, simplicity and scalability as requirements.

         I can go along with those.

>3) Remove the protocol requirements section, since any requirement here 
>will be viewed as a reverse engineering of some solution.

         Although this might sound reasonable to some, I think that some 
may object to this
since the protocol requirements are viewed by some as fundamental to the 
requirements
of any particular solution.  In the flurry of emails on the topic, I have 
not been able to
keep track of what the consensus on this might be (either way). Perhaps Ron 
has been keeping
track?

>Then any offered solution should have text to show to what extent they 
>fulfill the
>requirements, and what is their applicability and restrictions.

         Sounds reasonable.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Mon, 04 Mar 2002 13:22:21 -0800
Date: Mon, 04 Mar 2002 16:09:48 -0500
To: "CCAMP" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: GMPLS Signaling Implementation Survey Form
Cc: "Yakov Rekhter" <[email-masked]>, [email-masked]

All,
         If you'd like to answer this anonymously, please send your results 
to Scott Bradner ([email-masked]).  He'll remove your identify / contact 
info and forward it along to be included in the survey.

Thanks,
Lou

PS To be included in the first draft of the survey, please have your forms 
in by COB March 13.

At 03:18 PM 3/1/2002, Berger, Lou wrote:

>All,
>
>If you'd like to participate in a GMPLS signaling implementation survey,
>please complete (as much as you can/want) and return the enclosed.  We will
>consolidate all answers and publish the results (to the list and as a draft.)
>
>Thank you,
>Lou (and Yakov)
>
>----------------------------------
>GMPLS Signaling Implementation Survey Form                          [V 1.0]
>
>     This is form is derived from V2.2 of the "RSVP and QoS Implementation
>     Survey Information Form" authored by Gene Gaines 
> <[email-masked]>
>     and Marco Festa <[email-masked]>.  See
> 
><http://www.iit.nrc.ca/IETF/RSVP_survey/rsvp-qos_quest_980210.txt>http://www.iit.nrc.ca/IETF/RSVP_survey/rsvp-qos_quest_980210.txt. 
>
>
>     This form is also available from
> 
><http://www.labn.net/gmpls/sig-survey.txt>http://www.labn.net/gmpls/sig-survey.txt 
>
>=======================================================================
>
>1.  Organization:
>
>1.1   Organization url(s):
>
>2.  Product title(s):
>
>2.1   Brief description(s):
>
>----------------------------------------------------------------
>
>3.  Contact for GMPLS information
>3.1   Name:
>
>3.2   Title:
>
>3.3   E-mail:
>
>3.4   Organization/department:
>
>3.5   Postal address:
>
>3.6   Phone:
>
>3.7   Fax:
>----------------------------------------------------------------
>
>4.  Status:
>4.1     [ ] Development
>4.2     [ ] Alpha
>4.3     [ ] Beta
>4.4     [ ] Product
>4.5     [ ] Other (describe):
>
>5.  Switching capabilities
>5.1     [ ] PSC
>5.2     [ ] TDM
>5.3     [ ] LSC
>5.4     [ ] FSC
>
>6. Reference Drafts (please list, include version numbers)
>6.1    [ ]
>6.2    [ ]
>6.3    [ ]
>6.4    [ ]
>6.5    [ ]
>6.6    [ ]
>
>7. Interface technologies
>7.1    [ ] Frame Relay
>7.2    [ ] ATM
>7.3    [ ] Ethernet V2/DIX
>7.4    [ ] Ethernet 802.3
>7.5    [ ] SDH
>7.6    [ ] SONET
>7.7    [ ] Lambda (photonic)
>7.8    [ ] Fiber
>7.9    [ ] FiberChannel
>7.10   [ ] Other (describe):
>
>8. Availability
>8.1    [ ] Public and free
>8.2    [ ] Only to selected organizations/companies but free
>8.3    [ ] On sale.
>8.4    [ ] For internal company use only
>8.5    [ ] Other:
>
>9. Implementation based on:  (check all that apply)
>9.1    [ ] Purchased code (please list source if possible)
>9.2    [ ] Free code (please list source if possible)
>9.3    [ ] Internal implementation (no outside code, just from specs)
>9.4    [ ] Internal implementation on top of purchased or free code
>9.4.1      [ ] List portions from external source
>9.4.2      [ ] List portions developed internally
>
>10.  Supported Label Types
>10.1  [ ] MPLS Label
>10.2  [ ] Generalized Label
>10.3  [ ] Waveband Label
>10.4  [ ] SONET/SDH Label
>
>11.  Label Related
>11.1  [ ] Suggested Label
>11.2  [ ] Label Set
>
>12.  Traffic Parameters
>12.1  [ ] Intserv (Please list which)
>12.2  [ ] CR-LDP
>12.3  [ ] GMPLS Bandwidth Encoding
>12.4  [ ] SONET/SDH
>
>13.   [ ] Bidirectional LSPs
>
>14.  Notification
>14.1 [ ] Acceptable Label Set
>14.2 [ ] Notify Request Objects (GMPLS-RSVP)
>14.3 [ ] Notify Message (GMPLS-RSVP)
>14.4 [ ] Removing State with a PathErr message (GMPLS-RSVP)
>
>15  Other features
>15.1  [ ] Explicit Label Control
>15.2  [ ] Protection Information
>15.3  [ ] Administrative Status Information
>15.4  [ ] Interface Identification
>15.5  [ ] Errored Interface Identification
>15.6  [ ] Link Fault Handling
>15.7  [ ] Nodal Fault Handling
>
>16. Other specification(s) which apply:
>
>17. Other features supported:
>
>18. Currently-defined GMPLS signaling features not supported:
>
>19. Notes (please describe purpose of project, give any information that
>        might be useful to those interested in developing or using GMPLS)
>
>20. If you feel the above categories are not complete, add others which
>        will better describe your project:
>
>=======================================================================
>
>Person filling out this form:
>
>       Name:
>
>       E-mail:
>
>       Tel.:
>
>       Title:
>
>       Company:
>
>       Date prepared:
>
>----------------------------------------------------------------
>
>Return your information to the authors:
>
>       Lou Berger <[email-masked]> or <[email-masked]> and
>       Yakov Rekhter <[email-masked]>
>
>       all returned information will be consolidated and reported
>       to the CCAMP WG mailing list.
>
>Thank you!
>
>Updated 03/01/02
>
>--end--
>

Delivery-date: Mon, 04 Mar 2002 13:20:25 -0800
From: Shahram Davari <[email-masked]>
To: "'Thomas D. Nadeau'" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Mon, 4 Mar 2002 13:18:03 -0800 

Tom,

I think instead of debating whether Y.1711 is better than LSP-ping/GTTP or vice versa, it would be more constructive to identify and document the applicability of each proposal for various tunneling applications.

For this particular draft my suggestion at this stage is that the Bonica's requirement draft be revised to:

1) Add text (or at least a place holder) for additional security issues raised on the list.
2) Add backward compatibility, simplicity and scalability as requirements.
3) Remove the protocol requirements section, since any requirement here will be viewed as a reverse engineering of some solution.
 
Then any offered solution should have text to show to what extent they fulfill the requirements, and what is their applicability and restrictions.

-Shahram 

> -----Original Message-----
> From: Shahram Davari 
> Sent: Monday, March 04, 2002 1:23 PM
> To: 'Thomas D. Nadeau'
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> Tom,
> 
> I see that you haven't answered all my questions, but I trust 
> that you will.
> Please see my comments in-line.
> 
> -Shahram
> 
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:[email-masked]]
> > Sent: Monday, March 04, 2002 12:57 PM
> > To: Shahram Davari
> > Cc: [email-masked]
> > Subject: RE: draft-bonica-tunneltrace-02 
> > 
> > 
> > 
> > > > I am hearing that people want to
> > > > use simpler approaches, even if they are not 
> > architecturally pure. Some 
> > > of these
> > > > approaches that are available today and won't double the cost
> > > >of a device because the OAM
> > > > functions are built on top of existing software, and
> > > > thus don't require an army of software and  hardware 
> > developers to realize.
> > >
> > >Interesting. So you actually beleive that MPLS OAM doubles 
> > the cost of 
> > >device!!!
> > 
> >          No. Don't misinterpret what I am saying. I think 
> > that YOUR approach
> > will significantly increase the cost of a device.
> 
> Ignoring your 2X price increase comment, why do you think there will
> be a significant increase in the cost of a device? 
> implementing a simple CV flow
> shouldn't be that expensive.
> 
>   There are 
> > other approaches
> > that leverage existing technologies that are already 
> > implemented. I think
> > the cost increase for these approaches is marginal in comparison.
> > 
> > > >          I do not think that Y.1711 presents good solutions
> > > > to the problem of
> > > > OAM.
> > >
> > >Why? The approach taken in Y.1711 is not new, it has been 
> around for
> > >many many years in other technologies and has proven to work fine.
> > 
> >          You are basically trying to meld ATM OAM technology
> > onto MPLS, which isn't an easy thing to do nor is it a good 
> fit, IMHO.
> 
> I think Y.1711 shows that it is easy to do, and actually fits well.
> What is the difference between ATM, FR, or any CO technology 
> and MPLS, and what
> makes the basic OAM technique used by those technologies a 
> bad fit for MPLS?
> 
> > 
> > > > I don't think I am out in left field on this one either.
> > > > So again, I propose that we work on practical solutions 
> > to the problem 
> > > of OAM
> > > > for MPLS.
> > >
> > >What do you mean by practical solution?
> > 
> >          A solution to that can be implemented in one's 
> > lifetime 
> 
> Again interesting comments. I read this as " Y.1711 is not 
> implementable in
> one's life time".!!!!!!!!
> 
> >and will not
> > significantly increase the cost of the device on which it is 
> > implemented.
> 
> You keep pointing to the significant cost. Could you please 
> clearly identify which parts of the MPLS OAM has significant 
> cost to implement compared to other approaches that you mentioned?
> 
> > Such solutions generally do not require a complete re-design
> > of all hardware that is deployed in the world and that 
> generally seem
> > to work pretty well at this point.
> 
> 1) MPLS OAM could be easily implemented in software.
> 2) If one chooses to implement some part of it in hardware, 
> then off course new hardware is needed.
> 
> 
> > 
> >          --Tom
> > 
> > 
> > 
> > 
> > --------------------------------------------------------------
> > ----------
> > Mathematics is the supreme nostalgia of our time. 
> > 
> 

Delivery-date: Mon, 04 Mar 2002 10:24:05 -0800
From: Shahram Davari <[email-masked]>
To: "'Thomas D. Nadeau'" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Mon, 4 Mar 2002 10:22:43 -0800 

Tom,

I see that you haven't answered all my questions, but I trust that you will.
Please see my comments in-line.

-Shahram

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Monday, March 04, 2002 12:57 PM
> To: Shahram Davari
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> 
> > > I am hearing that people want to
> > > use simpler approaches, even if they are not 
> architecturally pure. Some 
> > of these
> > > approaches that are available today and won't double the cost
> > >of a device because the OAM
> > > functions are built on top of existing software, and
> > > thus don't require an army of software and  hardware 
> developers to realize.
> >
> >Interesting. So you actually beleive that MPLS OAM doubles 
> the cost of 
> >device!!!
> 
>          No. Don't misinterpret what I am saying. I think 
> that YOUR approach
> will significantly increase the cost of a device.

Ignoring your 2X price increase comment, why do you think there will
be a significant increase in the cost of a device? implementing a simple CV flow
shouldn't be that expensive.

  There are 
> other approaches
> that leverage existing technologies that are already 
> implemented. I think
> the cost increase for these approaches is marginal in comparison.
> 
> > >          I do not think that Y.1711 presents good solutions
> > > to the problem of
> > > OAM.
> >
> >Why? The approach taken in Y.1711 is not new, it has been around for
> >many many years in other technologies and has proven to work fine.
> 
>          You are basically trying to meld ATM OAM technology
> onto MPLS, which isn't an easy thing to do nor is it a good fit, IMHO.

I think Y.1711 shows that it is easy to do, and actually fits well.
What is the difference between ATM, FR, or any CO technology and MPLS, and what
makes the basic OAM technique used by those technologies a bad fit for MPLS?

> 
> > > I don't think I am out in left field on this one either.
> > > So again, I propose that we work on practical solutions 
> to the problem 
> > of OAM
> > > for MPLS.
> >
> >What do you mean by practical solution?
> 
>          A solution to that can be implemented in one's 
> lifetime 

Again interesting comments. I read this as " Y.1711 is not implementable in
one's life time".!!!!!!!!

>and will not
> significantly increase the cost of the device on which it is 
> implemented.

You keep pointing to the significant cost. Could you please clearly identify which parts of the MPLS OAM has significant cost to implement compared to other approaches that you mentioned?

> Such solutions generally do not require a complete re-design
> of all hardware that is deployed in the world and that generally seem
> to work pretty well at this point.

1) MPLS OAM could be easily implemented in software.
2) If one chooses to implement some part of it in hardware, then off course new hardware is needed.

> 
>          --Tom
> 
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 

Delivery-date: Mon, 04 Mar 2002 09:58:07 -0800
Date: Mon, 04 Mar 2002 12:56:33 -0500
To: Shahram Davari <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02 
Cc: [email-masked]

> > I am hearing that people want to
> > use simpler approaches, even if they are not architecturally pure. Some 
> of these
> > approaches that are available today and won't double the cost
> >of a device because the OAM
> > functions are built on top of existing software, and
> > thus don't require an army of software and  hardware developers to realize.
>
>Interesting. So you actually beleive that MPLS OAM doubles the cost of 
>device!!!

         No. Don't misinterpret what I am saying. I think that YOUR approach
will significantly increase the cost of a device.  There are other approaches
that leverage existing technologies that are already implemented. I think
the cost increase for these approaches is marginal in comparison.

> >          I do not think that Y.1711 presents good solutions
> > to the problem of
> > OAM.
>
>Why? The approach taken in Y.1711 is not new, it has been around for
>many many years in other technologies and has proven to work fine.

         You are basically trying to meld ATM OAM technology
onto MPLS, which isn't an easy thing to do nor is it a good fit, IMHO.

> > I don't think I am out in left field on this one either.
> > So again, I propose that we work on practical solutions to the problem 
> of OAM
> > for MPLS.
>
>What do you mean by practical solution?

         A solution to that can be implemented in one's lifetime and will not
significantly increase the cost of the device on which it is implemented.
Such solutions generally do not require a complete re-design
of all hardware that is deployed in the world and that generally seem
to work pretty well at this point.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Mon, 04 Mar 2002 09:14:38 -0800
Date: Mon, 04 Mar 2002 18:13:54 +0100
To: Kireeti Kompella <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: CCAMP Protection/Restoration Design Team
Cc: [email-masked]

Hi Kireeti,

At 18:25 24/02/2002 -0800, Kireeti Kompella wrote:
>Hi Folks,
>
>I'd like to thank all of you who volunteered for this work.  To keep
>the team small and effective, not everyone who volunteered could
>participate directly.  Note that you can (and should) participate
>through the CCAMP WG, by giving suggestions/feedback to the DT, and,
>if deemed necessary, by proposing alternate documents.
>
>Finally, note that the design team is _just another set of authors_.
>The document(s) they produce are subject to WG consensus to progress
>to WG documents and beyond.
>
>Here's the Protection/Restoration Design Team.  They have been on
>the job for a little over a month now.
>
>Deborah Brungard
>Sudheer Dharanikota
>Jonathan Lang
>Guangzhi Li
>Eric Mannie
>Dimitri Papadimitriou
>Bala Rajagopalan
>Yakov Rekhter
>
>Sudheer is the team lead.
>
>Their charter ("you" in what follows refers to the DT):
>
>a) read drafts re protection/restoration in CCAMP, IPO and MPLS.
>    These include (but are not limited to :-)):
>
>******* draft-ietf-tewg-restore-hierarchy-00.txt *******

+ draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt.

Thanks.

JP.

>         draft-bala-protection-restoration-signaling-00.txt
>         draft-bala-restoration-signaling-01.txt
>         draft-ietf-ipo-carrier-requirements-00.txt (Section 10)
>         draft-kini-restoration-shared-backup-01.txt
>         draft-li-shared-mesh-restoration-01.txt
>         draft-many-optical-restoration-01.txt
>         draft-suemura-protection-hierarchy-00.txt
>         draft-ylee-protection-occ-00.txt
>         -----------------------------------------------------
>         draft-atlas-rsvp-local-protect-interop-02.txt
>         draft-chang-mpls-path-protection-03.txt
>         draft-chang-mpls-rsvpte-path-protection-ext-02.txt
>         draft-owens-crldp-path-protection-ext-01.txt
>
>    The first draft is the requirements for Protection & Restoration
>    produced by the TEWG Design Team.  Functionality that you come up
>    with should satisfy these requirements; stuff that you come up
>    with that either goes beyond these requirements or doesn't meet
>    some of them should be called out so that we can re-evaluate.
>
>    The drafts below the line may be MPLS-specific, so they may or may
>    not apply.
>
>| AD's comment: For the first round... please refrain as much as possible
>| from going beyond the requirements specified in the first draft.  That
>| document restricted itself (on purpose) to requirements that are felt
>| to be realistic for real operators and in the reasonably short term.
>| So that is the scope you should be working in.
>
>b) produce a terminology document, preferably using ITU-T terminology,
>    but having a decoder ring to translate to terminology in current
>    drafts as well as the TE WG document
>c) produce an interim analysis document, comparing and contrasting
>    approaches (i.e., the above drafts, published and ongoing work
>    at the ITU/T1-X1/...)
>
>| AD's comment: And be careful. Leave the ITU and T1X1-... etc work in
>| those organisations if that is where it belongs (and often it does)!
>
>d) produce a more complete version of (c)
>e) produce a functional spec delineating
>    o What's in scope, out of scope, what's for future study, which of
>      the TEWG reqts have been met, which not, and what goes beyond.
>    o Overall approach
>    o Objects/procedures/... needed in a protocol-independent fashion
>f) produce a document detailing the changes for RSVP-TE and CR-LDP
>g) produce a document detailing the changes for OSFP-TE and IS-IS-TE
>
>The timeline for (a-c) is before the next IETF (March 1, 2002).
>
>A first cut of (d) and (e) should be available by end of April, 2002.
>If there is rough consensus in the CCAMP WG for the approach in (e),
>work should then start on (f) and (g).
>
>Kireeti.

Delivery-date: Mon, 04 Mar 2002 09:04:03 -0800
From: Shahram Davari <[email-masked]>
To: "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Mon, 4 Mar 2002 08:59:22 -0800 

Tom,

>          Lets not misrepresent the facts again. There are 
> lots of equipment 
> vendors
> who think that there are alternative ways of achieving defect 
> detection/repair using
> simpler,

Simpler and scalable such as GTTP?!!!!!!!!!! very interesting?

> more practical mechanisms. These same vendors and 
> operators alike
> spoke out at the OAM BOF against your grand architecture of 
> OAM for this
> reason.

To my knowledge only 3 opertors spoke against, which one of them
does not exist any more (bankrupted). That leaves us with 2 operators against
and 6 opertors for MPLS OAM!!!!!!!!!! 

>  I have also been told this numerous times by 
> operational carrier
> types privately as well.
> 
> > > Please don't just refer us again to your OAM draft,
> > > because I think  it is clear that is a non-starter.
> >NH=> Why is this.....and are you speaking on behalf of 
> yourself, Cisco or
> >the IETF?
> 
>          People at the IETF speak for themselves.  Read the 
> IETF guidelines
> if you are unclear on this.
> 
> >By saying this you are also stating that you also don't
> >value/respect the fact that these requirements are supported by the
> >following carriers AT&T, SBC, NTT, DT, Sprint, BT (+ a list of
> >manafuacturers, who are prepared it seems to meet these 
> requirements).
> >You offer no rationale for this statement.......so I can 
> only assume you (or
> >your company) disagree with these carrier's  requirements.
> 
>          I always value the input of carriers, and specifically weigh 
> heavily the input
> from their operational  organizations (versus marketing or 
> research). I 
> learned this
> lesson a long time ago. It is what drives what I do every day. Crrier 
> representatives
> who are on the operational side of their organizations have 
> expressed concern
> publicly and to me privately over these requirements and the 
> approaches 
> proposed
> to solve them in Y.1711.

Could you please name those carriers and their rational?

> I am hearing that people want to 
> use simpler 
> approaches,
> even if they are not architecturally pure. Some of these 
> approaches that 
> are available
> today and won't double the cost
>of a device because the OAM 
> functions are 
> built
> on top of existing software, and thus don't require an army 
> of software and 
> hardware
> developers to realize.

Interesting. So you actually beleive that MPLS OAM doubles the cost of device!!!

> 
>          I really think that operators and vendors want to 
> eat OAM pudding,
> not just talk about what color and shape it is. I just think 
> if we try to 
> build the
> pudding described in Y.1711, that we will all starve

Why?

> 
> > >  If there are still holes after this exercise, lets work together
> > > on these problems and find efficient and solvable solutions
> > > to them. This may not result
> > > in an architectural correct over-all grand reference,
> >NH=> Let me paraphrase what you are saying here:
> >-       I assume this remark is suggesting that the 
> requirements given in
> >draft-harrison-mpls-oam-req-01.txt (and also in Y.1710) is 
> not really what
> >carriers want, even though they are asking for them, and 
> that Y.1711 is not
> >a good solution....
> 
>          I do not think that Y.1711 presents good solutions 
> to the problem of
> OAM.

Why? The approach taken in Y.1711 is not new, it has been around for
many many years in other technologies and has proven to work fine.

> I don't think I am out in left field on this one either. 
> So again, I
> propose that we work on practical solutions to the problem of OAM
> for MPLS.

What do you mean by practical solution? 

-Shahram

> 
>          --Tom
> 
> 
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 
> 

Delivery-date: Mon, 04 Mar 2002 07:52:29 -0800
From: "David Allan"<[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: re: Y1711 applicability...was draft-bonica-tunneltrace-02
Date: Mon, 4 Mar 2002 10:45:38 -0500 

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

------_=_NextPart_001_01C1C393.A1D0F780
Content-Type: text/plain;
	charset="iso-8859-1"

Neil/Tom:

Somthing that is missing from this discussion is an appreciation of the
applicability of, limitations of..and deployment scenarios for Y.1711. It is
not a panacea, nor is it a product of some networking "axis of evil".

Y.1711 simply provides some defect detection/handling tools that can be
implemented on LERs for explicitly routed p2p LSPs regardless of payload,
and defines a framework and criteria for doing availability measurement with
the same tools. When used in this fashion, it can be overlaid on an existing
network and would work just fine as there are no dependencies on the
intermediate LSRs. There are no backward compatibility issues, and the
mechanism itself is quite lightweight, suggesting simple H/W assisted
implementation on the edge devices. It's not hard to imagine all the places
it could be used, as well as the places where it would add no value.

As such I'm not sure why folks are labelling this as a non-starter,
similarly I'm also seeing preliminary marketing literature suggesting that
by the mere existence of OAM as a topic means the problems have been solved.
IMHO neither is true.

What I got out of the BOF last December (and subsequent e-mail blizzard) is
that there are some operators and some vendors who don't think an MPLS
specific approach is useful and a similar camp who do (and we're all quite
passionate about it).

Seems to me that if you examine the facts, there is room for both camps to
co-exist.

cheers
Dave  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, March 03, 2002 6:24 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> Tom,
> 
> You keep making assertions like like 'grand architecture' and 
> stating a need
> for 'simpler solutions' but you offer no quantification of 
> such, and seem
> quite happy to shift the defect detection/handling 
> problems/costs towards
> the operator.  
> 
> To break the deadlock, let me ask you to answer a simple question:
> 
> -	The CV pkt is a simple 'keepalive' in the data-plane 
> carrying the
> LSP source address......many protocols use such a device, 
> this one just
> happens to look after the customer traffic (you know, the 
> stuff that earns
> carrier's money?).  This is about it complexity-wise as regards defect
> detection.  The only other things defined are an FDI pkt 
> (forward) and BDI
> pkt (backward) notifications which only appear after a defect 
> is detected.
> I think we would all therefore benefit if you can please 
> quantify why this
> single CV pkt is so complex as you keep asserting....esp given all the
> 'grand arch' benefits it brings?   We await your comparative technical
> analysis and costings for review.
> 
> regards, Neil
> 
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:[email-masked]]
> > Sent: 03 March 2002 18:30
> > To: neil.2.harrison
> > Cc: [email-masked]
> > Subject: RE: draft-bonica-tunneltrace-02 
> > 
> > 
> > 
> >          Neil,
> > 
> >          I am very glad that you have taken the time to reply to my
> > response. Regards Tom.
> > 
> > >Hi Tom...I am very glad you raised these points....please see my
> > >observations on them.  regards Neil
> > >
> > ><snip>
> > > > Achitectural correctness is bunk if it
> > > > does not leads to
> > > > implementations that cannot support the architecture in such
> > > > a way as to a) be
> > > > implemented in one's lifetime,
> > >NH=> I wholeheartedly agree with this......and for as long 
> > as I can remember
> > >management-plane X-I/Fs have been promised but never materialised.
> > 
> >          Again you misstate the facts. Management IFs exist 
> > today: SNMP,
> > LSP ping, etc...
> > 
> > >However,
> > >wrt to the topic here I am already aware of trial 
> > implementations by certain
> > >vendors and Shahram Davari has been involved since very 
> early on....
> > >and since his company cuts the silicon many then use then 
> > this tells me it 
> > >can't
> > >be be too complex.  Maybe this is just a problem for your 
> > company?....a
> > >quick look-see at who has problems seems to indicate Cisco 
> > figures largely
> > >here in a class of 1.
> > 
> >          Lets not misrepresent the facts again. There are 
> > lots of equipment 
> > vendors
> > who think that there are alternative ways of achieving defect 
> > detection/repair using
> > simpler, more practical mechanisms. These same vendors and 
> > operators alike
> > spoke out at the OAM BOF against your grand architecture of 
> > OAM for this
> > reason.  I have also been told this numerous times by 
> > operational carrier
> > types privately as well.
> > 
> > > > Please don't just refer us again to your OAM draft,
> > > > because I think  it is clear that is a non-starter.
> > >NH=> Why is this.....and are you speaking on behalf of 
> > yourself, Cisco or
> > >the IETF?
> > 
> >          People at the IETF speak for themselves.  Read the 
> > IETF guidelines
> > if you are unclear on this.
> > 
> > >By saying this you are also stating that you also don't
> > >value/respect the fact that these requirements are supported by the
> > >following carriers AT&T, SBC, NTT, DT, Sprint, BT (+ a list of
> > >manafuacturers, who are prepared it seems to meet these 
> > requirements).
> > >You offer no rationale for this statement.......so I can 
> > only assume you (or
> > >your company) disagree with these carrier's  requirements.
> > 
> >          I always value the input of carriers, and 
> specifically weigh 
> > heavily the input
> > from their operational  organizations (versus marketing or 
> > research). I 
> > learned this
> > lesson a long time ago. It is what drives what I do every 
> day. Crrier 
> > representatives
> > who are on the operational side of their organizations have 
> > expressed concern
> > publicly and to me privately over these requirements and the 
> > approaches 
> > proposed
> > to solve them in Y.1711.  I am hearing that people want to 
> > use simpler 
> > approaches,
> > even if they are not architecturally pure. Some of these 
> > approaches that 
> > are available
> > today and won't double the cost of a device because the OAM 
> > functions are 
> > built
> > on top of existing software, and thus don't require an army 
> > of software and 
> > hardware
> > developers to realize.
> > 
> >          I really think that operators and vendors want to 
> > eat OAM pudding,
> > not just talk about what color and shape it is. I just think 
> > if we try to 
> > build the
> > pudding described in Y.1711, that we will all starve
> > 
> > > >  If there are still holes after this exercise, lets 
> work together
> > > > on these problems and find efficient and solvable solutions
> > > > to them. This may not result
> > > > in an architectural correct over-all grand reference,
> > >NH=> Let me paraphrase what you are saying here:
> > >-       I assume this remark is suggesting that the 
> > requirements given in
> > >draft-harrison-mpls-oam-req-01.txt (and also in Y.1710) is 
> > not really what
> > >carriers want, even though they are asking for them, and 
> > that Y.1711 is not
> > >a good solution....
> > 
> >          I do not think that Y.1711 presents good solutions 
> > to the problem of
> > OAM. I don't think I am out in left field on this one either. 
> > So again, I
> > propose that we work on practical solutions to the problem of OAM
> > for MPLS.
> > 
> >          --Tom
> > 
> > 
> > 
> > 
> > 
> > --------------------------------------------------------------
> > ----------
> > Mathematics is the supreme nostalgia of our time. 
> > 
> 
> 

------_=_NextPart_001_01C1C393.A1D0F780
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>re: Y1711 applicability...was =
draft-bonica-tunneltrace-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Neil/Tom:</FONT>
</P>

<P><FONT SIZE=3D2>Somthing that is missing from this discussion is an =
appreciation of the applicability of, limitations of..and deployment =
scenarios for Y.1711. It is not a panacea, nor is it a product of some =
networking &quot;axis of evil&quot;.</FONT></P>

<P><FONT SIZE=3D2>Y.1711 simply provides some defect detection/handling =
tools that can be implemented on LERs for explicitly routed p2p LSPs =
regardless of payload, and defines a framework and criteria for doing =
availability measurement with the same tools. When used in this =
fashion, it can be overlaid on an existing network and would work just =
fine as there are no dependencies on the intermediate LSRs. There are =
no backward compatibility issues, and the mechanism itself is quite =
lightweight, suggesting simple H/W assisted implementation on the edge =
devices. It's not hard to imagine all the places it could be used, as =
well as the places where it would add no value.</FONT></P>

<P><FONT SIZE=3D2>As such I'm not sure why folks are labelling this as =
a non-starter, similarly I'm also seeing preliminary marketing =
literature suggesting that by the mere existence of OAM as a topic =
means the problems have been solved. IMHO neither is true.</FONT></P>

<P><FONT SIZE=3D2>What I got out of the BOF last December (and =
subsequent e-mail blizzard) is that there are some operators and some =
vendors who don't think an MPLS specific approach is useful and a =
similar camp who do (and we're all quite passionate about =
it).</FONT></P>

<P><FONT SIZE=3D2>Seems to me that if you examine the facts, there is =
room for both camps to co-exist.</FONT>
</P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Sunday, March 03, 2002 6:24 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: draft-bonica-tunneltrace-02 =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Tom,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; You keep making assertions like like 'grand =
architecture' and </FONT>
<BR><FONT SIZE=3D2>&gt; stating a need</FONT>
<BR><FONT SIZE=3D2>&gt; for 'simpler solutions' but you offer no =
quantification of </FONT>
<BR><FONT SIZE=3D2>&gt; such, and seem</FONT>
<BR><FONT SIZE=3D2>&gt; quite happy to shift the defect =
detection/handling </FONT>
<BR><FONT SIZE=3D2>&gt; problems/costs towards</FONT>
<BR><FONT SIZE=3D2>&gt; the operator.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To break the deadlock, let me ask you to answer =
a simple question:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -&nbsp;&nbsp;&nbsp;&nbsp; The CV pkt is a =
simple 'keepalive' in the data-plane </FONT>
<BR><FONT SIZE=3D2>&gt; carrying the</FONT>
<BR><FONT SIZE=3D2>&gt; LSP source address......many protocols use such =
a device, </FONT>
<BR><FONT SIZE=3D2>&gt; this one just</FONT>
<BR><FONT SIZE=3D2>&gt; happens to look after the customer traffic (you =
know, the </FONT>
<BR><FONT SIZE=3D2>&gt; stuff that earns</FONT>
<BR><FONT SIZE=3D2>&gt; carrier's money?).&nbsp; This is about it =
complexity-wise as regards defect</FONT>
<BR><FONT SIZE=3D2>&gt; detection.&nbsp; The only other things defined =
are an FDI pkt </FONT>
<BR><FONT SIZE=3D2>&gt; (forward) and BDI</FONT>
<BR><FONT SIZE=3D2>&gt; pkt (backward) notifications which only appear =
after a defect </FONT>
<BR><FONT SIZE=3D2>&gt; is detected.</FONT>
<BR><FONT SIZE=3D2>&gt; I think we would all therefore benefit if you =
can please </FONT>
<BR><FONT SIZE=3D2>&gt; quantify why this</FONT>
<BR><FONT SIZE=3D2>&gt; single CV pkt is so complex as you keep =
asserting....esp given all the</FONT>
<BR><FONT SIZE=3D2>&gt; 'grand arch' benefits it brings?&nbsp;&nbsp; We =
await your comparative technical</FONT>
<BR><FONT SIZE=3D2>&gt; analysis and costings for review.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; regards, Neil</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Thomas D. Nadeau [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: 03 March 2002 18:30</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: neil.2.harrison</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: draft-bonica-tunneltrace-02 =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Neil,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I am very =
glad that you have taken the time to reply to my</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; response. Regards Tom.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Hi Tom...I am very glad you raised =
these points....please see my</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;observations on them.&nbsp; regards =
Neil</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&lt;snip&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Achitectural correctness is bunk =
if it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; does not leads to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; implementations that cannot =
support the architecture in such</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; a way as to a) be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; implemented in one's =
lifetime,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;NH=3D&gt; I wholeheartedly agree with =
this......and for as long </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; as I can remember</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;management-plane X-I/Fs have been =
promised but never materialised.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Again you =
misstate the facts. Management IFs exist </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; today: SNMP,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; LSP ping, etc...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;However,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;wrt to the topic here I am already =
aware of trial </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; implementations by certain</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;vendors and Shahram Davari has been =
involved since very </FONT>
<BR><FONT SIZE=3D2>&gt; early on....</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;and since his company cuts the silicon =
many then use then </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this tells me it </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;can't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;be be too complex.&nbsp; Maybe this is =
just a problem for your </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; company?....a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;quick look-see at who has problems =
seems to indicate Cisco </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; figures largely</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;here in a class of 1.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Lets not =
misrepresent the facts again. There are </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; lots of equipment </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; vendors</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; who think that there are alternative ways =
of achieving defect </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; detection/repair using</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; simpler, more practical mechanisms. These =
same vendors and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; operators alike</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; spoke out at the OAM BOF against your =
grand architecture of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; OAM for this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; reason.&nbsp; I have also been told this =
numerous times by </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; operational carrier</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; types privately as well.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Please don't just refer us again =
to your OAM draft,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; because I think&nbsp; it is =
clear that is a non-starter.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;NH=3D&gt; Why is this.....and are you =
speaking on behalf of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; yourself, Cisco or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;the IETF?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; People at =
the IETF speak for themselves.&nbsp; Read the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; IETF guidelines</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; if you are unclear on this.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;By saying this you are also stating =
that you also don't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;value/respect the fact that these =
requirements are supported by the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;following carriers AT&amp;T, SBC, NTT, =
DT, Sprint, BT (+ a list of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;manafuacturers, who are prepared it =
seems to meet these </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirements).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;You offer no rationale for this =
statement.......so I can </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; only assume you (or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;your company) disagree with these =
carrier's&nbsp; requirements.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I always =
value the input of carriers, and </FONT>
<BR><FONT SIZE=3D2>&gt; specifically weigh </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; heavily the input</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; from their operational&nbsp; organizations =
(versus marketing or </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; research). I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; learned this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; lesson a long time ago. It is what drives =
what I do every </FONT>
<BR><FONT SIZE=3D2>&gt; day. Crrier </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; representatives</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; who are on the operational side of their =
organizations have </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; expressed concern</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; publicly and to me privately over these =
requirements and the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; approaches </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; proposed</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to solve them in Y.1711.&nbsp; I am =
hearing that people want to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; use simpler </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; approaches,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; even if they are not architecturally pure. =
Some of these </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; approaches that </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; are available</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; today and won't double the cost of a =
device because the OAM </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; functions are </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; built</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; on top of existing software, and thus =
don't require an army </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of software and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; hardware</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; developers to realize.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I really =
think that operators and vendors want to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; eat OAM pudding,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; not just talk about what color and shape =
it is. I just think </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; if we try to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; build the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; pudding described in Y.1711, that we will =
all starve</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&nbsp; If there are still holes =
after this exercise, lets </FONT>
<BR><FONT SIZE=3D2>&gt; work together</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; on these problems and find =
efficient and solvable solutions</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; to them. This may not =
result</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; in an architectural correct =
over-all grand reference,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;NH=3D&gt; Let me paraphrase what you =
are saying here:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I assume this remark is suggesting that the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirements given in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;draft-harrison-mpls-oam-req-01.txt =
(and also in Y.1710) is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; not really what</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;carriers want, even though they are =
asking for them, and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that Y.1711 is not</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;a good solution....</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I do not =
think that Y.1711 presents good solutions </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to the problem of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; OAM. I don't think I am out in left field =
on this one either. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; So again, I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; propose that we work on practical =
solutions to the problem of OAM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; for MPLS.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --Tom</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ----------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Mathematics is the supreme nostalgia of =
our time. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C393.A1D0F780--

Delivery-date: Mon, 04 Mar 2002 04:06:58 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt
Date: Mon, 04 Mar 2002 07:06:39 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: OSPF Extensions to Support Multi-Area Traffic 
                          Engineering
	Author(s)	: D. Cheng
	Filename	: draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt
	Pages		: 6
	Date		: 01-Mar-02
	
The [MULTI-AREA] introduces a set of mechanisms that could be used
to construct LSPs that span multiple IS-IS/OSPF areas, where one 
scenario is to allow the head-end LSR to compute the path all the
way to the ABR in the tail-end area. This document proposes some
new OSPF extensions that can be used in supporting that scenario,
i.e., by leaking some of the useful information from individual 
areas to others, the constraint-based routing at the head-end LSR
of LSPs in OSPF networks with multiple areas can be optimized.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-00.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-cheng-ccamp-ospf-multiarea-te-extensions-00.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-cheng-ccamp-ospf-multiarea-te-extensions-00.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-cheng-ccamp-ospf-multiarea-te-extensions-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 04 Mar 2002 04:06:50 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-imajuku-ml-routing-01.txt
Date: Mon, 04 Mar 2002 07:06:30 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Multi-layer routing using multiple-layer switch 
                          capable LSRs
	Author(s)	: W. Imajuku et al.
	Filename	: draft-imajuku-ml-routing-01.txt
	Pages		: 9
	Date		: 01-Mar-02
	
The integration of multi-layer switching capabilities within one 
box, such as the packet-switch capability (PSC) and the lambda-
switch capability (LSC) under MPLS/Generalized-MPLS control mechanism,
paves the way for realizing network resource optimization 
with consideration of multi-layer routing. This document clarifies 
the model of the GMPLS-controlled integrated PSC/LSC label switch 
router (LSR) and discusses the requirements of the routing extensions 
needed to realize optimized multi-layer traffic 
engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-imajuku-ml-routing-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-imajuku-ml-routing-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-imajuku-ml-routing-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-imajuku-ml-routing-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-imajuku-ml-routing-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 04 Mar 2002 04:05:25 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-mib-01.txt
Date: Mon, 04 Mar 2002 07:04:17 -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		: Link Management Protocol Management Information Base
	Author(s)	: M. Dubuc et al.
	Filename	: draft-ietf-ccamp-lmp-mib-01.txt
	Pages		: 70
	Date		: 01-Mar-02
	
This memo defines an experimental portion of the Management Informa-
tion Base (MIB) for use with network management protocols in the
Internet community. In particular, it describes managed objects for
modeling the Link Management Protocol (LMP) [LMP].

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-01.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 04 Mar 2002 04:05:22 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-sdhsonet-control-00.txt
Date: Mon, 04 Mar 2002 07:04:13 -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		: Framework for GMPLS-based Control of SDH/SONET 
                          Networks
	Author(s)	: G. Bernstein et al.
	Filename	: draft-ietf-ccamp-sdhsonet-control-00.txt
	Pages		: 26
	Date		: 01-Mar-02
	
The suite of protocols that defines Multi-Protocol Label Switching 
(MPLS) is in the process of enhancement to generalize its 
applicability to the control of non-packet based switching, that is, 
optical switching.  One area of prime consideration is to use these 
generalized MPLS (GMPLS) protocols in upgrading the control plane of 
optical transport networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-sdhsonet-control-00.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-sdhsonet-control-00.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-sdhsonet-control-00.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-sdhsonet-control-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-sdhsonet-control-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 04 Mar 2002 02:18:45 -0800
From: [email-masked]
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
To: [email-masked]
Date: Mon, 4 Mar 2002 11:17:24 +0100

2)

"Wijnen, Bert (Bert)" wrote:

> CCAMP WG members,
>
> before we start down another many 100s of emails re-discussing
> the same topic....
>
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
>
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
> Thanks
> Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

Delivery-date: Sun, 03 Mar 2002 22:52:00 -0800
From: Hug Werner <[email-masked]>
To: "Wijnen Bert (Bert)" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Mon, 4 Mar 2002 07:45:50 +0100 

My vote is for (2).

Werner

"Wijnen, Bert (Bert)" wrote:

> CCAMP WG members,
>
> before we start down another many 100s of emails re-discussing
> the same topic....
>
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
>
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
> Thanks
> Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

Delivery-date: Sun, 03 Mar 2002 15:29:53 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Sun, 3 Mar 2002 23:24:16 -0000 

Tom,

You keep making assertions like like 'grand architecture' and stating a need
for 'simpler solutions' but you offer no quantification of such, and seem
quite happy to shift the defect detection/handling problems/costs towards
the operator.  

To break the deadlock, let me ask you to answer a simple question:

-	The CV pkt is a simple 'keepalive' in the data-plane carrying the
LSP source address......many protocols use such a device, this one just
happens to look after the customer traffic (you know, the stuff that earns
carrier's money?).  This is about it complexity-wise as regards defect
detection.  The only other things defined are an FDI pkt (forward) and BDI
pkt (backward) notifications which only appear after a defect is detected.
I think we would all therefore benefit if you can please quantify why this
single CV pkt is so complex as you keep asserting....esp given all the
'grand arch' benefits it brings?   We await your comparative technical
analysis and costings for review.

regards, Neil

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: 03 March 2002 18:30
> To: neil.2.harrison
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> 
>          Neil,
> 
>          I am very glad that you have taken the time to reply to my
> response. Regards Tom.
> 
> >Hi Tom...I am very glad you raised these points....please see my
> >observations on them.  regards Neil
> >
> ><snip>
> > > Achitectural correctness is bunk if it
> > > does not leads to
> > > implementations that cannot support the architecture in such
> > > a way as to a) be
> > > implemented in one's lifetime,
> >NH=> I wholeheartedly agree with this......and for as long 
> as I can remember
> >management-plane X-I/Fs have been promised but never materialised.
> 
>          Again you misstate the facts. Management IFs exist 
> today: SNMP,
> LSP ping, etc...
> 
> >However,
> >wrt to the topic here I am already aware of trial 
> implementations by certain
> >vendors and Shahram Davari has been involved since very early on....
> >and since his company cuts the silicon many then use then 
> this tells me it 
> >can't
> >be be too complex.  Maybe this is just a problem for your 
> company?....a
> >quick look-see at who has problems seems to indicate Cisco 
> figures largely
> >here in a class of 1.
> 
>          Lets not misrepresent the facts again. There are 
> lots of equipment 
> vendors
> who think that there are alternative ways of achieving defect 
> detection/repair using
> simpler, more practical mechanisms. These same vendors and 
> operators alike
> spoke out at the OAM BOF against your grand architecture of 
> OAM for this
> reason.  I have also been told this numerous times by 
> operational carrier
> types privately as well.
> 
> > > Please don't just refer us again to your OAM draft,
> > > because I think  it is clear that is a non-starter.
> >NH=> Why is this.....and are you speaking on behalf of 
> yourself, Cisco or
> >the IETF?
> 
>          People at the IETF speak for themselves.  Read the 
> IETF guidelines
> if you are unclear on this.
> 
> >By saying this you are also stating that you also don't
> >value/respect the fact that these requirements are supported by the
> >following carriers AT&T, SBC, NTT, DT, Sprint, BT (+ a list of
> >manafuacturers, who are prepared it seems to meet these 
> requirements).
> >You offer no rationale for this statement.......so I can 
> only assume you (or
> >your company) disagree with these carrier's  requirements.
> 
>          I always value the input of carriers, and specifically weigh 
> heavily the input
> from their operational  organizations (versus marketing or 
> research). I 
> learned this
> lesson a long time ago. It is what drives what I do every day. Crrier 
> representatives
> who are on the operational side of their organizations have 
> expressed concern
> publicly and to me privately over these requirements and the 
> approaches 
> proposed
> to solve them in Y.1711.  I am hearing that people want to 
> use simpler 
> approaches,
> even if they are not architecturally pure. Some of these 
> approaches that 
> are available
> today and won't double the cost of a device because the OAM 
> functions are 
> built
> on top of existing software, and thus don't require an army 
> of software and 
> hardware
> developers to realize.
> 
>          I really think that operators and vendors want to 
> eat OAM pudding,
> not just talk about what color and shape it is. I just think 
> if we try to 
> build the
> pudding described in Y.1711, that we will all starve
> 
> > >  If there are still holes after this exercise, lets work together
> > > on these problems and find efficient and solvable solutions
> > > to them. This may not result
> > > in an architectural correct over-all grand reference,
> >NH=> Let me paraphrase what you are saying here:
> >-       I assume this remark is suggesting that the 
> requirements given in
> >draft-harrison-mpls-oam-req-01.txt (and also in Y.1710) is 
> not really what
> >carriers want, even though they are asking for them, and 
> that Y.1711 is not
> >a good solution....
> 
>          I do not think that Y.1711 presents good solutions 
> to the problem of
> OAM. I don't think I am out in left field on this one either. 
> So again, I
> propose that we work on practical solutions to the problem of OAM
> for MPLS.
> 
>          --Tom
> 
> 
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 

Delivery-date: Sun, 03 Mar 2002 13:16:21 -0800
Date: Sun, 03 Mar 2002 13:30:03 -0500
To: <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02 
Cc: [email-masked]

         Neil,

         I am very glad that you have taken the time to reply to my
response. Regards Tom.

>Hi Tom...I am very glad you raised these points....please see my
>observations on them.  regards Neil
>
><snip>
> > Achitectural correctness is bunk if it
> > does not leads to
> > implementations that cannot support the architecture in such
> > a way as to a) be
> > implemented in one's lifetime,
>NH=> I wholeheartedly agree with this......and for as long as I can remember
>management-plane X-I/Fs have been promised but never materialised.

         Again you misstate the facts. Management IFs exist today: SNMP,
LSP ping, etc...

>However,
>wrt to the topic here I am already aware of trial implementations by certain
>vendors and Shahram Davari has been involved since very early on....
>and since his company cuts the silicon many then use then this tells me it 
>can't
>be be too complex.  Maybe this is just a problem for your company?....a
>quick look-see at who has problems seems to indicate Cisco figures largely
>here in a class of 1.

         Lets not misrepresent the facts again. There are lots of equipment 
vendors
who think that there are alternative ways of achieving defect 
detection/repair using
simpler, more practical mechanisms. These same vendors and operators alike
spoke out at the OAM BOF against your grand architecture of OAM for this
reason.  I have also been told this numerous times by operational carrier
types privately as well.

> > Please don't just refer us again to your OAM draft,
> > because I think  it is clear that is a non-starter.
>NH=> Why is this.....and are you speaking on behalf of yourself, Cisco or
>the IETF?

         People at the IETF speak for themselves.  Read the IETF guidelines
if you are unclear on this.

>By saying this you are also stating that you also don't
>value/respect the fact that these requirements are supported by the
>following carriers AT&T, SBC, NTT, DT, Sprint, BT (+ a list of
>manafuacturers, who are prepared it seems to meet these requirements).
>You offer no rationale for this statement.......so I can only assume you (or
>your company) disagree with these carrier's  requirements.

         I always value the input of carriers, and specifically weigh 
heavily the input
from their operational  organizations (versus marketing or research). I 
learned this
lesson a long time ago. It is what drives what I do every day. Crrier 
representatives
who are on the operational side of their organizations have expressed concern
publicly and to me privately over these requirements and the approaches 
proposed
to solve them in Y.1711.  I am hearing that people want to use simpler 
approaches,
even if they are not architecturally pure. Some of these approaches that 
are available
today and won't double the cost of a device because the OAM functions are 
built
on top of existing software, and thus don't require an army of software and 
hardware
developers to realize.

         I really think that operators and vendors want to eat OAM pudding,
not just talk about what color and shape it is. I just think if we try to 
build the
pudding described in Y.1711, that we will all starve

> >  If there are still holes after this exercise, lets work together
> > on these problems and find efficient and solvable solutions
> > to them. This may not result
> > in an architectural correct over-all grand reference,
>NH=> Let me paraphrase what you are saying here:
>-       I assume this remark is suggesting that the requirements given in
>draft-harrison-mpls-oam-req-01.txt (and also in Y.1710) is not really what
>carriers want, even though they are asking for them, and that Y.1711 is not
>a good solution....

         I do not think that Y.1711 presents good solutions to the problem of
OAM. I don't think I am out in left field on this one either. So again, I
propose that we work on practical solutions to the problem of OAM
for MPLS.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Sat, 02 Mar 2002 13:28:57 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Sat, 2 Mar 2002 21:24:21 -0000 

Tom...please see below.  Regards, Neil
>>If you noted in some of my earlier mails I was very 
> careful to refer to
> >'simple breaks' when using trail-trace type of mechanisms for defect
> >diagnosis.  If you ever get a misbranching/mismerging defect then:
> >-       you need to know it exists in the 1st place (not 
> obvious how this
> >can be done....with CV it's trivial, as you see the source ID of any
> >offending LSP at the sink of the offended LSP, so you both 
> detect/diagnose
> >immediately)....I'll ignore the fact that a whole raft of 
> consequent actions
> >are also missing;
> 
>          Please clarify.
NH=> I provided info in earlier mails on this but you may have missed them,
also a read of Y.1710 and Y.1711 may not go amiss (BTW Cisco has 4 delegates
to the last SG13 where these Recs where agreed so they should be able to
provide you with copies, and I also noted Bian Moore recently flagged a URL
where copies of SG13 Recs should be available soon)....however, in summary:
-	need to raise an alarm relevant to the defect
-	need to suppress alarms in higher layer networks.....we all take FDI
(from networks like SDH/ATM/OTN) for granted.....some additonal features in
MPLS FDI which are defined are DL (Defect Location) and DT (Defect
Type)......former gives AS of original defect (but no lower level detail)
and latter indicates nature of original defect;
-	need to squelch traffic if misdelivered;
-	need to provide BDI if single-ended monitoring of availability
and/or 1:N-type of prot-sw used.....also replicates DL/DT fields from FDI;
-	need to suppress any QoS aggregation (into long-term registers of
such, eg pkt loss) when entering unavailable state.....but this pre-supposes
we have agreed/standardised (and in order) (i) defect entry/exit citeria
(ii) unavailable state entry/exit criteria.

<snipped>
> >NH=> Asking ICMP to proxy for missing defect handling in MPLS is a
> >possibility....and as Geroge hints in an earlier mail is 
> actually an example
> >of a layer violation, but so be it.  However, this should 
> not be used in
> >XoverMPLS....you need a solution here that is self-contained 
> within the MPLS
> >network.
> 
>          What is a "self-contained MPLS network"? MPLS 
> networks require IP 
> networks.
> When running X over MPLS why does that requirement change at all?
NH=> See my response to George S on this who raised the same point.
Note:  small point re above....I did not say 'self-contained MPLS network' I
said 'self-contained within the MPLS network', ie wrt the defect handling
behaviour.

Delivery-date: Sat, 02 Mar 2002 13:28:54 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Sat, 2 Mar 2002 21:24:23 -0000 

Hi Tom...I am very glad you raised these points....please see my
observations on them.  regards Neil

<snip>
> Achitectural correctness is bunk if it 
> does not leads to
> implementations that cannot support the architecture in such 
> a way as to a) be
> implemented in one's lifetime,
NH=> I wholeheartedly agree with this......and for as long as I can remember
management-plane X-I/Fs have been promised but never materialised.  However,
wrt to the topic here I am already aware of trial implementations by certain
vendors and Shahram Davari has been involved since very early on....and
since his company cuts the silicon many then use then this tells me it can't
be be too complex.  Maybe this is just a problem for your company?....a
quick look-see at who has problems seems to indicate Cisco figures largely
here in a class of 1.  However, you are not compelled to implement all (or
even any) of this stuff if you choose not to.

> and b) can be sold for a 
> reasonable price. 
> If neither
> can be met, then we are all just wasting our time.
NH=> What is a reasonable price to your company wrt to a box may mean an
unreasonable price/risk to an operator wrt to a network and the services it
supports, ie the operator may have increased Opex costs and unhappy
customers because they cannot offer robust carrier-strength network/service
management.  It would really help if you could give us some hard proof that
what has been requested/proposed is too costly for us/you?  But so far it
seems I can't get answers to this.
<snipped>

>          I think what might be more constructive is to set out the
> current problems that you as an operator (and other 
> operators) think need 
> to be
> solved and then see how the existing solutions can be used to 
> solve these
> problems.
NH=> I though we did this at the last BoF?....Peter Willis represented BT
and gave these. They are stated (as requirements) in
draft-harrison-mpls-oam-req-01.txt. 

> Please don't just refer us again to your OAM draft, 
> because I think
> it is clear that is a non-starter.
NH=> Why is this.....and are you speaking on behalf of yourself, Cisco or
the IETF?  By saying this you are also stating that you also don't
value/respect the fact that these requirements are supported by the
following carriers AT&T, SBC, NTT, DT, Sprint, BT (+ a list of
manafuacturers, who are prepared it seems to meet these requirements).  You
offer no rationale for this statement.......so I can only assume you (or
your company) disagree with these carrier's  requirements. 

>  If there are still holes 
> after this 
> exercise, lets work together
> on these problems and find efficient and solvable solutions 
> to them. This 
> may not result
> in an architectural correct over-all grand reference,
NH=> Let me paraphrase what you are saying here:
-	I assume this remark is suggesting that the requirements given in
draft-harrison-mpls-oam-req-01.txt (and also in Y.1710) is not really what
carriers want, even though they are asking for them, and that Y.1711 is not
a good solution....so, as I have asked many times now, it would help if you
could please provide evidence to support this remark.
-	irrespective of what carriers want, it seems the answer is X, so
let's develop X and only X come what may.  Given this, is there actually any
point is submitting requirements?

> but it 
> is probably 
> going to get us further
> than arguing over what is architecturally pure and what is 
> not, which IMHO 
> is a waste
> of everyone's time.
NH=> Agree with the waste of everyone's time bit......IMO it hardly seems to
matter what certain carrier's bring to IETF, it seems they just get ignored
if it does not suit certain parties.  Indeed, we are seriously reviewing the
value of continued IETF participation because of this.  I think it would be
far more constructive if you could explain to the carriers noted above why
they don't really want what they are asking for. It would also help if you
can explain how the 'existing solutions' (sic) that you refer to can meet
(or not) these requirements?

However, if you are not even prepared to countenance such requirements as
you stated above (ie "Please don't just refer us again to your OAM draft,
because I think it is clear that is a non-starter."), then maybe the simple
way out now (esp so we don't continue to waste each others time) is that
'IETF' develop the OAM solutions for MPLS that they feel are fit for purpose
and we let the carriers choose what they want to ask for?  And, as I
remarked earlier, there is no need whatsoever for your company to implement
all (or even any) of the Y.1711 stuff if you don't feel its any good.

Delivery-date: Sat, 02 Mar 2002 13:28:50 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Sat, 2 Mar 2002 21:24:18 -0000 

> > NH=> Asking ICMP to proxy for missing defect handling in MPLS is a
> > possibility....and as George hints in an earlier mail is 
> actually an example
> > of a layer violation, but so be it.  However, this should 
> not be used in
> > XoverMPLS....you need a solution here that is 
> self-contained within the MPLS
> > network.
> 
> Have we found the crux of the matter?  MPLS as defined by the IETF
> (and I personally don't believe any other body has jurisdiction over
> the core MPLS technology) requires that all boxes be IP capable.
> 
> ...George

NH=> Yes I think you have hit on the key point here George.....but you need
to be clear which *plane* you are referring to.  To do what is being
suggested (implicitly by your comment) requires an IP capable transfer-mode
network that is decoupled from the other layer network that it is proxying
defect handling for.   In other words, the IP network is acting as though
its some form of (i) higher layer client application/test-probe in the
traffic-plane and (ii) management-plane gatherer of information.  Several
points flow from this:

-	its a well known fact to us in telco world that the data-planes of
the traffic, control and management planes are not necessarily
congruent.....indeed for CO networks there are many advantages in not having
them congruent and in some cases this is clearly forced, eg OTNs.  A key
point of this observation is that the topology/design of the control (or
management) data-planes must only take its survivability cues from the duct
layer.  So even if one is using an IP-based encapsulation/transfer mode in
the user-plane of the control or management networks here, one may not be
doing so in the traffic-plane (this also has implications for 'addressing'
of the data-plane access points of the networks that constitute these
different planes).

-	if I build on the above and consider SDH/OTNs in general (we can
collectively call these GMPLS if it helps), the traffic-plane here is a
cct-sw 'quantised BW' entity.....clearly this has nothing to do with IP at
all (it may ultimately carry an IP-based pkt stream, or indeed anything
else, but that is irrelevant).  You might use an IP delivered set of
protocols in the management or control planes for such networks.....but
these lie in a different data-plane network as I noted above.

-	if one agrees with the above (and I can't see how anyone could not
since its obvious), then it follows that this logic can be applied to any CO
layer network.....MPLS is therefore but one example that I can add to FR,
ATM, SDH, OTNs, etc.  Ergo GMPLS....in principle, if not in embodiment.

-	and to reinforce the point.....the fact that MPLS creates new CO
trail entities (that can carry clients other than IP) means these will have
failure modes that are not relevant to any other layer network (inc IP), and
need decoupling from any specific client or server layer technologies.  This
is just a fact......you can disagree with it if you like (and I am sure many
will) but I can't alter the truth of this observation (hopefully such a
truth is a bit more obvious for an OTN in the context of 'GMPLS' for anyone
still struggling to grasp this).

Trying to pretend MPLS is not a layer network which creates CO trails (when
ER/signalled at least) does not help anyone long-term....esp if one is also
prepared to accept what is happening in GMPLS, as such a stance would be a
logical contradiction.  IMO its time we faced this fact and stopped skirting
the issue.

BTW - I would be careful saying that no other body should have jurisdiction
over MPLS as:
(i) I can't equate this remark with what I see happening to SDH and OTN wrt
GMPLS in IETF;
(ii) there are other bodies out there like ITU, ATMF, MPLSF, IEEE who will
need to have some say wrt MPLS development (ditto GMPLS....or put another
way SDH/OTNs/etc and the interfacing/control/management of such);
(iii) it assumes that IETF are eventually going to provide some
carrier-strength defect detection/handling functions for MPLS, but given
what I have seen over the last year this seems very unlikely to materialise.

regards, Neil

Delivery-date: Sat, 02 Mar 2002 13:28:48 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Sat, 2 Mar 2002 21:24:19 -0000 

Leen,

This is quite correct.  And it really does help not hinder.  The difficult
bit for most people I think is accepting MPLS fits here.  SDH and OTNs are
very obvious in that they do fit....ergo GMPLS fits.  FR and ATM also fit.
MPLS also fits but its hard for some to make this association (for whatever
reason....be it a truly held conviction or (more worryingly) commercially
driven motives).

All I have been saying is that this gives a formal way of describing layered
network relationships (just like your periodic table analogy)....and once
grasped it is very powerful in understanding/specifying required network
behaviour (and it also immediately explains the reality of the L1/2/3 tags
people use somewhat arbitrarily and the fact there there is no such thing as
'one' L3 network, viz the OSI 7-layer model).

It actually would help with progressing Bonnica and also understanding the
approach others have taken in Y.1710/1711.....but it requires a willingness
to be able to go into Rx mode rather than just Tx mode.

regards, Neil

> -----Original Message-----
> From: Mak, L (Leen) [mailto:[email-masked]]
> Sent: 01 March 2002 15:58
> To: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> Let me make a Friday afternoon remark and than duck 
> for the flak:
> 
> IMHO, the layering concept (and the associated system
> of functional modelling) is to the study and design of
> (circuit based) transport networks what the Periodic 
> System of Elements is to chemistry.
> 
> Of course, you can do without, but with such an ordening 
> principle the work in the field becomes a bit less intuitive 
> and a bit more structured. If you like: less of an art and 
> more of an engineering discipline. 
> 
> I'm afraid this does not progress the discussion on the 
> bonica draft, but it might help getting the layering concept 
> where it belongs ...
> 
> 
> Leen Mak.
> 
> 

Delivery-date: Fri, 01 Mar 2002 13:56:14 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Bradford, Richard" <[email-masked]>, Jonathan Lang <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: RE: LMP
Date: Fri, 1 Mar 2002 22:55:48 +0100 

Inline

> -----Original Message-----
> From: Bradford, Richard [mailto:[email-masked]]
> Sent: Friday, March 01, 2002 10:03 PM
> To: Jonathan Lang
> Cc: 'Wijnen, Bert (Bert)'; ccamp-wg
> Subject: RE: LMP
> 
> 
> At 11:30 AM 3/1/2002 -0800, Jonathan Lang wrote:
> >Bert,
> >
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > Sent: Tuesday, February 26, 2002 2:26 PM
> > > To: ccamp-wg
> > > Subject: LMP
> > >
> > >
> > >
> > > When I look at section 14, then I wonder:
> > >
> > >   LOCAL_CCID:  Class = 1, C-Type = 1, 4 byte CC_id
> > >   REMOTE_CCID: Class = 2, C-Type = 1, 4 byte CC_id
> > >
> > > Why is that not:
> > >
> > >   CCID: Class = 1, LOCAL: C-Type = 1, 4 byte CC_id
> > >   CCID: Class = 1, LOCAL: C-Type = 2, 4 byte CC_id
> >This change is fine with me unless there is objection from others.
> 
> I'll raise an objection. Throughout the draft the Class is 
> being used to define the meaning of the object and C-type its format.
> Local and remote CCIDs are two completely different objects.
> They are as different as remote  and local node-IDs.
> They are not different formats of the same object.
>
Sorry, I had a cut-and-paste error. I meant:
Why is that not:

   CCID: Class = 1, LOCAL:  C-Type = 1, 4 byte CC_id
   CCID: Class = 1, REMOTE: C-Type = 2, 4 byte CC_id

Bert

Delivery-date: Fri, 01 Mar 2002 13:43:01 -0800
From: Luc Ceuppens <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Fri, 1 Mar 2002 13:39:42 -0800

[ post by non-subscriber ]

(2)

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 1:37 AM
> To: ccamp-wg
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> CCAMP WG members, 
> 
> before we start down another many 100s of emails re-discussing
> the same topic....
> 
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
> 
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> > 
> > 1) Do you think we should have just a single set of traffic 
> parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> > 
> > (in the above, SHOULD and MUST are to be interpreted as in 
> RFC 2119.)
> > 
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Thanks
> Bert, speaking as AD who would like to see the WG take 
>       a decision on this topic.
> 

Delivery-date: Fri, 01 Mar 2002 13:23:02 -0800
Date: Fri, 01 Mar 2002 15:28:15 -0600
From: Jim Jones <[email-masked]>
Organization: Alcatel USA
To: "'Wijnen, Bert (Bert)'" <[email-masked]>
CC: ccamp-wg <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Option 2.)

Jim

>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Tuesday, February 26, 2002 1:37 AM
> > To: ccamp-wg
> > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> >
> >
> > CCAMP WG members,
> >
> > before we start down another many 100s of emails re-discussing
> > the same topic....
> >
> > PLEASE express your support for one of the 3 options that Kireeti
> > posed to the WG. Don't elaborate... just help the WG chair(s) to
> > figure out the (rough) consensus of the WG. The choices formulated
> > by Kireeti:
> >
> > > So, here we are again, arguing over this.  Let's follow the AD's
> > > suggestion and look for consensus in the WG.
> > >
> > > 1) Do you think we should have just a single set of traffic
> > parameters
> > >    and label values for SDH, and none for SONET?
> > > or
> > > 2) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one SHOULD
> > >    use the SDH equivalent?
> > > or
> > > 3) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one MUST
> > >    use the SDH equivalent?
> > >
> > > (in the above, SHOULD and MUST are to be interpreted as in
> > RFC 2119.)
> > >
> > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> >
> > Thanks
> > Bert, speaking as AD who would like to see the WG take
> >       a decision on this topic.
> >

Delivery-date: Fri, 01 Mar 2002 13:06:32 -0800
Date: Fri, 01 Mar 2002 16:02:57 -0500
To: Jonathan Lang <[email-masked]>
From: "Bradford, Richard" <[email-masked]>
Subject: RE: LMP
Cc: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>

At 11:30 AM 3/1/2002 -0800, Jonathan Lang wrote:
>Bert,
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Tuesday, February 26, 2002 2:26 PM
> > To: ccamp-wg
> > Subject: LMP
> >
> >
> >
> > When I look at section 14, then I wonder:
> >
> >   LOCAL_CCID:  Class = 1, C-Type = 1, 4 byte CC_id
> >   REMOTE_CCID: Class = 2, C-Type = 1, 4 byte CC_id
> >
> > Why is that not:
> >
> >   CCID: Class = 1, LOCAL: C-Type = 1, 4 byte CC_id
> >   CCID: Class = 1, LOCAL: C-Type = 2, 4 byte CC_id
>This change is fine with me unless there is objection from others.

I'll raise an objection. Throughout the draft the Class is being used to 
define the meaning of the object and C-type its format. Local and remote 
CCIDs are two completely different objects. They are as different as remote 
and local node-IDs. They are not different formats of the same object.

--
Rich Bradford          Email: [email-masked]
Cisco Systems, Inc.    Tel: 978-497-3079
300 Apollo Drive       Fax: 978-497-3079
Chelmsford, Mass 01824

Delivery-date: Fri, 01 Mar 2002 12:49:42 -0800
From: "Natale, Robert C (Bob)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Fri, 1 Mar 2002 15:48:23 -0500 

Hi,

Apologies in advance for this post going against the
grain of the AD's guidance for this thread.  I am not
(I hope!) posting a "diatribe" here :-) -- I am just
curious about something and maybe the answer to it
will affect my own and possibly others' assessment
of the options before us....

As a non-expert (re the diffs between SONET and SDH as
they might necessarily affect labeling requirements or
not), I opted for #1 (or #4, which I consider to be its
moral equivalent) on the basis of my interpretation of
s/w engineering principles and my (negative) experience
with allowing optionality in widely deployed standards.

Since the respondents seems largely divided between
#1 and #2 (with the few mentioning #4 as an acceptable
alternative about equally divided between #1 and #2
as another acceptable choice for them), my attention
is naturally drawn to the absence of any "votes" for
#3 (apologies if I've missed anyone's vote for #3)...?

The only diff that I can discern between #2 and #3 is
the SHOULD in #2 vs the MUST in #3.  It is that SHOULD
in #2 that caused me to discount it up front.  I am
curious to know how the people expressing a preference
for #2 feel about #3 -- that is, do they see it important
that we specify #2 rather than #3, or rather than #1?

I'm really against that SHOULD in #2.  But -- although
I do prefer #1 (or, second, #4) for the reasons mentioned
above -- I might not feel as determinedly antagonistic
to #3, if that were to end up being the WG's consensus.

Thanks,

BobN

>At 07:39 AM 2/26/2002, Wijnen, Bert (Bert) wrote:
>If people want to express their support for this 4th option
>then that is fine with me. WG chair(s) do you agree too
>(don't want to step on your toes or sit in your chair).
>
>Bert
>
> > -----Original Message-----
> > From: Mannie, Eric 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Tuesday, February 26, 2002 11:32 AM
> > To: 'Wijnen, Bert (Bert)'; ccamp-wg
> > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> >
> >
> > Hello Bert and all,
> >
> > One question is missing:
> >
> > 4) Do you think we should have just a single set of traffic
> > parameters and label format (values) for both SDH and SONET.
> >
> > In 1) "none for SONET" assumes that SONET doesn't exist
> > anymore. Note also that the traffic parameters are already
> > identical, the only difference is about the label. As editor
> > of these drafts I would like at least to see the right
> > questions asked on the mailing list.
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Tuesday, February 26, 2002 10:37 AM
> > To: ccamp-wg
> > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> >
> > CCAMP WG members,
> >
> > before we start down another many 100s of emails re-discussing
> > the same topic....
> >
> > PLEASE express your support for one of the 3 options that Kireeti
> > posed to the WG. Don't elaborate... just help the WG chair(s) to
> > figure out the (rough) consensus of the WG. The choices formulated
> > by Kireeti:
> >
> > > So, here we are again, arguing over this.  Let's follow the AD's
> > > suggestion and look for consensus in the WG.
> > >
> > > 1) Do you think we should have just a single set of traffic
> > >    parameters and label values for SDH, and none for SONET?
> > > or
> > > 2) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one SHOULD
> > >    use the SDH equivalent?
> > > or
> > > 3) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one MUST
> > >    use the SDH equivalent?
> > >
> > > (in the above, SHOULD and MUST are to be interpreted as in
> > > RFC 2119.)
> > >
> > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> >
> > Thanks
> > Bert, speaking as AD who would like to see the WG take
> >       a decision on this topic.

Delivery-date: Fri, 01 Mar 2002 12:21:47 -0800
Date: Fri, 01 Mar 2002 15:21:32 -0500
To: "Wijnen, Bert (Bert)" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Cc: "Mannie, Eric" <[email-masked]>,"ccamp-wg" <[email-masked]>

(4) or if not approved, (2).

Lou

At 07:39 AM 2/26/2002, Wijnen, Bert (Bert) wrote:

>If people want to express their support for this 4th option
>then that is fine with me. WG chair(s) do you agree too
>(don't want to step on your toes or sit in your chair).
>
>Bert
>
> > -----Original Message-----
> > From: Mannie, Eric 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Tuesday, February 26, 2002 11:32 AM
> > To: 'Wijnen, Bert (Bert)'; ccamp-wg
> > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> >
> >
> > Hello Bert and all,
> >
> > One question is missing:
> >
> > 4) Do you think we should have just a single set of traffic
> > parameters and
> > label format (values) for both SDH and SONET.
> >
> > In 1) "none for SONET" assumes that SONET doesn't exist
> > anymore. Note also
> > that the traffic parameters are already identical, the only
> > difference is
> > about the label. As editor of these drafts I would like at
> > least to see the
> > right questions asked on the mailing list.
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Tuesday, February 26, 2002 10:37 AM
> > To: ccamp-wg
> > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> >
> >
> > CCAMP WG members,
> >
> > before we start down another many 100s of emails re-discussing
> > the same topic....
> >
> > PLEASE express your support for one of the 3 options that Kireeti
> > posed to the WG. Don't elaborate... just help the WG chair(s) to
> > figure out the (rough) consensus of the WG. The choices formulated
> > by Kireeti:
> >
> > > So, here we are again, arguing over this.  Let's follow the AD's
> > > suggestion and look for consensus in the WG.
> > >
> > > 1) Do you think we should have just a single set of traffic
> > parameters
> > >    and label values for SDH, and none for SONET?
> > > or
> > > 2) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one SHOULD
> > >    use the SDH equivalent?
> > > or
> > > 3) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one MUST
> > >    use the SDH equivalent?
> > >
> > > (in the above, SHOULD and MUST are to be interpreted as in
> > RFC 2119.)
> > >
> > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> >
> > Thanks
> > Bert, speaking as AD who would like to see the WG take
> >       a decision on this topic.
> >

Delivery-date: Fri, 01 Mar 2002 12:20:16 -0800
Date: Fri, 01 Mar 2002 15:18:41 -0500
To: CCAMP <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: GMPLS Signaling Implementation Survey Form
Cc: Yakov Rekhter <[email-masked]>

All,

If you'd like to participate in a GMPLS signaling implementation survey, 
please complete (as much as you can/want) and return the enclosed.  We will 
consolidate all answers and publish the results (to the list and as a draft.)

Thank you,
Lou (and Yakov)

----------------------------------
GMPLS Signaling Implementation Survey Form                          [V 1.0]

    This is form is derived from V2.2 of the "RSVP and QoS Implementation
    Survey Information Form" authored by Gene Gaines <[email-masked]>
    and Marco Festa <[email-masked]>.  See
    http://www.iit.nrc.ca/IETF/RSVP_survey/rsvp-qos_quest_980210.txt.

    This form is also available from
    http://www.labn.net/gmpls/sig-survey.txt
=======================================================================

1.  Organization:

1.1   Organization url(s):

2.  Product title(s):

2.1   Brief description(s):

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

3.  Contact for GMPLS information
3.1   Name:

3.2   Title:

3.3   E-mail:

3.4   Organization/department:

3.5   Postal address:

3.6   Phone:

3.7   Fax:
----------------------------------------------------------------

4.  Status:
4.1     [ ] Development
4.2     [ ] Alpha
4.3     [ ] Beta
4.4     [ ] Product
4.5     [ ] Other (describe):

5.  Switching capabilities
5.1     [ ] PSC
5.2     [ ] TDM
5.3     [ ] LSC
5.4     [ ] FSC

6. Reference Drafts (please list, include version numbers)
6.1    [ ]
6.2    [ ]
6.3    [ ]
6.4    [ ]
6.5    [ ]
6.6    [ ]

7. Interface technologies
7.1    [ ] Frame Relay
7.2    [ ] ATM
7.3    [ ] Ethernet V2/DIX
7.4    [ ] Ethernet 802.3
7.5    [ ] SDH
7.6    [ ] SONET
7.7    [ ] Lambda (photonic)
7.8    [ ] Fiber
7.9    [ ] FiberChannel
7.10   [ ] Other (describe):

8. Availability
8.1    [ ] Public and free
8.2    [ ] Only to selected organizations/companies but free
8.3    [ ] On sale.
8.4    [ ] For internal company use only
8.5    [ ] Other:

9. Implementation based on:  (check all that apply)
9.1    [ ] Purchased code (please list source if possible)
9.2    [ ] Free code (please list source if possible)
9.3    [ ] Internal implementation (no outside code, just from specs)
9.4    [ ] Internal implementation on top of purchased or free code
9.4.1      [ ] List portions from external source
9.4.2      [ ] List portions developed internally

10.  Supported Label Types
10.1  [ ] MPLS Label
10.2  [ ] Generalized Label
10.3  [ ] Waveband Label
10.4  [ ] SONET/SDH Label

11.  Label Related
11.1  [ ] Suggested Label
11.2  [ ] Label Set

12.  Traffic Parameters
12.1  [ ] Intserv (Please list which)
12.2  [ ] CR-LDP
12.3  [ ] GMPLS Bandwidth Encoding
12.4  [ ] SONET/SDH

13.   [ ] Bidirectional LSPs

14.  Notification
14.1 [ ] Acceptable Label Set
14.2 [ ] Notify Request Objects (GMPLS-RSVP)
14.3 [ ] Notify Message (GMPLS-RSVP)
14.4 [ ] Removing State with a PathErr message (GMPLS-RSVP)

15  Other features
15.1  [ ] Explicit Label Control
15.2  [ ] Protection Information
15.3  [ ] Administrative Status Information
15.4  [ ] Interface Identification
15.5  [ ] Errored Interface Identification
15.6  [ ] Link Fault Handling
15.7  [ ] Nodal Fault Handling

16. Other specification(s) which apply:

17. Other features supported:

18. Currently-defined GMPLS signaling features not supported:

19. Notes (please describe purpose of project, give any information that
       might be useful to those interested in developing or using GMPLS)

20. If you feel the above categories are not complete, add others which
       will better describe your project:

=======================================================================

Person filling out this form:

      Name:

      E-mail:

      Tel.:

      Title:

      Company:

      Date prepared:

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

Return your information to the authors:

      Lou Berger <[email-masked]> or <[email-masked]> and
      Yakov Rekhter <[email-masked]>

      all returned information will be consolidated and reported
      to the CCAMP WG mailing list.

Thank you!

Updated 03/01/02

--end--

Delivery-date: Fri, 01 Mar 2002 11:40:05 -0800
From: Jonathan Lang <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Fri, 1 Mar 2002 11:33:06 -0800 

2)

Thanks,
Jonathan

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 1:37 AM
> To: ccamp-wg
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> CCAMP WG members, 
> 
> before we start down another many 100s of emails re-discussing
> the same topic....
> 
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
> 
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> > 
> > 1) Do you think we should have just a single set of traffic 
> parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> > 
> > (in the above, SHOULD and MUST are to be interpreted as in 
> RFC 2119.)
> > 
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Thanks
> Bert, speaking as AD who would like to see the WG take 
>       a decision on this topic.
> 

Delivery-date: Fri, 01 Mar 2002 11:39:33 -0800
From: Jonathan Lang <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, [email-masked]
Subject: RE: draft-ietf-ccamp-lmp-02.txt
Date: Fri, 1 Mar 2002 11:32:32 -0800 

Bert,
  Thanks for pointing this out.  We have already started working on this as
can be seen by the recent contribution by Alex Zinin on LMP Security. 

Thanks,
Jonathan

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 2:55 AM
> To: [email-masked]
> Subject: draft-ietf-ccamp-lmp-02.txt
> 
> 
> From Kireeti's "wg document status" email
> 
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:[email-masked]]
> > Sent: Monday, February 25, 2002 2:52 AM
> > To: [email-masked]
> > Subject: WG dcoument status
> > 
> > 
> > Here's a status update.
> > 
> ... snip ...
> 
> > The LMP draft:
> > 	draft-ietf-ccamp-lmp-02.txt
> > has gone through one round of WG Last Call comments and, once a
> > new version has been produced incorporating these comments, will
> > go through a final WG Last Call.  This is also targeted as a
> > Proposed Standard.
> > 
> I will note that in my view, the security section will need
> serious work. I doubt that the Security ADs will sign off on the
> current text. The security section should address the risks
> and treats. It should then specify how to protect against them.
> A text like "LMP exchanges may be authenticated with MD5" (which
> is basically what you write now) seems not sufficient to me.
> 
> Bert
> 

Delivery-date: Fri, 01 Mar 2002 11:38:00 -0800
From: Jonathan Lang <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: LMP
Date: Fri, 1 Mar 2002 11:30:52 -0800 

Bert,

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 2:26 PM
> To: ccamp-wg
> Subject: LMP
> 
> 
> 
> When I look at section 14, then I wonder:
> 
>   LOCAL_CCID:  Class = 1, C-Type = 1, 4 byte CC_id
>   REMOTE_CCID: Class = 2, C-Type = 1, 4 byte CC_id
> 
> Why is that not:
> 
>   CCID: Class = 1, LOCAL: C-Type = 1, 4 byte CC_id
>   CCID: Class = 1, LOCAL: C-Type = 2, 4 byte CC_id
This change is fine with me unless there is objection from others.

Thanks,
Jonathan

> 
> The above is just an example. this is type of definitions
> occur throughout section 14, and it seems we are using
> many more name space code points than really needed. 
> Is this handy? Wise? Good design?
> 
> Bert 
> 

Delivery-date: Fri, 01 Mar 2002 11:33:04 -0800
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: [email-masked]
Subject: Re: WG dcoument status 
Date: Fri, 01 Mar 2002 11:32:51 -0800
From: Yakov Rekhter <[email-masked]>

Bert,

> Mmm.. RFC1264 says on page 4, pls note items 4) and 5):
> 
>   
>   4.0 Requirements for Proposed Standard
> 
>    1) Documents specifying the Protocol and its Usage.  The
>       specification for the routing protocol must be well written such
>       that independent, interoperable implementations can be developed
>       solely based on the specification.  For example, it should be
>       possible to develop an interoperable implementation without
>       consulting the original developers of the routing protocol.
> 
>    2) A Management Information Base (MIB) must be written for the
>       protocol.  The MIB does not need to submitted for Proposed
>       Standard at the same time as the routing protocol, but must be
>       at least an Internet Draft.
> 
>    3) The security architecture of the protocol must be set forth
>       explicitly.  The security architecture must include mechanisms for
>       authenticating routing messages and may include other forms of
>       protection.
> 
>    4) One or more implementations must exist.
> 
>    5) There must be evidence that the major features of the protocol
>       have been tested.
> 
>    6) No operational experience is required for the routing protocol
>       at this stage in the standardization process.

(4) is satisfied by having just *one* implementation.

Ditto for (5).

Nowhere in the above there is a requirement for multiple interoperable
implementations. With this in mind, please take out the part about
"interoperability test results".

Yakov.

> 
> Bert 
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[email-masked]]
> > Sent: Friday, March 01, 2002 2:58 PM
> > To: Wijnen, Bert (Bert)
> > Cc: Kireeti Kompella; [email-masked]
> > Subject: Re: WG dcoument status 
> > 
> 
> .. snip ..
> 
> > > showing up.... In other words... it might be good if people start to
> > > report implementation and interoperability test reults.
> > 
> > Please note that in the RTG area (rfc1264) there is no requirement
> > for a Proposed Standard to have (a) more than one implementation, and
> > (b) for these implementations to be interoperable.
> > 
> > Yakov.
> > 

Delivery-date: Fri, 01 Mar 2002 11:32:39 -0800
Date: Fri, 01 Mar 2002 20:27:37 +0100
From: Gert Van Hoey <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: "Wijnen, Bert (Bert)" <[email-masked]>, "Mannie, Eric" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

I prefer option (2)

Gert

Delivery-date: Fri, 01 Mar 2002 11:29:15 -0800
To: "ccamp-wg <ccamp" <[email-masked]>
cc: "Wijnen, Bert (Bert)" <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF 
Date: Fri, 01 Mar 2002 11:28:34 -0800
From: Yakov Rekhter <[email-masked]>

My vote is for (2)

Yakov.

> "Wijnen, Bert (Bert)" wrote:
> 
> > CCAMP WG members,
> >
> > before we start down another many 100s of emails re-discussing
> > the same topic....
> >
> > PLEASE express your support for one of the 3 options that Kireeti
> > posed to the WG. Don't elaborate... just help the WG chair(s) to
> > figure out the (rough) consensus of the WG. The choices formulated
> > by Kireeti:
> >
> > > So, here we are again, arguing over this.  Let's follow the AD's
> > > suggestion and look for consensus in the WG.
> > >
> > > 1) Do you think we should have just a single set of traffic parameters
> > >    and label values for SDH, and none for SONET?
> > > or
> > > 2) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one SHOULD
> > >    use the SDH equivalent?
> > > or
> > > 3) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one MUST
> > >    use the SDH equivalent?
> > >
> > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> > >
> > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> >
> > Thanks
> > Bert, speaking as AD who would like to see the WG take
> >       a decision on this topic.

Delivery-date: Fri, 01 Mar 2002 10:43:27 -0800
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Thomas D. Nadeau'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Fri, 1 Mar 2002 10:42:30 -0800 

Eric,

> This  being the IETF,  there's not  much point  in 
> criticizing  a particular
> proposal on the ground that it only works when IP is used.  

I didn't criticize the IETF. I suggested that it would be preferred to develop a non-IP based OAM tool, if at all possible, and if it does not introduce excess complexity.

-Shahram 

Delivery-date: Fri, 01 Mar 2002 10:35:20 -0800
To: Shahram Davari <[email-masked]>
cc: "'Thomas D. Nadeau'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-bonica-tunneltrace-02 
Reply-To: [email-masked]
Date: Fri, 01 Mar 2002 13:34:56 -0500
From: Eric Rosen <[email-masked]>

Shahram> But we could also have  configured LSPs (without signaling), and in
Shahram> future  people   may  use  other   non-IP  based  routing/signaling
Shahram> protocols such as PNNI. 

I certainly  hope not.  But of  course there's no telling  what people might
try to do. 

Shahram> Therefore developing  an IP-based  OAM for MPLS  will unnecessarily
Shahram> limit the routing/signaling protocols that could be used for MPLS

This  being the IETF,  there's not  much point  in criticizing  a particular
proposal on the ground that it only works when IP is used.  

I would  propose that  issues having to  do with  the use of  non-IP control
planes be declared out of scope. 

Delivery-date: Fri, 01 Mar 2002 10:34:08 -0800
From: Jonathan Lang <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, [email-masked]
Subject: RE: draft-ietf-ccamp-lmp-02.txt
Date: Fri, 1 Mar 2002 10:25:59 -0800 

Bert,
  Thanks for your comments.  Responses inline.

-Jonathan

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 6:03 AM
> To: [email-masked]
> Subject: RE: draft-ietf-ccamp-lmp-02.txt
> 
> 
> Further comments (I have not checked the whole document,
> just reporting as I see thibgs while looking for specific
> stuff).
> 
> The IANA considerations section is setting aside 4% of the
> name space for Message Type and 8% of Object Class name space for
> OIF UNI. Is that the proper thing to do?
> 
> I understand OIF has already "provisionally claimed" a few
> of the "reserved" numbers. We can honor that while we move forward.
> But I think it would be better to keep the whole name space 
> assignments in one place, and under control of IANA.
> 
> The OIF (and other organisations) can then request assignments through
> the normal process, similar to how 
>   
>
http://www.ietf.org/internet-drafts/draft-bala-uni-signaling-extensions-00.t
xt
> is trying to do right now.
agreed.  We have rewritten the IANA considerations section to keep the whole
name space assignments under control of IANA.

>By the way, you use these terms:
>
>  - Message Type
>  - Msg Type
>  - MsgType
>
>Probably better to settle for one "spelling" and be consistent I think
Done.  Thanks for catching that.

>In IANA Considerations section you also talk about
>"class and class type name spaces" while you only elaborate on the
>control of the "Object Class Name Space". So are there multiple names
spaces
>for class and class-type or just one. There seem to be two, i.e. Object
Class
>and Class Type (within a class). Does the Class Type name space not have
>IANA considerations?
This has been clarified as you suggest.

>
>Bert 

> -----Original Message-----
> From: Wijnen, Bert (Bert) 
> Sent: Tuesday, February 26, 2002 11:52 AM
> To: [email-masked]
> Subject: draft-ietf-ccamp-lmp-02.txt
> 
> 
> From Kireeti's "wg document status" email
> 
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:[email-masked]]
> > Sent: Monday, February 25, 2002 2:52 AM
> > To: [email-masked]
> > Subject: WG dcoument status
> > 
> > 
> > Here's a status update.
> > 
> ... snip ...
> 
> > The LMP draft:
> > 	draft-ietf-ccamp-lmp-02.txt
> > has gone through one round of WG Last Call comments and, once a
> > new version has been produced incorporating these comments, will
> > go through a final WG Last Call.  This is also targeted as a
> > Proposed Standard.
> > 
> I will note that in my view, the security section will need
> serious work. I doubt that the Security ADs will sign off on the
> current text. The security section should address the risks
> and treats. It should then specify how to protect against them.
> A text like "LMP exchanges may be authenticated with MD5" (which
> is basically what you write now) seems not sufficient to me.
> 
> Bert
> 

Delivery-date: Fri, 01 Mar 2002 09:40:07 -0800
Date: Fri, 01 Mar 2002 18:38:25 +0100
From: [email-masked]
Organization: Alcatel Bell - IPO NA (Antwerpen)
To: "[email-masked]" <[email-masked]>
Subject: CCAMP P&R DT output: draft-design-team-gmpls-recovery-analysis-00.txt

CCAMPers, 

You can find from today the second output of the P&R DT 
on "GMPLS-based recovery analysis" at the following 
location:

http://www.cs.odu.edu/~sudheer/draft-design-team-gmpls-recovery-analysis-00.txt

Don't hesitate to share with us your comments and input.

- dimitri.

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Address: Alcatel - Optical NA, Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Fri, 01 Mar 2002 08:54:12 -0800
Date: Fri, 01 Mar 2002 11:53:51 -0500
To: <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: WG dcoument status
Cc: "John Drake" <[email-masked]>,"Berger, Lou" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "Kireeti Kompella" <[email-masked]>,<[email-masked]>

I'll send the form to the ccamp list and post a URL.

Lou

At 11:49 AM 3/1/2002, [email-masked] wrote:

>Lou,
>
>Could you please send me a form,
>
>Many thanks,
>- dimitri.
>
>John Drake wrote:
> >
> > Lou,
> >
> > Please send me a form.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Lou Berger [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Friday, March 01, 2002 8:20 AM
> > To: Wijnen, Bert (Bert)
> > Cc: Yakov Rekhter; Kireeti Kompella; [email-masked]
> > Subject: RE: WG dcoument status
> >
> > hmm,  looks like all that is missing is a formal statement on 4.
> > My guess is that just making a statement that one exists (and it does)
> > isn't sufficient.  I volunteer to pull together an implementation
> > report.  I'll send out a form later today, collect the info and post the
> > results.
> >
> > Lou
> >
> > At 11:02 AM 3/1/2002, Wijnen, Bert (Bert) wrote:
> >
> > >Mmm.. RFC1264 says on page 4, pls note items 4) and 5):
> > >
> > >
> > >   4.0 Requirements for Proposed Standard
> > >
> > >    1) Documents specifying the Protocol and its Usage.  The
> > >       specification for the routing protocol must be well written such
> > >       that independent, interoperable implementations can be developed
> > >       solely based on the specification.  For example, it should be
> > >       possible to develop an interoperable implementation without
> > >       consulting the original developers of the routing protocol.
> > >
> > >    2) A Management Information Base (MIB) must be written for the
> > >       protocol.  The MIB does not need to submitted for Proposed
> > >       Standard at the same time as the routing protocol, but must be
> > >       at least an Internet Draft.
> > >
> > >    3) The security architecture of the protocol must be set forth
> > >       explicitly.  The security architecture must include mechanisms for
> > >       authenticating routing messages and may include other forms of
> > >       protection.
> > >
> > >    4) One or more implementations must exist.
> > >
> > >    5) There must be evidence that the major features of the protocol
> > >       have been tested.
> > >
> > >    6) No operational experience is required for the routing protocol
> > >       at this stage in the standardization process.
> > >
> > >Bert
> > >
> > > > -----Original Message-----
> > > > From: Yakov Rekhter 
> [<<mailto:[email-masked]>mailto:[email-masked]>mailto:[email-masked]]
> > > > Sent: Friday, March 01, 2002 2:58 PM
> > > > To: Wijnen, Bert (Bert)
> > > > Cc: Kireeti Kompella; [email-masked]
> > > > Subject: Re: WG dcoument status
> > > >
> > >
> > >.. snip ..
> > >
> > > > > showing up.... In other words... it might be good if people start to
> > > > > report implementation and interoperability test reults.
> > > >
> > > > Please note that in the RTG area (rfc1264) there is no requirement
> > > > for a Proposed Standard to have (a) more than one implementation, and
> > > > (b) for these implementations to be interoperable.
> > > >
> > > > Yakov.
> > > >
>
>--
>Papadimitriou Dimitri
>E-mail : [email-masked]
>Website: 
><http://www.rc.bel.alcatel.be/~papadimd/index.html>http://www.rc.bel.alcatel.be/~papadimd/index.html 
>
>Address: Alcatel - Optical NA, Fr. Wellesplein, 1
>          B-2018 Antwerpen, Belgium
>Phone:   Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Fri, 01 Mar 2002 08:50:33 -0800
Date: Fri, 01 Mar 2002 17:49:32 +0100
From: [email-masked]
Organization: Alcatel Bell - IPO NA (Antwerpen)
To: John Drake <[email-masked]>
Cc: "'Lou Berger'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, Yakov Rekhter <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: WG dcoument status

Lou,

Could you please send me a form,

Many thanks,
- dimitri.

John Drake wrote:
> 
> Lou,
> 
> Please send me a form.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Friday, March 01, 2002 8:20 AM
> To: Wijnen, Bert (Bert)
> Cc: Yakov Rekhter; Kireeti Kompella; [email-masked]
> Subject: RE: WG dcoument status
> 
> hmm,  looks like all that is missing is a formal statement on 4.
> My guess is that just making a statement that one exists (and it does)
> isn't sufficient.  I volunteer to pull together an implementation
> report.  I'll send out a form later today, collect the info and post the
> results.
> 
> Lou
> 
> At 11:02 AM 3/1/2002, Wijnen, Bert (Bert) wrote:
> 
> >Mmm.. RFC1264 says on page 4, pls note items 4) and 5):
> >
> >
> >   4.0 Requirements for Proposed Standard
> >
> >    1) Documents specifying the Protocol and its Usage.  The
> >       specification for the routing protocol must be well written such
> >       that independent, interoperable implementations can be developed
> >       solely based on the specification.  For example, it should be
> >       possible to develop an interoperable implementation without
> >       consulting the original developers of the routing protocol.
> >
> >    2) A Management Information Base (MIB) must be written for the
> >       protocol.  The MIB does not need to submitted for Proposed
> >       Standard at the same time as the routing protocol, but must be
> >       at least an Internet Draft.
> >
> >    3) The security architecture of the protocol must be set forth
> >       explicitly.  The security architecture must include mechanisms for
> >       authenticating routing messages and may include other forms of
> >       protection.
> >
> >    4) One or more implementations must exist.
> >
> >    5) There must be evidence that the major features of the protocol
> >       have been tested.
> >
> >    6) No operational experience is required for the routing protocol
> >       at this stage in the standardization process.
> >
> >Bert
> >
> > > -----Original Message-----
> > > From: Yakov Rekhter [<mailto:[email-masked]>mailto:[email-masked]]
> > > Sent: Friday, March 01, 2002 2:58 PM
> > > To: Wijnen, Bert (Bert)
> > > Cc: Kireeti Kompella; [email-masked]
> > > Subject: Re: WG dcoument status
> > >
> >
> >.. snip ..
> >
> > > > showing up.... In other words... it might be good if people start to
> > > > report implementation and interoperability test reults.
> > >
> > > Please note that in the RTG area (rfc1264) there is no requirement
> > > for a Proposed Standard to have (a) more than one implementation, and
> > > (b) for these implementations to be interoperable.
> > >
> > > Yakov.
> > >

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
Address: Alcatel - Optical NA, Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Fri, 01 Mar 2002 08:42:49 -0800
From: "John Strand" <[email-masked]>
To: "Wijnen Bert \(Bert\)" <[email-masked]>, "ccamp-wg" <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Fri, 1 Mar 2002 11:42:56 -0500

My vote is for (1).

John

"Wijnen, Bert (Bert)" wrote:

> CCAMP WG members,
>
> before we start down another many 100s of emails re-discussing
> the same topic....
>
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
>
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
> Thanks
> Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

Delivery-date: Fri, 01 Mar 2002 08:42:00 -0800
From: Shahram Davari <[email-masked]>
To: "'Thomas D. Nadeau'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Fri, 1 Mar 2002 08:41:26 -0800 

Thom,

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Friday, March 01, 2002 11:08 AM
> To: [email-masked]
> Cc: [email-masked]; Shahram Davari; [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> 
> >Eric/Shahram,  see addtional remarks below.  regards Neil
> >
> > > Shahram> 1) If a router  is not GTTP upgraded, it will  drop
> > > the TTL expired
> > > Shahram>    GTTP messages.  Consequently the host will not
> > > receive any reply
> > > Shahram>    from that router,  which translates to a break
> > > in the tunnel at
> > > Shahram>    that point.
> > >
> > > For GTTP to be useful at all, the tunnel head ends must 
> support it.
> > >
> > > If a particular  node within a tunnel does not support  GTTP,
> > > but some nodes
> > > beyond  it do,  we won't  get complete  trace info,  but
> > > should  be  able to
> > > continue tracing beyond the non-supporting node.
> > >
> > > But the  basic point is valid,  that in order  to use GTTP to
> > >  trace through
> > > your network,  your routers must  support it.  I  guess I
> > > don't see  this as
> > > much of a problem.  I  wouldn't call it an interoperability
> > > problem, because
> > > no existing mechanisms are broken by the use of GTTP.
> >NH=> If you noted in some of my earlier mails I was very 
> careful to refer to
> >'simple breaks' when using trail-trace type of mechanisms for defect
> >diagnosis.  If you ever get a misbranching/mismerging defect then:
> >-       you need to know it exists in the 1st place (not 
> obvious how this
> >can be done....with CV it's trivial, as you see the source ID of any
> >offending LSP at the sink of the offended LSP, so you both 
> detect/diagnose
> >immediately)....I'll ignore the fact that a whole raft of 
> consequent actions
> >are also missing;
> 
>          Please clarify.

I think what Neil is saying is that a path-trace is only a diagnostics
tool. It can't be used to detect path-defects in real-time. You still need
another tool to detect that the defect exists in the first place, and then
you may use path-trace to find what the problem is.

Also using a GTTP type of path-trace, you have to assume either: 1) the path is fine (has no defect) or 2) If there is any defect, it is a simple path-break defect.

Defects such as misbranching, merging, etc can't be detected, unless: 1) All nodes are GTTP upgraded and 2) There is a return path from all nodes to the GTTP host

> 
> >-       since the location of such defects cannot be known a 
> priori, then if
> >you want the 'misbranched' GTTP messages to elicit a 
> response then the
> >arbitrary nodes where they end up must be able to respond......and in
> >general this means the whole network/nodes need to be 'GTTP 
> aware' and they
> >need a return channel to the source.
> >IMO any trail-trace functions are best used under the 
> assumption that the
> >network is actually defect-free.....we need other tools to 
> detect/handle the
> >defects (for the many reasons I tried to point out in earlier mails).
> > >
> > > Shahram> 2) TTL expired user packets will now be forwarded to
> > > UDP module
> > > Shahram>    instead of being dropped. Which could overload
> > > the UDP module in
> > > Shahram>    certain situations.
> > >
> > > TTL-expired user packets are not simply dropped today; they
> > > are forwarded to
> > > the ICMP module  to cause the generation of an  ICMP message.
> > >  Usually there
> > > is some sort of limit placed on the number of packets that
> > > can be queued for
> > > ICMP processing, or the  number of such packets that can be
> > > seen in a given
> > > amount of  time, etc.  The  marginal overhead to  see whether
> > > a  packet that
> > > makes it through to ICMP processing  is a GTTP packet doesn't
> > > seem like that
> > > big a deal.
> >NH=> Asking ICMP to proxy for missing defect handling in MPLS is a
> >possibility....and as Geroge hints in an earlier mail is 
> actually an example
> >of a layer violation, but so be it.  However, this should 
> not be used in
> >XoverMPLS....you need a solution here that is self-contained 
> within the MPLS
> >network.
> 
>          What is a "self-contained MPLS network"? MPLS 
> networks require IP 
> networks.
> When running X over MPLS why does that requirement change at all?

The basic philosophy of MPLS was to decouple forwarding from routing and signaling (control-plane). The idea was that any routing and signaling protocol could be used, without the need to change the forwarding paradigm.

It is true that today we have LDP, CR-LDP, RSVP-TE, BGP, etc  as control-plane. But 
we could also have configured LSPs (without signaling), and in future people may use other
non-IP based routing/signaling protocols such as PNNI.

Therefore developing an IP-based OAM for MPLS will unnecessarily limit the routing/signaling protocols that could be used for MPLS. If it was impossible to define a non-IP based OAM, then we had no choice, but it is possible.

Yours,
-Shahram

> 
>          --Tom
> 
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 

Delivery-date: Fri, 01 Mar 2002 08:30:37 -0800
From: John Drake <[email-masked]>
To: 'Lou Berger' <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: WG dcoument status 
Date: Fri, 1 Mar 2002 08:29:59 -0800 

Lou,

Please send me a form.

Thanks,

John

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Friday, March 01, 2002 8:20 AM
To: Wijnen, Bert (Bert)
Cc: Yakov Rekhter; Kireeti Kompella; [email-masked]
Subject: RE: WG dcoument status 

hmm,  looks like all that is missing is a formal statement on 4.
My guess is that just making a statement that one exists (and it does) 
isn't sufficient.  I volunteer to pull together an implementation 
report.  I'll send out a form later today, collect the info and post the 
results.

Lou

At 11:02 AM 3/1/2002, Wijnen, Bert (Bert) wrote:

>Mmm.. RFC1264 says on page 4, pls note items 4) and 5):
>
>
>   4.0 Requirements for Proposed Standard
>
>    1) Documents specifying the Protocol and its Usage.  The
>       specification for the routing protocol must be well written such
>       that independent, interoperable implementations can be developed
>       solely based on the specification.  For example, it should be
>       possible to develop an interoperable implementation without
>       consulting the original developers of the routing protocol.
>
>    2) A Management Information Base (MIB) must be written for the
>       protocol.  The MIB does not need to submitted for Proposed
>       Standard at the same time as the routing protocol, but must be
>       at least an Internet Draft.
>
>    3) The security architecture of the protocol must be set forth
>       explicitly.  The security architecture must include mechanisms for
>       authenticating routing messages and may include other forms of
>       protection.
>
>    4) One or more implementations must exist.
>
>    5) There must be evidence that the major features of the protocol
>       have been tested.
>
>    6) No operational experience is required for the routing protocol
>       at this stage in the standardization process.
>
>Bert
>
> > -----Original Message-----
> > From: Yakov Rekhter [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Friday, March 01, 2002 2:58 PM
> > To: Wijnen, Bert (Bert)
> > Cc: Kireeti Kompella; [email-masked]
> > Subject: Re: WG dcoument status
> >
>
>.. snip ..
>
> > > showing up.... In other words... it might be good if people start to
> > > report implementation and interoperability test reults.
> >
> > Please note that in the RTG area (rfc1264) there is no requirement
> > for a Proposed Standard to have (a) more than one implementation, and
> > (b) for these implementations to be interoperable.
> >
> > Yakov.
> >

Delivery-date: Fri, 01 Mar 2002 08:30:33 -0800
Date: Fri, 01 Mar 2002 17:29:50 +0100
From: Dieter Beller <[email-masked]>
Organization: Alcatel SEL AG, TND Stuttgart, Germany
To: [email-masked]
CC: Kireeti Kompella <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

This is a multi-part message in MIME format.
--------------92F447776B4FA072BE972122
Content-Type: multipart/alternative;
 boundary="------------5F237EA30320C44D576F5575"

--------------5F237EA30320C44D576F5575
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

My vote is for 2).

Dieter

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

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Sunday, February 24, 2002 4:11 PM
> To: Wijnen, Bert (Bert)
> Cc: Mannie, Eric; [email-masked]'; [email-masked]'; ccamp-wg;
> [email-masked]'
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
>
> On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:
>
> > Guys... I have seen to much of this. I have asked Kireeti
> > EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
> > WG mailing list. I do NOT want another 500 emails going back
> > and forth on this issue. We need to approach this pragmatically.
> >
> > - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the
> >   WG mailing list on what exactly we agreed in SLC. That will
> >   help to prepare a response to ITU-T as well
>
> First off, I should apologize for letting this go on unchecked.
>
> Second, I should make it known to the WG as a whole that there was
> a discussion of this issue at SLC among several folks directly
> involved, the ADs and the chairs.  I thought we had achieved
> consensus, but now it seems not.
>
> Here's what I thought we had agreed:
>
> 1) There is a document in the ITU that defines a *single* standard
that
>    encompasses both SONET and SDH -- almost.  There are a few signals
>    that are in SONET but not in SDH; it was believed that the only
such
>    signal was VC-3.  Also, there are "legacy" implementations of SONET

>    that do not match the ITU document.
>
> 2) Thus, it was agreed (to my recollection) that both the SONET and
>    SDH label formats will be retained, with wording that says that
>    whenever possible, the SDH equivalent should be used.  This covers
>    both the cases of SONET signals that don't have SDH equivalents,
>    and legacy equipment.
>
> It is *not* the IETF's intention to promote an artificial separation
> between SONET and SDH.  Nor is it the intent to promote as standard
> work that is now "pre-standard".
>
> However, it *is* the IETF's goal to be able to set up paths across
> SONET and SDH networks, and to be pragmatic about this.  This was
> the spirit in which an agreement was forged -- or so I thought.  In
> retrospect, it would have been wise to go one step further and
> decide the actual words.
>
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
>
> 1) Do you think we should have just a single set of traffic parameters

>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
>
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
>
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
>
> Thanks,
> Kireeti.

--

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

        V
+---------------+      Dieter Beller
| A L C A T E L |      Alcatel Optics Group
+---------------+      Terrestrial Networks Division
                       Dept. US/EA3

                       Alcatel SEL AG
                       Lorenzstrasse 10
                       D-70435 Stuttgart, Germany

                       Phone:   +49 711 821-43125
                       Fax:     +49 711 821-42303

                       E-mailto:[email-masked]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

--------------5F237EA30320C44D576F5575
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
My vote is for 2).
<p>Dieter
<p>
<hr WIDTH="100%">
<p><tt>> -----Original Message-----</tt>
<br><tt>> From: Kireeti Kompella [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</tt>
<br><tt>> Sent: Sunday, February 24, 2002 4:11 PM</tt>
<br><tt>> To: Wijnen, Bert (Bert)</tt>
<br><tt>> Cc: Mannie, Eric; [email-masked]'; [email-masked]'; ccamp-wg;</tt>
<br><tt>> [email-masked]'</tt>
<br><tt>> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF</tt>
<br><tt>></tt>
<br><tt>> On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:</tt>
<br><tt>></tt>
<br><tt>> > Guys... I have seen to much of this. I have asked Kireeti</tt>
<br><tt>> > EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the</tt>
<br><tt>> > WG mailing list. I do NOT want another 500 emails going back</tt>
<br><tt>> > and forth on this issue. We need to approach this pragmatically.</tt>
<br><tt>> ></tt>
<br><tt>> > - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the</tt>
<br><tt>> >&nbsp;&nbsp; WG mailing list on what exactly we agreed in SLC.
That will</tt>
<br><tt>> >&nbsp;&nbsp; help to prepare a response to ITU-T as well</tt>
<br><tt>></tt>
<br><tt>> First off, I should apologize for letting this go on unchecked.</tt>
<br><tt>></tt>
<br><tt>> Second, I should make it known to the WG as a whole that there
was</tt>
<br><tt>> a discussion of this issue at SLC among several folks directly</tt>
<br><tt>> involved, the ADs and the chairs.&nbsp; I thought we had achieved</tt>
<br><tt>> consensus, but now it seems not.</tt>
<br><tt>></tt>
<br><tt>> Here's what I thought we had agreed:</tt>
<br><tt>></tt>
<br><tt>> 1) There is a document in the ITU that defines a *single* standard
that</tt>
<br><tt>>&nbsp;&nbsp;&nbsp; encompasses both SONET and SDH -- almost.&nbsp;
There are a few signals</tt>
<br><tt>>&nbsp;&nbsp;&nbsp; that are in SONET but not in SDH; it was believed
that the only such</tt>
<br><tt>>&nbsp;&nbsp;&nbsp; signal was VC-3.&nbsp; Also, there are "legacy"
implementations of SONET</tt>
<br><tt>>&nbsp;&nbsp;&nbsp; that do not match the ITU document.</tt>
<br><tt>></tt>
<br><tt>> 2) Thus, it was agreed (to my recollection) that both the SONET
and</tt>
<br><tt>>&nbsp;&nbsp;&nbsp; SDH label formats will be retained, with wording
that says that</tt>
<br><tt>>&nbsp;&nbsp;&nbsp; whenever possible, the SDH equivalent should
be used.&nbsp; This covers</tt>
<br><tt>>&nbsp;&nbsp;&nbsp; both the cases of SONET signals that don't
have SDH equivalents,</tt>
<br><tt>>&nbsp;&nbsp;&nbsp; and legacy equipment.</tt>
<br><tt>></tt>
<br><tt>> It is *not* the IETF's intention to promote an artificial separation</tt>
<br><tt>> between SONET and SDH.&nbsp; Nor is it the intent to promote
as standard</tt>
<br><tt>> work that is now "pre-standard".</tt>
<br><tt>></tt>
<br><tt>> However, it *is* the IETF's goal to be able to set up paths across</tt>
<br><tt>> SONET and SDH networks, and to be pragmatic about this.&nbsp;
This was</tt>
<br><tt>> the spirit in which an agreement was forged -- or so I thought.&nbsp;
In</tt>
<br><tt>> retrospect, it would have been wise to go one step further and</tt>
<br><tt>> decide the actual words.</tt>
<br><tt>></tt>
<br><tt>> So, here we are again, arguing over this.&nbsp; Let's follow
the AD's</tt>
<br><tt>> suggestion and look for consensus in the WG.</tt>
<br><tt>></tt>
<br><tt>> 1) Do you think we should have just a single set of traffic parameters</tt>
<br><tt>>&nbsp;&nbsp;&nbsp; and label values for SDH, and none for SONET?</tt>
<br><tt>> or</tt>
<br><tt>> 2) Do you think we should have one for SONET and one for SDH,
with</tt>
<br><tt>>&nbsp;&nbsp;&nbsp; the proviso that, if an SDH equivalent is available,
one SHOULD</tt>
<br><tt>>&nbsp;&nbsp;&nbsp; use the SDH equivalent?</tt>
<br><tt>> or</tt>
<br><tt>> 3) Do you think we should have one for SONET and one for SDH,
with</tt>
<br><tt>>&nbsp;&nbsp;&nbsp; the proviso that, if an SDH equivalent is available,
one MUST</tt>
<br><tt>>&nbsp;&nbsp;&nbsp; use the SDH equivalent?</tt>
<br><tt>></tt>
<br><tt>> (in the above, SHOULD and MUST are to be interpreted as in RFC
2119.)</tt>
<br><tt>></tt>
<br><tt>> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!</tt>
<br><tt>></tt>
<br><tt>> Feedback is welcome from *all* those interested in the CCAMP
WG.</tt>
<br><tt>> Also, what we are looking for is rough consensus, not votes.</tt>
<br><tt>></tt>
<br><tt>> Thanks,</tt>
<br><tt>> Kireeti.</tt>
<p><tt>--</tt><tt></tt>
<p><tt>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; V</tt>
<br><tt>+---------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dieter Beller</tt>
<br><tt>| A L C A T E L |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Alcatel Optics
Group</tt>
<br><tt>+---------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Terrestrial Networks
Division</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Dept. US/EA3</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Alcatel SEL AG</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Lorenzstrasse 10</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
D-70435 Stuttgart, Germany</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Phone:&nbsp;&nbsp; +49 711 821-43125</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax:&nbsp;&nbsp;&nbsp;&nbsp; +49 711 821-42303</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
E-<A HREF="mailto:[email-masked]">mailto:[email-masked]</A></tt><tt></tt>
<p><tt>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++</tt>
<br>&nbsp;</html>

--------------5F237EA30320C44D576F5575--

--------------92F447776B4FA072BE972122
Content-Type: text/x-vcard; charset=us-ascii;
 name="D.Beller.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dieter Beller
Content-Disposition: attachment;
 filename="D.Beller.vcf"

begin:vcard 
n:Beller;Dieter
tel;fax:+49 711 821 - 42303
tel;work:+49 711 821 - 43125
x-mozilla-html:FALSE
org:Alcatel - Optics Group - Terrestrial Networks Division;US/EA3
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Alcatel SEL AG,=0D=0ALorenzstrasse 10;Stuttgart;;70435;Germany
fn:Beller, Dieter
end:vcard

--------------92F447776B4FA072BE972122--

Delivery-date: Fri, 01 Mar 2002 08:24:47 -0800
Date: Fri, 01 Mar 2002 11:23:57 -0500
To: [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02 
Cc: [email-masked], [email-masked]

>George....you are simply wrong here *if* applied architecturally correctly.

         We need to remember one of the guiding principles of the
IETF (remember Neil, this is not the ITU): working code and rough consensus.
Both exist for most of the existing "oam" solutions. As Yakov said 
recently, "the
proof is not necessarily in the pudding, but in the eating of the pudding." I
want to eat pudding.  Achitectural correctness is bunk if it does not leads to
implementations that cannot support the architecture in such a way as to a) be
implemented in one's lifetime, and b) can be sold for a reasonable price. 
If neither
can be met, then we are all just wasting our time.

>But please explain/list examples of layer violations you are aware of.
>BTW - If anyone takes what you have written at face value then all tunnels
>should be banned, ie they are *all* layer violations (I see Shahram also
>noted exactly similar).  Sadly, from what I see you may be actually correct
>in many cases (ie relying on fault management of one layer to proxy for
>inadequacies in another layer)....but you'd need to think the consequences
>of that out very carefully and the potential implications before you take it
>further.
>
>In the meantime.....
>
>Think of a leased line (as a server...any technology) that you do not
>own.....or even a duct network (yes its a real network, bottom layer in
>fact....and sets the inherited disjoint connectiveity graph for *all* layers
>above it) that you do not own, and I am aware of Andy Reid of BT here
>telling me you lost a bet with him over virtualisation here.  A 'Tunnel' is
>a colloquialism for a (more formally defined) server layer trail (which can
>be a link connection between client layer nodes).  If you don't/can't grok
>this yet please read the text book by Reid/Sexton on Broadband Networking or
>G.805.....and tell us what is factually wrong with what is in there.  I am
>finding these terse 'I know better than you' assertions not all
>constructive....esp when they are plainly wrong, like this one (*if* done
>arch correctly of course).

         I think what might be more constructive is to set out the
current problems that you as an operator (and other operators) think need 
to be
solved and then see how the existing solutions can be used to solve these
problems. Please don't just refer us again to your OAM draft, because I think
it is clear that is a non-starter.  If there are still holes after this 
exercise, lets work together
on these problems and find efficient and solvable solutions to them. This 
may not result
in an architectural correct over-all grand reference, but it is probably 
going to get us further
than arguing over what is architecturally pure and what is not, which IMHO 
is a waste
of everyone's time.

         --Tom

>Neil
>
> > -----Original Message-----
> > From: George Swallow [mailto:[email-masked]]
> > Sent: 28 February 2002 17:12
> > To: Shahram Davari
> > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked];
> > [email-masked]
> > Subject: Re: draft-bonica-tunneltrace-02
> >
> >
> > Shahram -
> >
> > > and layer violation issues.
> >
> > Any sort of a tunnel is a layer violation in and of itself.  So if you
> > have to violate those same layers to trace them so be it.
> >
> > ...George
> >
> > ==================================================================
> > George Swallow       Cisco Systems                  (978) 497-8143
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824
> >

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Fri, 01 Mar 2002 08:22:01 -0800
Date: Fri, 01 Mar 2002 11:20:20 -0500
To: "Wijnen, Bert (Bert)" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: WG dcoument status 
Cc: "Yakov Rekhter" <[email-masked]>, "Kireeti Kompella" <[email-masked]>,<[email-masked]>

hmm,  looks like all that is missing is a formal statement on 4.
My guess is that just making a statement that one exists (and it does) 
isn't sufficient.  I volunteer to pull together an implementation 
report.  I'll send out a form later today, collect the info and post the 
results.

Lou

At 11:02 AM 3/1/2002, Wijnen, Bert (Bert) wrote:

>Mmm.. RFC1264 says on page 4, pls note items 4) and 5):
>
>
>   4.0 Requirements for Proposed Standard
>
>    1) Documents specifying the Protocol and its Usage.  The
>       specification for the routing protocol must be well written such
>       that independent, interoperable implementations can be developed
>       solely based on the specification.  For example, it should be
>       possible to develop an interoperable implementation without
>       consulting the original developers of the routing protocol.
>
>    2) A Management Information Base (MIB) must be written for the
>       protocol.  The MIB does not need to submitted for Proposed
>       Standard at the same time as the routing protocol, but must be
>       at least an Internet Draft.
>
>    3) The security architecture of the protocol must be set forth
>       explicitly.  The security architecture must include mechanisms for
>       authenticating routing messages and may include other forms of
>       protection.
>
>    4) One or more implementations must exist.
>
>    5) There must be evidence that the major features of the protocol
>       have been tested.
>
>    6) No operational experience is required for the routing protocol
>       at this stage in the standardization process.
>
>Bert
>
> > -----Original Message-----
> > From: Yakov Rekhter [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Friday, March 01, 2002 2:58 PM
> > To: Wijnen, Bert (Bert)
> > Cc: Kireeti Kompella; [email-masked]
> > Subject: Re: WG dcoument status
> >
>
>.. snip ..
>
> > > showing up.... In other words... it might be good if people start to
> > > report implementation and interoperability test reults.
> >
> > Please note that in the RTG area (rfc1264) there is no requirement
> > for a Proposed Standard to have (a) more than one implementation, and
> > (b) for these implementations to be interoperable.
> >
> > Yakov.
> >

Delivery-date: Fri, 01 Mar 2002 08:10:04 -0800
Date: Fri, 01 Mar 2002 11:08:25 -0500
To: [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02 
Cc: [email-masked], [email-masked], [email-masked]

>Eric/Shahram,  see addtional remarks below.  regards Neil
>
> > Shahram> 1) If a router  is not GTTP upgraded, it will  drop
> > the TTL expired
> > Shahram>    GTTP messages.  Consequently the host will not
> > receive any reply
> > Shahram>    from that router,  which translates to a break
> > in the tunnel at
> > Shahram>    that point.
> >
> > For GTTP to be useful at all, the tunnel head ends must support it.
> >
> > If a particular  node within a tunnel does not support  GTTP,
> > but some nodes
> > beyond  it do,  we won't  get complete  trace info,  but
> > should  be  able to
> > continue tracing beyond the non-supporting node.
> >
> > But the  basic point is valid,  that in order  to use GTTP to
> >  trace through
> > your network,  your routers must  support it.  I  guess I
> > don't see  this as
> > much of a problem.  I  wouldn't call it an interoperability
> > problem, because
> > no existing mechanisms are broken by the use of GTTP.
>NH=> If you noted in some of my earlier mails I was very careful to refer to
>'simple breaks' when using trail-trace type of mechanisms for defect
>diagnosis.  If you ever get a misbranching/mismerging defect then:
>-       you need to know it exists in the 1st place (not obvious how this
>can be done....with CV it's trivial, as you see the source ID of any
>offending LSP at the sink of the offended LSP, so you both detect/diagnose
>immediately)....I'll ignore the fact that a whole raft of consequent actions
>are also missing;

         Please clarify.

>-       since the location of such defects cannot be known a priori, then if
>you want the 'misbranched' GTTP messages to elicit a response then the
>arbitrary nodes where they end up must be able to respond......and in
>general this means the whole network/nodes need to be 'GTTP aware' and they
>need a return channel to the source.
>IMO any trail-trace functions are best used under the assumption that the
>network is actually defect-free.....we need other tools to detect/handle the
>defects (for the many reasons I tried to point out in earlier mails).
> >
> > Shahram> 2) TTL expired user packets will now be forwarded to
> > UDP module
> > Shahram>    instead of being dropped. Which could overload
> > the UDP module in
> > Shahram>    certain situations.
> >
> > TTL-expired user packets are not simply dropped today; they
> > are forwarded to
> > the ICMP module  to cause the generation of an  ICMP message.
> >  Usually there
> > is some sort of limit placed on the number of packets that
> > can be queued for
> > ICMP processing, or the  number of such packets that can be
> > seen in a given
> > amount of  time, etc.  The  marginal overhead to  see whether
> > a  packet that
> > makes it through to ICMP processing  is a GTTP packet doesn't
> > seem like that
> > big a deal.
>NH=> Asking ICMP to proxy for missing defect handling in MPLS is a
>possibility....and as Geroge hints in an earlier mail is actually an example
>of a layer violation, but so be it.  However, this should not be used in
>XoverMPLS....you need a solution here that is self-contained within the MPLS
>network.

         What is a "self-contained MPLS network"? MPLS networks require IP 
networks.
When running X over MPLS why does that requirement change at all?

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Fri, 01 Mar 2002 08:02:52 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: WG dcoument status 
Date: Fri, 1 Mar 2002 17:02:19 +0100 

Mmm.. RFC1264 says on page 4, pls note items 4) and 5):

  4.0 Requirements for Proposed Standard

   1) Documents specifying the Protocol and its Usage.  The
      specification for the routing protocol must be well written such
      that independent, interoperable implementations can be developed
      solely based on the specification.  For example, it should be
      possible to develop an interoperable implementation without
      consulting the original developers of the routing protocol.

   2) A Management Information Base (MIB) must be written for the
      protocol.  The MIB does not need to submitted for Proposed
      Standard at the same time as the routing protocol, but must be
      at least an Internet Draft.

   3) The security architecture of the protocol must be set forth
      explicitly.  The security architecture must include mechanisms for
      authenticating routing messages and may include other forms of
      protection.

   4) One or more implementations must exist.

   5) There must be evidence that the major features of the protocol
      have been tested.

   6) No operational experience is required for the routing protocol
      at this stage in the standardization process.

Bert 

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Friday, March 01, 2002 2:58 PM
> To: Wijnen, Bert (Bert)
> Cc: Kireeti Kompella; [email-masked]
> Subject: Re: WG dcoument status 
> 

.. snip ..

> > showing up.... In other words... it might be good if people start to
> > report implementation and interoperability test reults.
> 
> Please note that in the RTG area (rfc1264) there is no requirement
> for a Proposed Standard to have (a) more than one implementation, and
> (b) for these implementations to be interoperable.
> 
> Yakov.
> 

Envelope-to: [email-masked]
Delivery-date: Fri, 01 Mar 2002 08:01:13 -0800
Message-Id: <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-bonica-tunneltrace-02 
Date: Fri, 01 Mar 2002 11:00:40 -0500
From: George Swallow <[email-masked]>

> NH=> Asking ICMP to proxy for missing defect handling in MPLS is a
> possibility....and as Geroge hints in an earlier mail is actually an example
> of a layer violation, but so be it.  However, this should not be used in
> XoverMPLS....you need a solution here that is self-contained within the MPLS
> network.

Have we found the crux of the matter?  MPLS as defined by the IETF
(and I personally don't believe any other body has jurisdiction over
the core MPLS technology) requires that all boxes be IP capable.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Fri, 01 Mar 2002 07:58:24 -0800
From: "Mak, L (Leen)" <[email-masked]>
To: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Fri, 1 Mar 2002 16:57:40 +0100 

Let me make a Friday afternoon remark and than duck 
for the flak:

IMHO, the layering concept (and the associated system
of functional modelling) is to the study and design of
(circuit based) transport networks what the Periodic 
System of Elements is to chemistry.

Of course, you can do without, but with such an ordening 
principle the work in the field becomes a bit less intuitive 
and a bit more structured. If you like: less of an art and 
more of an engineering discipline. 

I'm afraid this does not progress the discussion on the 
bonica draft, but it might help getting the layering concept 
where it belongs ...

Leen Mak.

Envelope-to: [email-masked]
Delivery-date: Fri, 01 Mar 2002 07:18:57 -0800
Message-Id: <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-bonica-tunneltrace-02 
Date: Fri, 01 Mar 2002 10:17:16 -0500
From: George Swallow <[email-masked]>

> George....you are simply wrong here *if* applied architecturally correctly.

Some folks build architectures, others build boxes.

> But please explain/list examples of layer violations you are aware of.

RFC2390 (nee RFC1293) employed by a very large part of the commercial
world for the last decade.

> BTW - If anyone takes what you have written at face value then all tunnels
> should be banned, ie they are *all* layer violations (I see Shahram also

The point of my message is that "a layer violation" is not one of the
Ten Commandments nor part of Hammurabi's code.  It's simply an
engineering caveat of "beyond here, there be dragons".  One needs to
be very careful, but one needs also to be practical and cost
effective.

> [...]
> inadequacies in another layer)....but you'd need to think the consequences
> of that out very carefully and the potential implications before you take it
> further.

Yes!

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Fri, 01 Mar 2002 06:57:42 -0800
Date: Fri, 01 Mar 2002 09:20:11 -0500
From: Dongmei <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, "Mannie, Eric" <[email-masked]>, [email-masked], [email-masked], ccamp-wg <[email-masked]>, [email-masked]
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

--------------88721D24A8786D769D30348E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vote for 1.

-----Original Message-----

> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Sunday, February 24, 2002 7:11 PM
> To: Wijnen, Bert (Bert)
> Cc: Mannie, Eric; [email-masked]'; [email-masked]'; ccamp-wg;
> [email-masked]'
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
>
>
>
>
> On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:
>
> > Guys... I have seen to much of this. I have asked Kireeti
> > EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
> > WG mailing list. I do NOT want another 500 emails going back
> > and forth on this issue. We need to approach this pragmatically.
> >
> > - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the
> >   WG mailing list on what exactly we agreed in SLC. That will
> >   help to prepare a response to ITU-T as well
>
> First off, I should apologize for letting this go on unchecked.
>
> Second, I should make it known to the WG as a whole that there was
> a discussion of this issue at SLC among several folks directly
> involved, the ADs and the chairs.  I thought we had achieved
> consensus, but now it seems not.
>
> Here's what I thought we had agreed:
>
> 1) There is a document in the ITU that defines a *single* standard
> that
>    encompasses both SONET and SDH -- almost.  There are a few signals
>    that are in SONET but not in SDH; it was believed that the only
> such
>    signal was VC-3.  Also, there are "legacy" implementations of SONET
>
>    that do not match the ITU document.
>
> 2) Thus, it was agreed (to my recollection) that both the SONET and
>    SDH label formats will be retained, with wording that says that
>    whenever possible, the SDH equivalent should be used.  This covers
>    both the cases of SONET signals that don't have SDH equivalents,
>    and legacy equipment.
>
> It is *not* the IETF's intention to promote an artificial separation
> between SONET and SDH.  Nor is it the intent to promote as standard
> work that is now "pre-standard".
>
> However, it *is* the IETF's goal to be able to set up paths across
> SONET and SDH networks, and to be pragmatic about this.  This was
> the spirit in which an agreement was forged -- or so I thought.  In
> retrospect, it would have been wise to go one step further and
> decide the actual words.
>
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
>
> 1) Do you think we should have just a single set of traffic parameters
>
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
>
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
>
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
>
> Thanks,
> Kireeti.
>

--------------88721D24A8786D769D30348E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Vote for 1.
<p><font size=-1>-----Original Message-----</font>
<blockquote TYPE=CITE><font size=-1>From: Kireeti Kompella [<a href="mailto:[email-masked]">mailto:[email-masked]</a>]</font>
<br><font size=-1>Sent: Sunday, February 24, 2002 7:11 PM</font>
<br><font size=-1>To: Wijnen, Bert (Bert)</font>
<br><font size=-1>Cc: Mannie, Eric; [email-masked]'; [email-masked]';
ccamp-wg;</font>
<br><font size=-1>[email-masked]'</font>
<br><font size=-1>Subject: RE: SONET/SDH label agreement for IETF, ITU-T
and OIF</font>
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p><font size=-1>On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:</font>
<p><font size=-1>> Guys... I have seen to much of this. I have asked Kireeti</font>
<br><font size=-1>> EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS
on the</font>
<br><font size=-1>> WG mailing list. I do NOT want another 500 emails going
back</font>
<br><font size=-1>> and forth on this issue. We need to approach this pragmatically.</font>
<br><font size=-1>></font>
<br><font size=-1>> - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT
on the</font>
<br><font size=-1>>&nbsp;&nbsp; WG mailing list on what exactly we agreed
in SLC. That will</font>
<br><font size=-1>>&nbsp;&nbsp; help to prepare a response to ITU-T as
well</font>
<p><font size=-1>First off, I should apologize for letting this go on unchecked.</font>
<p><font size=-1>Second, I should make it known to the WG as a whole that
there was</font>
<br><font size=-1>a discussion of this issue at SLC among several folks
directly</font>
<br><font size=-1>involved, the ADs and the chairs.&nbsp; I thought we
had achieved</font>
<br><font size=-1>consensus, but now it seems not.</font>
<p><font size=-1>Here's what I thought we had agreed:</font>
<p><font size=-1>1) There is a document in the ITU that defines a *single*
standard that</font>
<br><font size=-1>&nbsp;&nbsp; encompasses both SONET and SDH -- almost.&nbsp;
There are a few signals</font>
<br><font size=-1>&nbsp;&nbsp; that are in SONET but not in SDH; it was
believed that the only such</font>
<br><font size=-1>&nbsp;&nbsp; signal was VC-3.&nbsp; Also, there are "legacy"
implementations of SONET</font>
<br><font size=-1>&nbsp;&nbsp; that do not match the ITU document.</font>
<p><font size=-1>2) Thus, it was agreed (to my recollection) that both
the SONET and</font>
<br><font size=-1>&nbsp;&nbsp; SDH label formats will be retained, with
wording that says that</font>
<br><font size=-1>&nbsp;&nbsp; whenever possible, the SDH equivalent should
be used.&nbsp; This covers</font>
<br><font size=-1>&nbsp;&nbsp; both the cases of SONET signals that don't
have SDH equivalents,</font>
<br><font size=-1>&nbsp;&nbsp; and legacy equipment.</font>
<p><font size=-1>It is *not* the IETF's intention to promote an artificial
separation</font>
<br><font size=-1>between SONET and SDH.&nbsp; Nor is it the intent to
promote as standard</font>
<br><font size=-1>work that is now "pre-standard".</font>
<p><font size=-1>However, it *is* the IETF's goal to be able to set up
paths across</font>
<br><font size=-1>SONET and SDH networks, and to be pragmatic about this.&nbsp;
This was</font>
<br><font size=-1>the spirit in which an agreement was forged -- or so
I thought.&nbsp; In</font>
<br><font size=-1>retrospect, it would have been wise to go one step further
and</font>
<br><font size=-1>decide the actual words.</font>
<p><font size=-1>So, here we are again, arguing over this.&nbsp; Let's
follow the AD's</font>
<br><font size=-1>suggestion and look for consensus in the WG.</font>
<p><font size=-1>1) Do you think we should have just a single set of traffic
parameters</font>
<br><font size=-1>&nbsp;&nbsp; and label values for SDH, and none for SONET?</font>
<br><font size=-1>or</font>
<br><font size=-1>2) Do you think we should have one for SONET and one
for SDH, with</font>
<br><font size=-1>&nbsp;&nbsp; the proviso that, if an SDH equivalent is
available, one SHOULD</font>
<br><font size=-1>&nbsp;&nbsp; use the SDH equivalent?</font>
<br><font size=-1>or</font>
<br><font size=-1>3) Do you think we should have one for SONET and one
for SDH, with</font>
<br><font size=-1>&nbsp;&nbsp; the proviso that, if an SDH equivalent is
available, one MUST</font>
<br><font size=-1>&nbsp;&nbsp; use the SDH equivalent?</font>
<p><font size=-1>(in the above, SHOULD and MUST are to be interpreted as
in RFC 2119.)</font>
<p><font size=-1>PLEASE respond with just (1), (2) or (3), and avoid long
diatribes!</font>
<p><font size=-1>Feedback is welcome from *all* those interested in the
CCAMP WG.</font>
<br><font size=-1>Also, what we are looking for is rough consensus, not
votes.</font>
<p><font size=-1>Thanks,</font>
<br><font size=-1>Kireeti.</font>
<br>&nbsp;</blockquote>
</html>

--------------88721D24A8786D769D30348E--

Delivery-date: Fri, 01 Mar 2002 06:55:43 -0800
Date: Fri, 01 Mar 2002 10:06:09 -0500
From: Guangzhi Li <[email-masked]>
Cc: "ccamp-wg <ccamp" <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

(1) is better.

-- Guangzhi

Diego Caviglia wrote:

> I do agree with Jennifer.
>
> My vote is (1).
>
> Diego.
>
> Jennifer Yates <[email-masked]>@ops.ietf.org on 01/03/2002
> 15.16.27
>
> Sent by:  [email-masked]
>
> To:   "Wijnen, Bert (Bert)" <[email-masked]>
> cc:   ccamp-wg <[email-masked]>
>
> Subject:  Re: SONET/SDH label agreement for IETF, ITU-T and OIF
>
> My vote is for (1).
>
> Jen
>
> "Wijnen, Bert (Bert)" wrote:
>
> > CCAMP WG members,
> >
> > before we start down another many 100s of emails re-discussing
> > the same topic....
> >
> > PLEASE express your support for one of the 3 options that Kireeti
> > posed to the WG. Don't elaborate... just help the WG chair(s) to
> > figure out the (rough) consensus of the WG. The choices formulated
> > by Kireeti:
> >
> > > So, here we are again, arguing over this.  Let's follow the AD's
> > > suggestion and look for consensus in the WG.
> > >
> > > 1) Do you think we should have just a single set of traffic parameters
> > >    and label values for SDH, and none for SONET?
> > > or
> > > 2) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one SHOULD
> > >    use the SDH equivalent?
> > > or
> > > 3) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one MUST
> > >    use the SDH equivalent?
> > >
> > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> > >
> > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> >
> > Thanks
> > Bert, speaking as AD who would like to see the WG take
> >       a decision on this topic.

Delivery-date: Fri, 01 Mar 2002 06:46:08 -0800
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF
To: "ccamp-wg <ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Fri, 1 Mar 2002 15:45:08 +0100

I do agree with Jennifer.

My vote is (1).

Diego.

Jennifer Yates <[email-masked]>@ops.ietf.org on 01/03/2002
15.16.27

Sent by:  [email-masked]

To:   "Wijnen, Bert (Bert)" <[email-masked]>
cc:   ccamp-wg <[email-masked]>

Subject:  Re: SONET/SDH label agreement for IETF, ITU-T and OIF

My vote is for (1).

Jen

"Wijnen, Bert (Bert)" wrote:

> CCAMP WG members,
>
> before we start down another many 100s of emails re-discussing
> the same topic....
>
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
>
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
> Thanks
> Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

Delivery-date: Fri, 01 Mar 2002 06:44:02 -0800
From: [email-masked]
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF
To: [email-masked], [email-masked]
Date: Fri, 1 Mar 2002 15:43:34 +0100

My preference would go to option (2).

Bart.

"Wijnen, Bert (Bert)" wrote:

> CCAMP WG members,
>
> before we start down another many 100s of emails re-discussing
> the same topic....
>
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
>
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
> Thanks
> Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

Delivery-date: Fri, 01 Mar 2002 06:37:14 -0800
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
To: "ccamp-wg <ccamp" <[email-masked]>
Cc: "Kireeti Kompella <kireeti" <[email-masked]>
From: "Mario Molinari" <[email-masked]>
Date: Fri, 1 Mar 2002 15:35:54 +0100

If I'm not too late, I'd like to express my vote for (1).

Mario

Kireeti Kompella <[email-masked]>@ops.ietf.org on 25/02/2002 01.10.36

Sent by:  [email-masked]

To:   "Wijnen, Bert (Bert)" <[email-masked]>
cc:   "Mannie, Eric" <[email-masked]>, "[email-masked]'"
      <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg
      <[email-masked]>, "[email-masked]'" <[email-masked]>

Subject:  RE: SONET/SDH label agreement for IETF, ITU-T and OIF

On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:

> Guys... I have seen to much of this. I have asked Kireeti
> EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
> WG mailing list. I do NOT want another 500 emails going back
> and forth on this issue. We need to approach this pragmatically.
>
> - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the
>   WG mailing list on what exactly we agreed in SLC. That will
>   help to prepare a response to ITU-T as well

First off, I should apologize for letting this go on unchecked.

Second, I should make it known to the WG as a whole that there was
a discussion of this issue at SLC among several folks directly
involved, the ADs and the chairs.  I thought we had achieved
consensus, but now it seems not.

Here's what I thought we had agreed:

1) There is a document in the ITU that defines a *single* standard that
   encompasses both SONET and SDH -- almost.  There are a few signals
   that are in SONET but not in SDH; it was believed that the only such
   signal was VC-3.  Also, there are "legacy" implementations of SONET
   that do not match the ITU document.

2) Thus, it was agreed (to my recollection) that both the SONET and
   SDH label formats will be retained, with wording that says that
   whenever possible, the SDH equivalent should be used.  This covers
   both the cases of SONET signals that don't have SDH equivalents,
   and legacy equipment.

It is *not* the IETF's intention to promote an artificial separation
between SONET and SDH.  Nor is it the intent to promote as standard
work that is now "pre-standard".

However, it *is* the IETF's goal to be able to set up paths across
SONET and SDH networks, and to be pragmatic about this.  This was
the spirit in which an agreement was forged -- or so I thought.  In
retrospect, it would have been wise to go one step further and
decide the actual words.

So, here we are again, arguing over this.  Let's follow the AD's
suggestion and look for consensus in the WG.

1) Do you think we should have just a single set of traffic parameters
   and label values for SDH, and none for SONET?
or
2) Do you think we should have one for SONET and one for SDH, with
   the proviso that, if an SDH equivalent is available, one SHOULD
   use the SDH equivalent?
or
3) Do you think we should have one for SONET and one for SDH, with
   the proviso that, if an SDH equivalent is available, one MUST
   use the SDH equivalent?

(in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)

PLEASE respond with just (1), (2) or (3), and avoid long diatribes!

Feedback is welcome from *all* those interested in the CCAMP WG.
Also, what we are looking for is rough consensus, not votes.

Thanks,
Kireeti.

Delivery-date: Fri, 01 Mar 2002 06:36:13 -0800
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF
To: "Wijnen, Bert (Bert)" <[email-masked]>, ccamp-wg <[email-masked]>
From: [email-masked]
Date: Fri, 1 Mar 2002 15:34:19 +0100

My preference would go to option (2).

Sven.

Jennifer Yates <[email-masked]> on 01/03/2002 15:16:27

                                                              
  To:          "Wijnen, Bert (Bert)" <[email-masked]>     
                                                              
  cc:          ccamp-wg <[email-masked]>(bcc: Sven VAN    
               DEN BOSCH/BE/ALCATEL)                          

                                                              
  Subject      Re: SONET/SDH label agreement for IETF, ITU-T  
  :            and OIF                                        

My vote is for (1).

Jen

"Wijnen, Bert (Bert)" wrote:

> CCAMP WG members,
>
> before we start down another many 100s of emails re-discussing
> the same topic....
>
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
>
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
> Thanks
> Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

Delivery-date: Fri, 01 Mar 2002 06:28:47 -0800
From: "Brian Moore" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-bonica-tunneltrace-02
Date: Fri, 1 Mar 2002 09:29:28 -0000

[ post by non-subscriber ]

Neil,
Just to let you know that we (SG13) have set up an ftp site to allow us to
share documents with our IETF colleagues. The process for registering for
access is described on the site
(http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.html).
The draft Rec Y.1711 is on the site.
Brian.

B W Moore
Lucent Technologies
[email-masked]
Tel: +44 1206 762335
Fax: +44 1206 762336
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, February 28, 2002 10:08 PM
Subject: RE: draft-bonica-tunneltrace-02

> Thanks Steve....nice to hear a voice of sanity.
>
> Just FYI.....many people from various IETF lists have privately asked me
for
> copies of Y.1711 (and/or Y.1710 - requirements/principles) and I have have
> passed them on.  Also SG13 have sent formal liaisons to IETF/ATMF/MPLSF on
> these already.  If anyone else wants a copy until such time they become
> publically available please ask me and I'll do my best to post on.....but
be
> prepared for a little delay as I'll be travelling from tomorrow for a week
> or so.
>
> As an aside.....this ITU/IETF bickering is really helping nobody here.
Each
> side can learn from the other.  I get really sad when I see destructive
> comments about the G.805 layering/partitioning arch
> stuff......why?....because its how we all actually work even if some of us
> don't actually consciously recognise it.  G.805 just gives it a formal
> base....and its a damn sight more useful than the almost useless L1/2/3
> classifications (which mean nothing) and the OSI model which gives the
> illusion there is only *one* layer network (at L3, OSI sense)....absolute
> bunkum.  G.805 matches reality.  Give it a shot.
>
> regards, Neil
>
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: 28 February 2002 17:28
> > To: Shahram Davari
> > Cc: [email-masked]'; 'Randy Bush'; Cuevas, Enrique G, ALASO;
> > [email-masked]; Brian Moore
> > Subject: Re: draft-bonica-tunneltrace-02
> >
> >
> > (snip)
> > > Why? Simply because it is produced by ITU is not a logical
> > way to dismiss it.
> > > Do you think the ITU architecture is wrong and if so why?
> > and what architecture
> > > (if any!) do you suggest that the requirements and
> > solutions should fit in to?
> > ITU and IETF do have a formal cooperation agreement. This
> > does not mean that
> > either organization needs to do what the other says, but in
> > the event IETF were
> > to choose to diverge, it would at least be polite to send a
> > communication to
> > the relevante ITU-T study group (in this case, SG13) to
> > indicate why. ITU-T
> > input should at least be given serious consideration.
> >
> > > As has been stated these are to a
> > > large extent documented in the (sadly too new to get at for
> > free) documents
> > > Y.1711/Y.1710 but were in the now expired though surely google-able
> > > draft-harrison...
> > My understanding is that these should be made available to
> > IETF through a
> > public ftp site in the next few days. Material from Study
> > Group 15 has been
> > shared in this way in the past. A similar mechanism is now
> > being set up for
> > Study Group 13.
> >
> > Regards,
> > Steve Trowbridge
> >
>

Delivery-date: Fri, 01 Mar 2002 06:19:54 -0800
Date: Fri, 01 Mar 2002 09:16:27 -0500
From: Jennifer Yates <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

My vote is for (1).

Jen

"Wijnen, Bert (Bert)" wrote:

> CCAMP WG members,
>
> before we start down another many 100s of emails re-discussing
> the same topic....
>
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
>
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
> Thanks
> Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

Delivery-date: Fri, 01 Mar 2002 06:02:46 -0800
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: WG dcoument status 
Date: Fri, 01 Mar 2002 05:58:16 -0800
From: Yakov Rekhter <[email-masked]>

Bert,

> > Bert Wijnen (AD) has suggested that there should be an implementation
> > statement before these move on to IETF Last Call; the WG chairs and
> > draft editors agreed.
> 
> Pls note that we discussed this in the SUB-IP Directorate and that a
> wider set of people agreed. The reason why we do this is based on earlier
> practice in the RTG area in that a protocol that touches the core of the
> network, that we do want to see implementation/interoperability reports
> at the PS stage as opposed to at the DS stage.
> 
> This report is to be prepared by the WG (chairs). And it needs to be sent
> to iesg-secretary who will put it online on the IETF webpages, so that
> during IETF Last Call people can actually look at the reports.
> 
> Please also not that some people worred (back at SLC meeting) that this
> might delay the docs too much. I would like to remind you that it is now
> 2.5 months later, and I have still not seen any signs of such a report.
> So don't blame the process if things get delayed because of a report not
> showing up.... In other words... it might be good if people start to
> report implementation and interoperability test reults.

Please note that in the RTG area (rfc1264) there is no requirement
for a Proposed Standard to have (a) more than one implementation, and
(b) for these implementations to be interoperable.

Yakov.

Delivery-date: Fri, 01 Mar 2002 00:34:54 -0800
Date: Fri, 01 Mar 2002 09:32:59 +0100
From: Loa Andersson <[email-masked]>
To: David Allan <[email-masked]>
CC: [email-masked], Shahram Davari <[email-masked]>, 'Randy Bush' <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

David Allan wrote:

> Loa:
> 
> First observation is that this has gone on way too long. T'would be nice 
> to see the chairs or ADs make a decision as to whether consensus exists 
> in one direction or another.

seem like a good idea!

/Loa

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se