Subject: RE: draft-ietf-ccamp-tracereq
From: Ron Bonica <[email-masked]>
To: Xiaoming Fu <[email-masked]>
Cc: [email-masked]
Date: Sat, 31 May 2003 12:51:05 -0400

Xiaoming,

Thanks for the thorough review. A new version of the draft is available at
http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-04.txt.

                              Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Xiaoming Fu
> Sent: Friday, May 30, 2003 7:20 PM
> To: Ron Bonica
> Cc: [email-masked]
> Subject: Re: draft-ietf-ccamp-tracereq
>
>
> Ron,
>
> It is a nice document. I went it through and have a few comments:
>
> - Section 3, 9) - "forwarding plane failu res" ==> _failures_

Oops....

>
> - I didn't understand why the following paragraph appears twice - the
>    same in Section 3, 13) and 14). I assume you're talking about control
>    plane failure in 13).
>        Justification: MTU information is sometimes useful in identifying
>        the root cause of forwarding plane failures.

You have a point. MTU information, in either direction, can be useful in
debugging
both control and forwarding plane failures. The paragraph should read as
follows in
both 3.13 and 3.14:

Justification: MTU information is sometimes useful in identifying
the root cause of forwarding and control plane failures.

>
> - Again, Section 3, 14):
>        14) When tracing through the forwarding plane, display the MTU
>        associated with each hop in the reverse direction.
>    Meanwhile, in Section 4.3:
>        The protocol must be stateless. That is, nodes should not have to
>        maintain state between successive traceroute messages.
>    Are you assuming the probe and response messages are always hop-by-hop
>    addressed? Otherwise, the forwarding and reverse paths of transporting
>    the probe & response pair could differ, e.g., due to the Internet
>    routing, or policies. And -
>    Do we need a same transport path for them? If so, how a stateless
>    traceroute protocol knows the reverse path to forward the response
>    message?  Probably we could create a temporary state while handling a
>    probe message, to include P_HOP & Interface information like in RSVP,
>    although the state is used only once in this case.

Requirements 13 and 14 are ambiguous. As a result, you have interpretted
them
in a manner that was not intended. They should be restated as follows:

13) When tracing through the control plane, display the MTU associated with
interface
that forwards datagrams through the traced path.

14) When tracing through the forwarding plane, display the MTU associated
with each
interface that receives datagtrams along the traced path.

>
> - Section 4.1 - I don't understand the following sentense:
>                               Many network forward datagrams that specify
>      IP options differently than they would forward datagrams that do not
>      specify IP options.
>    Maybe they ==> them, but the implication of this sentense is still
>    unclear to me.

This paragraph should read as follows:

Many networks forward datagrams that specify IP options differently than
they would forward datagrams that do not specify IP options. Therefore,
the introductions of IP options would cause the application to trace a
forwarding path other than the path that its user intended to trace.

>
> - Section 4.2 "IP was _disqualified_ in order to conserve protocol
>     identifiers." - I'm not sure this is always valid. Anyway,
>     using UDP would have also to request a port number from IANA; there
>     is actually a tradeoff among protocol_ID v.s. port number v.s. ICMP
>     type. BTW, UDP may introduce a little (although minor)
>     additional overhead.

IANA is much more willing to assign UDP port numbers than protocol-IDs.
This is because there are so many more UDP port numbers available.

>
> - In general I would expect the document would not constrain too much
>    on protocol details - the latter looks to me more of a protocol
>    design issue, instead of an informational RFC on "requirement".

In principle, I agree. Section 4 provides just enough protocol requirements
to keep protocol designers away from some known bad design approaches. For
example,
years ago we tried returning MPLS information in ICMP datagrams. This wasn't
well received. So, the requirements document guides us around that bad
approach.

>
> - It looks better if an experimental traceroute protocol (RFC1393 -
>    traceroute using an IP option) would be referenced and shortly
>    introduced in Section 2 (e.g., MTU determination).

I thought about referencing RFC 1393 but decided not to because it is not
widely known or implemented.

                                             Ron

>
> My 2 cents.
>
> Xiaoming
>
> Ron Bonica wrote:
> > Folks,
> >
> > At the request of the IESG, I have updated draft-ietf-ccamp-tracereq and
> > sent a new copy to the draft editor. Until the draft editor
> posts it, a copy
> > can be found at
http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-03.txt.
>
> Please take a look, as this draft will need to go through another WG last
> call.
>
> ===========================================
> Ronald P. Bonica       Ph: 703 886 1681
> vBNS Engineering       page: 1 888 268 8021
> Ashburn, Va.
> ===========================================
> "We are not on Earth to guard a museum, but
> to cultivate a flourishing garden of life."
>                 -- Angelo Giuseppe Roncalli
>
>

--
Xiaoming Fu
University of Goettingen, Telematics Group
Lotzestr. 16-18, 37083 Goettingen, Germany
Tel.+49-551-39 14411, Fax.+49-551-39 14403
http://www.ifi.informatik.uni-goettingen.de

Delivery-date: Sat, 31 May 2003 07:22:22 +0000
Date: Sat, 31 May 2003 00:21:02 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Adrian Farrel <[email-masked]>
cc: [email-masked]
Subject: Re: ASON reqts - Moving on?

On Wed, 14 May 2003, Adrian Farrel wrote:

> Kireeti, what are the next steps?

Sorry that this has been so long.

First of all, there is good consensus to make the ASON requirements
doc (draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt) a CCAMP WG
document.  Authors, please resubmit it as a WG document.

However, the ADs, seeing signs of World War III on this list for the
umpteenth time, want to be clear where this is going.  The rules of
engagement are:

1) We *really* need to make sure that the ITU is in the loop on this --
   that they tell us when we get things wrong or we miss things, and
   participate actively in reviewing the document.  Fortunately, the
   draft is based on work done by folks active in the ITU, so we
   should have a good start; but we need to keep that up.  If this
   means regular Liaison statements back and forth, so be it.
2) Regarding whether this work falls under the purview of CCAMP,
   CCAMP's charter is to "define signalling protocols and measurement
   protocols such that they support ... O-O and O-E-O optical switches",
   i.e., optical networks, and ASON is a very important example of an
   optical network.
3) It is thus incumbent on us as a group to define the requirements,
   and see whether GMPLS measures up; if so, document that; and if not,
   decide what needs to be done.
4) Let's do this with grace -- no inter-SDO or any other kind of egg
   throwing.  It might be less fun that way, but it is definitely
   more productive.

Since we are going down this path, I guess I should address Steve's
questions re motivations for this document:

| 5. Those who think that ITU-T didn't get the requirements right, so we
|    need to look at everything from scratch.

This is explicitly *not* the intent.  A requirement goes into this
document iff:
  (a) the ITU-T says, "Yes, that's a requirement for ASON signaling"; and
  (b) CCAMP and the ITU-T agree that GMPLS doesn't meet it.

Requirements that are already met MAY be documented, but it is not a
goal to capture all ASON requirements.

Kireeti.

Delivery-date: Sat, 31 May 2003 05:42:07 +0000
Date: Fri, 30 May 2003 22:40:05 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Time slots for CCAMP 57

Hi,

Please submit your requests for time slots for the CCAMP meeting
at the 57th IETF to Ron and me.

Note that to get a time slot, you MUST have submitted a draft by
the draft deadline (June 30, 9:00AM ET).  Furthermore, these time
slots are for discussing and resolving issues raised on the mailing
list, or for first time drafts, a *very* brief overview of the idea,
why it's relevant, and how it fits into the CCAMP charter.  No
presentations!

If you request a time slot, please follow up and start an email
discussion on the CCAMP list.

Thanks,
Kireeti.

Delivery-date: Sat, 31 May 2003 01:57:15 +0000
Date: Fri, 30 May 2003 18:55:31 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>
cc: [email-masked], Stephen Trowbridge <[email-masked]>, "Wijnen, Bert" <[email-masked]>, "" <[email-masked]>, "Ronald P. Bonica" <[email-masked]>, "'Lam, Hing-Kam (Kam)'" <[email-masked]>
Subject: RE: ASON RSVP-TE extensions

On Fri, 30 May 2003, Ong, Lyndon wrote:

> The cutoff for uploading documents for the ITU meeting in
> Chicago is this Monday - given the short time I wonder if
> you couldn't just submit this as a contribution from
> yourself and Ron as co-chairs of CCAMP (considering that
> you were invited to participate).  I'm copying this to
> Kam Lam as well for his feedback.

Good idea.  I'll wait till Monday, and if I don't see any feedback,
I will send formally to Kam Lam so that I can present it there.  As
for a formal Liaison, we can send that when the CCAMP WG has converged
on the text.

Kireeti.

Delivery-date: Fri, 30 May 2003 23:34:55 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, [email-masked]
Cc: Stephen Trowbridge <[email-masked]>, "Wijnen, Bert" <[email-masked]>, [email-masked], "Ronald P. Bonica" <[email-masked]>, "'Lam, Hing-Kam (Kam)'" <[email-masked]>
Subject: RE: ASON RSVP-TE extensions
Date: Fri, 30 May 2003 16:37:46 -0700

Hi Kireeti,

The cutoff for uploading documents for the ITU meeting in
Chicago is this Monday - given the short time I wonder if 
you couldn't just submit this as a contribution from 
yourself and Ron as co-chairs of CCAMP (considering that
you were invited to participate).  I'm copying this to
Kam Lam as well for his feedback.

Cheers,

Lyndon

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Friday, May 30, 2003 3:46 PM
To: [email-masked]
Cc: Stephen Trowbridge; Wijnen, Bert; [email-masked]; Ronald P. Bonica;
Kireeti Kompella
Subject: ASON RSVP-TE extensions

Hi All,

We would like to send the following as a Liaison to the ITU-T from
the CCAMP WG.

Please comment on the text.  Ideally, we would like to send this out
before the interim meeting in Chicago, and discuss it there.

It would be helpful in this context to know what it means procedurally
that a document "has been consented" in the ITU.

Kireeti.
----------------------------------------------------------------------
 To: ...
 From: ...

Following up on the code point allocations in RFC 3474, we (the CCAMP
WG) seek clarification on some further points.

Regarding the following paragraph in the Introduction of the
pre-publication draft of RFC 3474 which reads:

   Note that from the perspective of the ASON model ResvErr and ResvTear
   messages are not used. For backwards compatibility, when an ASON-
   compliant GMPLS node receives either a ResvErr or ResvTear as a
   response during the setup phase of message exchange, the GMPLS-ASON
   node should instead issue a PathTear message downstream and a PathErr
   (with Path_State_Removed flag set) message upstream. This is so that
   RSVP states are immediately removed upon error during the setup
   process.

Removing this is a vital step in keeping the base semantics of the
RSVP protocol intact.  In particular, it would be unexpected and
possibly fatal if as a consequence of a node issuing a ResvErr (and
expecting the removal of Resv state alone), Path state were to be
removed as well due to the "translation" of a ResvErr to a PathErr
(with Path_State_Removed flag set) plus a PathTear.  We thank you
that you did so in RFC 3474 prior to publication.

We understand that RFC 3474 is based in part on G.7713.2.  In G.7713.2,
we see no similar paragraph.  The closest is the following, from
Appendix III Protocol Elements Not Used (p. 46), which says in part:

- ResvErr

  This message is modified from definitions in RFC 2205 and RFC 2961,
  with further extensions to support distributed connection management.
  This message is used to

  - Respond to a Resv connection setup request (when encountering problems
    with setup); however, note that in the GMPLS implementation where a
    connection setup error requires releasing the connection, and since
    ResvErr does not remove Path states, the PathTear is used for GMPLS
    connection-oriented network to remove Path states, i.e., ResvErr is
    not used during setup and release.

G.7713.2 is silent on what is to be done if an implementation were in
fact to receive a ResvErr or ResvTear message.  We believe the
Recommendation is incomplete without describing what should happen in
this event.  Is it intended that the behaviour of a node receiving a
ResvErr/ResvTear be left unspecified, or is an explicit statement is
forthcoming?

Sincerely,
Ronald Bonica and
Kireeti Kompella,
CCAMP WG chairs

Delivery-date: Fri, 30 May 2003 23:21:42 +0000
Date: Sat, 31 May 2003 01:19:48 +0200
From: Xiaoming Fu <[email-masked]>
To: Ron Bonica <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-ccamp-tracereq

Ron,

It is a nice document. I went it through and have a few comments:

- Section 3, 9) - "forwarding plane failu res" ==> _failures_

- I didn't understand why the following paragraph appears twice - the
   same in Section 3, 13) and 14). I assume you're talking about control
   plane failure in 13).
       Justification: MTU information is sometimes useful in identifying
       the root cause of forwarding plane failures.

- Again, Section 3, 14):
       14) When tracing through the forwarding plane, display the MTU
       associated with each hop in the reverse direction.
   Meanwhile, in Section 4.3:
       The protocol must be stateless. That is, nodes should not have to
       maintain state between successive traceroute messages.
   Are you assuming the probe and response messages are always hop-by-hop
   addressed? Otherwise, the forwarding and reverse paths of transporting
   the probe & response pair could differ, e.g., due to the Internet
   routing, or policies. And -
   Do we need a same transport path for them? If so, how a stateless
   traceroute protocol knows the reverse path to forward the response
   message?  Probably we could create a temporary state while handling a
   probe message, to include P_HOP & Interface information like in RSVP,
   although the state is used only once in this case.

- Section 4.1 - I don't understand the following sentense:
                              Many network forward datagrams that specify
     IP options differently than they would forward datagrams that do not
     specify IP options.
   Maybe they ==> them, but the implication of this sentense is still
   unclear to me.

- Section 4.2 "IP was _disqualified_ in order to conserve protocol
    identifiers." - I'm not sure this is always valid. Anyway,
    using UDP would have also to request a port number from IANA; there
    is actually a tradeoff among protocol_ID v.s. port number v.s. ICMP
    type. BTW, UDP may introduce a little (although minor)
    additional overhead.

- In general I would expect the document would not constrain too much
   on protocol details - the latter looks to me more of a protocol
   design issue, instead of an informational RFC on "requirement".

- It looks better if an experimental traceroute protocol (RFC1393 -
   traceroute using an IP option) would be referenced and shortly
   introduced in Section 2 (e.g., MTU determination).

My 2 cents.

Xiaoming

Ron Bonica wrote:
> Folks,
> 
> At the request of the IESG, I have updated draft-ietf-ccamp-tracereq and
> sent a new copy to the draft editor. Until the draft editor posts it, a copy
> can be found at http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-03.txt.
> 
> Please take a look, as this draft will need to go through another WG last
> call.
> 
> ===========================================
> Ronald P. Bonica       Ph: 703 886 1681
> vBNS Engineering       page: 1 888 268 8021
> Ashburn, Va.
> ===========================================
> "We are not on Earth to guard a museum, but
> to cultivate a flourishing garden of life."
>                 -- Angelo Giuseppe Roncalli
> 
> 

-- 
Xiaoming Fu
University of Goettingen, Telematics Group
Lotzestr. 16-18, 37083 Goettingen, Germany
Tel.+49-551-39 14411, Fax.+49-551-39 14403
http://www.ifi.informatik.uni-goettingen.de

Delivery-date: Fri, 30 May 2003 22:48:43 +0000
Date: Fri, 30 May 2003 15:45:35 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
cc: Stephen Trowbridge <[email-masked]>, "Wijnen, Bert" <[email-masked]>, "" <[email-masked]>, "Ronald P. Bonica" <[email-masked]>, Kireeti Kompella <[email-masked]>
Subject: ASON RSVP-TE extensions

Hi All,

We would like to send the following as a Liaison to the ITU-T from
the CCAMP WG.

Please comment on the text.  Ideally, we would like to send this out
before the interim meeting in Chicago, and discuss it there.

It would be helpful in this context to know what it means procedurally
that a document "has been consented" in the ITU.

Kireeti.
----------------------------------------------------------------------
 To: ...
 From: ...

Following up on the code point allocations in RFC 3474, we (the CCAMP
WG) seek clarification on some further points.

Regarding the following paragraph in the Introduction of the
pre-publication draft of RFC 3474 which reads:

   Note that from the perspective of the ASON model ResvErr and ResvTear
   messages are not used. For backwards compatibility, when an ASON-
   compliant GMPLS node receives either a ResvErr or ResvTear as a
   response during the setup phase of message exchange, the GMPLS-ASON
   node should instead issue a PathTear message downstream and a PathErr
   (with Path_State_Removed flag set) message upstream. This is so that
   RSVP states are immediately removed upon error during the setup
   process.

Removing this is a vital step in keeping the base semantics of the
RSVP protocol intact.  In particular, it would be unexpected and
possibly fatal if as a consequence of a node issuing a ResvErr (and
expecting the removal of Resv state alone), Path state were to be
removed as well due to the "translation" of a ResvErr to a PathErr
(with Path_State_Removed flag set) plus a PathTear.  We thank you
that you did so in RFC 3474 prior to publication.

We understand that RFC 3474 is based in part on G.7713.2.  In G.7713.2,
we see no similar paragraph.  The closest is the following, from
Appendix III Protocol Elements Not Used (p. 46), which says in part:

- ResvErr

  This message is modified from definitions in RFC 2205 and RFC 2961,
  with further extensions to support distributed connection management.
  This message is used to

  - Respond to a Resv connection setup request (when encountering problems
    with setup); however, note that in the GMPLS implementation where a
    connection setup error requires releasing the connection, and since
    ResvErr does not remove Path states, the PathTear is used for GMPLS
    connection-oriented network to remove Path states, i.e., ResvErr is
    not used during setup and release.

G.7713.2 is silent on what is to be done if an implementation were in
fact to receive a ResvErr or ResvTear message.  We believe the
Recommendation is incomplete without describing what should happen in
this event.  Is it intended that the behaviour of a node receiving a
ResvErr/ResvTear be left unspecified, or is an explicit statement is
forthcoming?

Sincerely,
Ronald Bonica and
Kireeti Kompella,
CCAMP WG chairs

Delivery-date: Fri, 30 May 2003 11:14:59 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g709-04.txt
Date: Fri, 30 May 2003 07:13:01 -0400

--NextPart

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

	Title		: Generalized MPLS Signalling Extensions for G.709 
                          Optical Transport Networks Control
	Author(s)	: D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-g709-04.txt
	Pages		: 21
	Date		: 2003-5-29
	
This document is a companion to the Generalized MPLS (GMPLS)
signalling documents. It describes the 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-ietf-ccamp-gmpls-g709-04.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-g709-04.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-g709-04.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 30 May 2003 11:14:50 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt
Date: Fri, 30 May 2003 07:13:05 -0400

--NextPart

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

	Title		: SONET/SDH Encoding for Link Management Protocol (LMP) 
                          Test messages
	Author(s)	: J. Lang, D. Papadimitriou
	Filename	: draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt
	Pages		: 15
	Date		: 2003-5-29
	
This document details the Synchronous Optical NETwork (SONET)/ 
Synchronous Digital Hierarchy (SDH) technology specific information 
needed when sending Link Management Protocol (LMP) test messages.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-test-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: Fri, 30 May 2003 03:37:16 +0000
Date: Thu, 29 May 2003 23:32:25 -0400
From: Ron Bonica <[email-masked]>
Subject: draft-ietf-ccamp-tracereq
To: [email-masked]

Folks,

At the request of the IESG, I have updated draft-ietf-ccamp-tracereq and
sent a new copy to the draft editor. Until the draft editor posts it, a copy
can be found at http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-03.txt.

Please take a look, as this draft will need to go through another WG last
call.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"We are not on Earth to guard a museum, but
to cultivate a flourishing garden of life."
                -- Angelo Giuseppe Roncalli

Delivery-date: Thu, 29 May 2003 15:12:01 +0000
Date: Thu, 29 May 2003 11:06:45 -0400
From: Ron Bonica <[email-masked]>
Subject: RE: Route Exclusion
To: Adrian Farrel <[email-masked]>, 'Kireeti Kompella' <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]

Folks,

Are there any objections to adopting the route exclusion draft as a WG item?
If so, please post them to the mailing list by June 5. If not, CCAMP will
adopt the draft as a WG item.

                                                 Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, May 27, 2003 3:57 PM
> To: 'Kireeti Kompella'; Ron Bonica; [email-masked]
> Cc: [email-masked]; [email-masked]; Adrian
> Farrel
> Subject: Route Exclusion
>
>
> Kireeti, Ron,
>
> You may recall that at SF there was a surprisingly large number
> of people (30+)
> who had read this draft and expressed an interest. (In today's
> climate, it seems
> unusual if all of the authors have read a draft!)
>
> We (the authors) are also seeing a fair bit of interest expressed
> to us from
> people who need the function and want to go ahead and start
> implementing - they
> want to know what the future of the draft is. At the same time,
> the ASON work
> seems to be pulling in this requirement, and I shouldn't be surprised if
> multi-area/multi-domain/multi-AS decides it is a requirement, too.
>
> So the question for you is, what do we do with this draft?
>
> There appear to be three possibilies:
>
> 1. The draft becomes a WG draft in the near future, and continues
> to develop
> with input from the WG.
>
> 2. The authors continue to spend their efforts on the draft with
> no particular
> IETF target in sight and without the GMPLS community having any realistic
> expectation of the draft going anywhere. Other standards bodies,
> needing the
> function, develop their own alternatives and so on...
>
>  3. The authors bring the draft forward as an individual
> submission to the IESG.
>
>  Well, you can guess which I think is the best idea.
>
> What do you think?
>
> Cheers,
> Adrian
>
>
>

Envelope-to: [email-masked]
Delivery-date: Thu, 29 May 2003 13:17:10 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-mpls-mgmt-overview-05.txt
Date: Thu, 29 May 2003 09:15:32 -0400

FYI,

Changes are minor nits and synchronization of new (final?) versions of the MIB
drafts that have come out.

Adrian
----- Original Message -----
From: <[email-masked]>
To: <IETF-Announce: ;>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, May 29, 2003 7:20 AM
Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-05.txt

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Multiprotocol Label Switching Working Group
of the IETF.
>
> Title : Multiprotocol Label Switching (MPLS) Management
>                           Overview
> Author(s) : T. Nadeau, C. Srinivasan, A. Farrel
> Filename : draft-ietf-mpls-mgmt-overview-05.txt
> Pages : 28
> Date : 2003-5-28
>
> A range of Management Information Base (MIB) modules has
> been developed to help model and manage the various aspects
> of Multiprotocol Label Switching (MPLS) networks.  These MIB
> modules are defined in separate documents that focus on the
> specific areas of responsibility of the modules that they
> describe.
> This memo describes the management architecture for MPLS
> and indicates the inter-relationships between the different
> MIB modules used for MPLS network management.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-05.txt
>

Delivery-date: Thu, 29 May 2003 11:22:50 +0000
To: IETF-Announce: ;
Cc: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-05.txt
Date: Thu, 29 May 2003 07:20:17 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Multiprotocol Label Switching (MPLS) Management    
                          Overview
	Author(s)	: T. Nadeau, C. Srinivasan, A. Farrel
	Filename	: draft-ietf-mpls-mgmt-overview-05.txt
	Pages		: 28
	Date		: 2003-5-28
	
A range of Management Information Base (MIB) modules has
been developed to help model and manage the various aspects
of Multiprotocol Label Switching (MPLS) networks.  These MIB
modules are defined in separate documents that focus on the
specific areas of responsibility of the modules that they
describe.
This memo describes the management architecture for MPLS
and indicates the inter-relationships between the different
MIB modules used for MPLS network management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-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-mpls-mgmt-overview-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-mpls-mgmt-overview-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-mpls-mgmt-overview-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-mgmt-overview-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: Wed, 28 May 2003 11:47:47 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-analysis-01.txt
Date: Wed, 28 May 2003 07:46:36 -0400

--NextPart

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

	Title		: Analysis of Generalized MPLS-based Recovery Mechanisms
                          (including Protection and Restoration)
	Author(s)	: D. Papadimitriou, E. Mannie
	Filename	: draft-ietf-ccamp-gmpls-recovery-analysis-01.txt
	Pages		: 40
	Date		: 2003-5-27
	
This document provides an analysis grid that can be used to
evaluate, compare and contrast the numerous Generalized MPLS
(GMPLS)-based recovery mechanisms currently proposed at the CCAMP
Working Group. A detailed analysis of each of the recovery phases is
provided using the terminology defined in [CCAMP-TERM]. Also, this
document focuses on transport plane survivability and recovery
issues and not on control plane resilience and related aspects.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-recovery-analysis-01.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: Tue, 27 May 2003 19:57:44 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, "Ron Bonica" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Adrian Farrel" <[email-masked]>
Subject: Route Exclusion
Date: Tue, 27 May 2003 15:56:33 -0400

Kireeti, Ron,

You may recall that at SF there was a surprisingly large number of people (30+)
who had read this draft and expressed an interest. (In today's climate, it seems
unusual if all of the authors have read a draft!)

We (the authors) are also seeing a fair bit of interest expressed to us from
people who need the function and want to go ahead and start implementing - they
want to know what the future of the draft is. At the same time, the ASON work
seems to be pulling in this requirement, and I shouldn't be surprised if
multi-area/multi-domain/multi-AS decides it is a requirement, too.

So the question for you is, what do we do with this draft?

There appear to be three possibilies:

1. The draft becomes a WG draft in the near future, and continues to develop
with input from the WG.

2. The authors continue to spend their efforts on the draft with no particular
IETF target in sight and without the GMPLS community having any realistic
expectation of the draft going anywhere. Other standards bodies, needing the
function, develop their own alternatives and so on...

 3. The authors bring the draft forward as an individual submission to the IESG.

 Well, you can guess which I think is the best idea.

What do you think?

Cheers,
Adrian

Delivery-date: Tue, 27 May 2003 13:24:11 +0000
content-class: urn:content-classes:message
Subject: Vendor attributes in TE LSAs
Date: Tue, 27 May 2003 09:19:28 -0400
From: "Udo Neustadter" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi all,

I am working on a GMPLS implementation, and part of my problem is the
addition of company specific data to the TE LSAs. The Internet-Draft
http://www.ietf.org/internet-drafts/draft-udo-ospf-vendatt-00.txt
proposes an interoperable way to solve the following two issues:
  1. Companies that already applied with IANA for an SMI Network
management enterprise code do not need to re-apply for sub-TLV values
from the pool of numbers reserved for private use
  2. Allows private attributes/data to be embedded in the TE router LSA
(the one TE LSA that contains the router address TLV).

I would like for the draft to be considered part of this working group.
This work is an extension to the work done in
http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt
and
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensio
ns-09.txt.=20

Thanks in advance for your support.

Udo

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 19:05:24 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 19:04:17 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 19:03:10 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 19:02:38 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 19:02:06 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 19:01:32 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 19:00:52 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 19:00:19 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 18:59:44 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 18:59:12 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 18:58:38 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 18:58:05 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 18:57:04 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 18:52:54 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 18:42:33 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 14:31:41 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard, Version 07 [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 18:34:04 +0000
Message-Id: <[email-masked]>
To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching  Architecture to Proposed Standard, Version 07
Date: Thu, 22 May 2003 14:31:41 -0400

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-07.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 17:10:56 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 17:10:22 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 17:08:16 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 17:07:34 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 17:06:49 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 17:06:16 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 17:05:44 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:46:38 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:44:58 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:42:45 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:16:51 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Document Action: Tracing Requirements for Generic Tunnels to          Informational [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Tracing Requirements for Generic 
Tunnels' <draft-ietf-ccamp-tracereq-02.txt> as a Informational. This document 
is the product of the Common Control and Measurement Plane Working Group. 
The IESG contact persons are Bert Wijnen and Alex Zinin 

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:42:14 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:16:51 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Document Action: Tracing Requirements for Generic Tunnels to          Informational [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Tracing Requirements for Generic 
Tunnels' <draft-ietf-ccamp-tracereq-02.txt> as a Informational. This document 
is the product of the Common Control and Measurement Plane Working Group. 
The IESG contact persons are Bert Wijnen and Alex Zinin 

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:41:42 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:16:51 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Document Action: Tracing Requirements for Generic Tunnels to          Informational [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Tracing Requirements for Generic 
Tunnels' <draft-ietf-ccamp-tracereq-02.txt> as a Informational. This document 
is the product of the Common Control and Measurement Plane Working Group. 
The IESG contact persons are Bert Wijnen and Alex Zinin 

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:41:09 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:16:51 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Document Action: Tracing Requirements for Generic Tunnels to          Informational [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Tracing Requirements for Generic 
Tunnels' <draft-ietf-ccamp-tracereq-02.txt> as a Informational. This document 
is the product of the Common Control and Measurement Plane Working Group. 
The IESG contact persons are Bert Wijnen and Alex Zinin 

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:40:37 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:40:05 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:39:29 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:39:00 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:38:26 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List] [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:25:42 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:16:51 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Document Action: Tracing Requirements for Generic Tunnels to          Informational [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Tracing Requirements for Generic 
Tunnels' <draft-ietf-ccamp-tracereq-02.txt> as a Informational. This document 
is the product of the Common Control and Measurement Plane Working Group. 
The IESG contact persons are Bert Wijnen and Alex Zinin 

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:23:35 +0000
Message-Id: <[email-masked]>
Date: Thu, 22 May 2003 12:07:17 -0400
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
To: [email-masked]
From: "The IESG" <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching 	   Architecture to Proposed Standard [[email-masked] in Pass-Through List]

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:18:19 +0000
Message-Id: <[email-masked]>
To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Document Action: Tracing Requirements for Generic Tunnels to  Informational 
Date: Thu, 22 May 2003 12:16:51 -0400

The IESG has approved the Internet-Draft 'Tracing Requirements for Generic 
Tunnels' <draft-ietf-ccamp-tracereq-02.txt> as a Informational. This document 
is the product of the Common Control and Measurement Plane Working Group. 
The IESG contact persons are Bert Wijnen and Alex Zinin 

Envelope-to: [email-masked]
Delivery-date: Thu, 22 May 2003 16:10:58 +0000
Message-Id: <[email-masked]>
To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching  Architecture to Proposed Standard
Date: Thu, 22 May 2003 12:07:17 -0400

The IESG has approved the Internet-Draft 'Generalized Multi-Protocol 
Label Switching Architecture' 
<draft-ietf-ccamp-gmpls-architecture-06.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement 
Plane Working Group. The IESG contact persons are Bert Wijnen and 
Alex Zinin.
     
Technical Summary
     
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
     
Working Group Summary
     
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
     
Protocol Quality
     
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.

Delivery-date: Wed, 21 May 2003 13:39:28 +0000
From: "Jonathan Lang" <[email-masked]>
To: "'Manoj Agiwal'" <[email-masked]>, "''Ccamp \(E-mail\)'" <[email-masked]>
Subject: RE: Link Summary Message
Date: Wed, 21 May 2003 06:36:49 -0700

Manoj,

> -----Original Message-----
> From: Manoj Agiwal [mailto:[email-masked]] 
> Sent: Tuesday, May 20, 2003 8:56 PM
> To: 'Ccamp (E-mail)
> Cc: [email-masked]'
> Subject: FW: Link Summary Message
> 
> 
> Hi ,
>        LMP darft says
> 
>  "The linksummary MUST be send periodically transmitted until 
> (1) the node receives a LinkSummaryAck or LinkSummaryNack 
> message or (2) a retry limit has been reached and no 
> LinkSummaryAck or LinkSummaryNack message has been received"
> 
> When a new Data Link is enabled for a TE link which is 
> already in UP state . Then how a Link Summary message is 
> initiated for a new DL added to a TE link ? Which event 
> should trigger the sending of Link Summary message in this scenario?
You can trigger the LinkSummary message when the data link is enabled
for the TE link.

> 
> Do we sent Link Summary message periodically when TE is in UP state ? 
Sure.  In section 4, it says
"Link property correlation SHOULD be done before the link is brought up
and MAY be done at any time a link is up and not in the Verification
process."

> 
> 
> When should Event  evSummaryFail be generated to DL fsm .
> 
>      1) When we receive Link Summary Nack message.
> 
>          or
> 
>      2) When we negatively acknowlege Link Summary message 
> i.e. when we send Link Summary Nack .
> 
>          or
> 
>          In both the cases 
Both cases.

Thanks,
Jonathan
> 
> Regards ,
> Manoj
>  
> 
>   
> 

Delivery-date: Wed, 21 May 2003 04:06:13 +0000
From: Manoj Agiwal <[email-masked]>
To: "'Ccamp (E-mail)" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: FW: Link Summary Message
Date: Tue, 20 May 2003 22:56:26 -0500

Hi ,
       LMP darft says

 "The linksummary MUST be send periodically transmitted until (1) the node
receives a LinkSummaryAck or LinkSummaryNack message or (2) a retry limit
has been reached and no LinkSummaryAck or LinkSummaryNack message has been
received"

When a new Data Link is enabled for a TE link which is already in UP state .
Then how a Link Summary message is initiated for a new DL added to a TE link
? Which event should trigger the sending of Link Summary message in this
scenario?

Do we sent Link Summary message periodically when TE is in UP state ? 

When should Event  evSummaryFail be generated to DL fsm .

     1) When we receive Link Summary Nack message.

         or

     2) When we negatively acknowlege Link Summary message i.e. when we send
Link Summary Nack .

         or

         In both the cases 

Regards ,
Manoj

  

Delivery-date: Tue, 20 May 2003 12:39:41 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: draft-ietf-ccamp-gmpls-architecture-07.txt
Date: Tue, 20 May 2003 14:37:57 +0200

Dimitri posted a new rev, to address some more nits
from IESG. 

If anyone wants to do a quick check, Here are ptrs to colored
web pages showing the difference between rev 5 and 7 or the
differences between rev 6 and rev 7. So depending on which
one you reviewed you can see what has changed.

    http://psg.com/~bwijnen/gmplsarch.05-07.html
    http://psg.com/~bwijnen/gmplsarch.06-07.html

I think all changes are fine and OK. IESG did approve rev 06,
and so (assuming they are also OK with rev 07, which I expect
to hear within a day or so) then it will go to RFC-Editor queue.

Thanks,
Bert 

Delivery-date: Tue, 20 May 2003 11:32:06 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-07.txt
Date: Tue, 20 May 2003 07:25:34 -0400

--NextPart

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

	Title		: Generalized Multi-Protocol Label Switching 
                          Architecture
	Author(s)	: E. Mannie
	Filename	: draft-ietf-ccamp-gmpls-architecture-07.txt
	Pages		: 58
	Date		: 2003-5-19
	
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.
This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-architecture-07.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, 19 May 2003 20:47:28 +0000
Date: Mon, 19 May 2003 13:46:25 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>
cc: [email-masked], "" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>, "" <[email-masked]>
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi  cation

Hi Lyndon,

On Mon, 19 May 2003, Ong, Lyndon wrote:

> Maybe everyone is tired out :o)  In any case, I think
> a liaison response is certainly a good idea, and you
> deserve some thanks for putting it together and attempting
> to reach some consensus on the list.

To give credit where it's due, there were many who helped; there were
also many replies to the first version that helped shape this one.

> Just wanted to clarify one point, though - the liaison says
> that compared to G.7714.1 messages
>
> > "GMPLS identifiers are typically 32 bit numbers and as such are not
> > printable characters."
>
> Maybe it's a fine point, but the messages in G.7714.1 are described
> in bit-oriented format, not as characters; the Base64 encoding is
> then applied to the message before it goes out on the trace, so that
> what is sent on the wire is in the form of printable characters.
>
> That means that 32 bit numbers can still be carried in the message,
> subject to the length limit.  A decoding would be applied at the other
> end to recover the original bit-oriented message.
> (Folks who worked on 7714.1 can correct me if I'm wrong on this).

Well, the liaison has already been sent.  However, if necessary we can
clarify this at the interim ITU SG14/15 meeting in a couple of weeks.

Thanks for your comments,
Kireeti.

Delivery-date: Mon, 19 May 2003 20:14:54 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, [email-masked]
Cc: [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>,  "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation
Date: Mon, 19 May 2003 13:16:34 -0700

Hi Kireeti,

Maybe everyone is tired out :o)  In any case, I think
a liaison response is certainly a good idea, and you
deserve some thanks for putting it together and attempting
to reach some consensus on the list.

Just wanted to clarify one point, though - the liaison says
that compared to G.7714.1 messages
 
> "GMPLS identifiers are typically 32 bit numbers and as such are not 
> printable characters."

Maybe it's a fine point, but the messages in G.7714.1 are described
in bit-oriented format, not as characters; the Base64 encoding is
then applied to the message before it goes out on the trace, so that
what is sent on the wire is in the form of printable characters.  

That means that 32 bit numbers can still be carried in the message,
subject to the length limit.  A decoding would be applied at the other 
end to recover the original bit-oriented message.
(Folks who worked on 7714.1 can correct me if I'm wrong on this).

Cheers,

Lyndon

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Saturday, May 17, 2003 9:51 AM
To: [email-masked]
Cc: [email-masked]; Wijnen, Bert (Bert); Ron Bonica (E-mail);
[email-masked]
Subject: RE: Proposed response to the Liaison Statement on LMP Link
Verifi cation

Hi All,

On Sun, 11 May 2003, Kireeti Kompella wrote:

> Please send your replies to the list (if you wish to reply privately,
> include the Liaison Coordinator and the ADs in your reply).

There was some support, no nay-sayers and no alternative text.

I'm surprised at the somewhat tepid support, as when the subject
of liaisons came up, there were heated opinions that CCAMP was
not keeping its end up, and now that we have liaisons to send,
there is limited (expressed) interest, either for or against.

In any case, this is important, there is enough support, so I will
send the liaison off as is.

I encourage those who can to attend the interim meeting in Chicago.
It's coming up soon, June 9-13.

Thanks,
Kireeti.

Delivery-date: Mon, 19 May 2003 19:20:25 +0000
Date: Mon, 19 May 2003 12:15:45 -0700 (PDT)
From: vivek_1975 <[email-masked]>
Reply-To: vivek_1975 <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: Re: FW: draft-ietf-ccamp-lmp-08.txt

Hi,

Hi i am not sure whether the question has been raised previously in this list. In the ccamp-lmp draft for all the messages, there is more emphasize on the transmission order. 

Can somebody answer why this STRICT requirement is enforced rather than the similar kind of mechanism followed in RSVP(Objects can come in any order).

Regards
Vivek

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Monday, May 19, 2003, 6:15 AM
> To: "Ccamp-wg (E-mail)" <[email-masked]>
> Subject: FW: draft-ietf-ccamp-lmp-08.txt
> 
> Here is the last IESG comment on this document.
> I think that Thomas had indeed uncovered a serious issue.
> With various other IANA controlled name spaces, we have 
> recently found that the IANA guidelines/rules for making
> assignments were either not clear or allowed for 
> assignments to be made too easily. That then later resulted
> in all sorts of let us say "un-friendly" discussions. We
> betetr try to avoid those in the future and so we must be
> very specific and very precise in the IANA guidelines for
> new namespaces.
> 
> Pls fix as part of your new revision.
> 
> Thanks,
> Bert 
> 
> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]]
> Sent: maandag 19 mei 2003 14:47
> To: Bert Wijnen
> Cc: [email-masked]
> Subject: draft-ietf-ccamp-lmp-08.txt
> 
> 
> Discuss comments:
> 
> 
>    The LMP Message Type name space should be allocated as follows:
>    pursuant to the policies outlined in [RFC2434], the numbers in the
>    range 0-127 are allocated by Standards Action, 128-240 are allocated
>    through an Expert Review, and 241-255 are reserved for Private Use.
> 
> It might be good to expand on expert review just a bit. Is the
> intention that anyone can get one an allocation? Allocations only for
> stuff that will clearly eventually be published as an RFC? What sort
> of review is the expert expected to do? The more text one can give
> here, the less confusion there will be later should people disagree
> with the decision of the expert.
> 
>    The LMP Sub-object Class name space should be allocated as follows:
>    pursuant to the policies outlined in [RFC2434], the numbers in the
>    range of 0-127 are allocated by Standards Action, 128-247 are
>    allocated through an Expert Review, and 248-255 are reserved for
>    Private Use.
> 
> seems wrong. the sub-object assignment policy should be determined by
> the Class. I.e., when you create a class, you define what the policy
> should be for sub-classes. For some sub-classes, FCFS might be fine,
> for others maybe only standards action. One-size fits all doesn't seem
> right. I'd suggest something like:
> 
>    The policy for allocating values out of the LMP Sub-object Class
>    name space is part of the defintion of the specific Class
>    instance. When a Class is defined, its definition must also include
>    a description of the policy underwhich sub-objects are allocated.
> 
> note: that also means this needs to be done for all of the sub-objects
> that are defined in this document.
> 
>    The LMP Object Class type name space should be allocated as follows:
>    pursuant to the policies outlined in [RFC2434], the numbers in the
>    range 0-111 are allocated by Standards Action, 112-119 are allocated
>    through an Expert Review, and 120-127 are reserved for Private Use.
> 
> ditto   
> 
> 
> Thomas
> 

Delivery-date: Mon, 19 May 2003 13:52:30 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Dieter Beller" <[email-masked]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>, "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Subject: RE: ASON reqts
Date: Mon, 19 May 2003 09:51:15 -0400

Jerry, Deiter,

Thanks very much for your emails, and for pointers to 
additional information.
This is very helpful.

-Vishal

> -----Original Message-----
> From: Dieter Beller [mailto:[email-masked]]
> Sent: Monday, May 19, 2003 4:55 AM
> To: [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS; Kireeti Kompella; [email-masked]
> Subject: Re: ASON reqts
> 
> 
> Vishal,
> 
> Ash, Gerald R (Jerry), ALABS wrote:
> > Vishal,
> > 
> > 
> >>>>I believe the initial routing requirements are captured in ITU doc.
> >>>>G.7715. However, I am not sure whether, unlike signaling, the ITU has
> >>>>begun work on the protocol-specific instantiations of routing
> >>>>requirements.
> > 
> >  
> > 
> >>>The conclusion drawn from some initial discussions on specific
> >>>routing protocols was to step back for a moment and develop a
> >>>so-called mid-level requirements recommendation for a link state
> >>>routing protocol which still should be protocol neutral. This
> >>>requirements recommendation will then be used for the assessment
> >>>of existing link state routing protocols to be applied in ASON.
> > 
> > 
> >>Would you know where this work currently stands within the ITU?
> >>Has this intermediate or mid-level document been created?
> >>If so, how may one get access to it, and has it been liased
> >>to the IETF?
> > 
> > 
> > There is a Liaison from ITU-T to IETF that reports the status 
> of the ASON routing work at 
> http://www.ietf.org/IESG/LIAISON/ls15-39.htm.  There is also a 
> pointer to G.7715 at the bottom of the Liaison:
> > 
> > click the link at the bottom of the Liaison --> 
> > click "Common Control and Measurement Plane (ccamp) Working Group" -->
> > click "I accept" at the bottom of this page -->
> > click "ASON Routing Activities" -->
> > click "download" on the G.7715 line -->
> > brings up G.7715
> > 
> 
> please find some more information by checking these:
> 
> http://ops.ietf.org/lists/ccamp/ccamp.2003/msg00330.html
> 
> http://ops.ietf.org/lists/ccamp/ccamp.2003/ppt00001.ppt
> 
> 
> Dieter
> 
> 
> > Thanks,
> > Jerry
> >
> 

Delivery-date: Mon, 19 May 2003 12:56:04 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: FW: draft-ietf-ccamp-lmp-08.txt
Date: Mon, 19 May 2003 14:53:53 +0200

Here is the last IESG comment on this document.
I think that Thomas had indeed uncovered a serious issue.
With various other IANA controlled name spaces, we have 
recently found that the IANA guidelines/rules for making
assignments were either not clear or allowed for 
assignments to be made too easily. That then later resulted
in all sorts of let us say "un-friendly" discussions. We
betetr try to avoid those in the future and so we must be
very specific and very precise in the IANA guidelines for
new namespaces.

Pls fix as part of your new revision.

Thanks,
Bert 

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: maandag 19 mei 2003 14:47
To: Bert Wijnen
Cc: [email-masked]
Subject: draft-ietf-ccamp-lmp-08.txt

Discuss comments:

   The LMP Message Type name space should be allocated as follows:
   pursuant to the policies outlined in [RFC2434], the numbers in the
   range 0-127 are allocated by Standards Action, 128-240 are allocated
   through an Expert Review, and 241-255 are reserved for Private Use.

It might be good to expand on expert review just a bit. Is the
intention that anyone can get one an allocation? Allocations only for
stuff that will clearly eventually be published as an RFC? What sort
of review is the expert expected to do? The more text one can give
here, the less confusion there will be later should people disagree
with the decision of the expert.

   The LMP Sub-object Class name space should be allocated as follows:
   pursuant to the policies outlined in [RFC2434], the numbers in the
   range of 0-127 are allocated by Standards Action, 128-247 are
   allocated through an Expert Review, and 248-255 are reserved for
   Private Use.

seems wrong. the sub-object assignment policy should be determined by
the Class. I.e., when you create a class, you define what the policy
should be for sub-classes. For some sub-classes, FCFS might be fine,
for others maybe only standards action. One-size fits all doesn't seem
right. I'd suggest something like:

   The policy for allocating values out of the LMP Sub-object Class
   name space is part of the defintion of the specific Class
   instance. When a Class is defined, its definition must also include
   a description of the policy underwhich sub-objects are allocated.

note: that also means this needs to be done for all of the sub-objects
that are defined in this document.

   The LMP Object Class type name space should be allocated as follows:
   pursuant to the policies outlined in [RFC2434], the numbers in the
   range 0-111 are allocated by Standards Action, 112-119 are allocated
   through an Expert Review, and 120-127 are reserved for Private Use.

ditto   

Thomas

Delivery-date: Mon, 19 May 2003 08:58:22 +0000
Date: Mon, 19 May 2003 10:55:11 +0200
From: Dieter Beller <[email-masked]>
Organization: Alcatel SEL AG, OND Stuttgart, Germany
To: [email-masked]
CC: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

Vishal,

Ash, Gerald R (Jerry), ALABS wrote:
> Vishal,
> 
> 
>>>>I believe the initial routing requirements are captured in ITU doc.
>>>>G.7715. However, I am not sure whether, unlike signaling, the ITU has
>>>>begun work on the protocol-specific instantiations of routing
>>>>requirements.
> 
>  
> 
>>>The conclusion drawn from some initial discussions on specific
>>>routing protocols was to step back for a moment and develop a
>>>so-called mid-level requirements recommendation for a link state
>>>routing protocol which still should be protocol neutral. This
>>>requirements recommendation will then be used for the assessment
>>>of existing link state routing protocols to be applied in ASON.
> 
> 
>>Would you know where this work currently stands within the ITU?
>>Has this intermediate or mid-level document been created?
>>If so, how may one get access to it, and has it been liased
>>to the IETF?
> 
> 
> There is a Liaison from ITU-T to IETF that reports the status of the ASON routing work at http://www.ietf.org/IESG/LIAISON/ls15-39.htm.  There is also a pointer to G.7715 at the bottom of the Liaison:
> 
> click the link at the bottom of the Liaison --> 
> click "Common Control and Measurement Plane (ccamp) Working Group" -->
> click "I accept" at the bottom of this page -->
> click "ASON Routing Activities" -->
> click "download" on the G.7715 line -->
> brings up G.7715
> 

please find some more information by checking these:

http://ops.ietf.org/lists/ccamp/ccamp.2003/msg00330.html

http://ops.ietf.org/lists/ccamp/ccamp.2003/ppt00001.ppt

Dieter

> Thanks,
> Jerry
>

Delivery-date: Sun, 18 May 2003 11:23:03 +0000
From: Manoj Agiwal <[email-masked]>
To: "'Ccamp (E-mail)" <[email-masked]>
Subject: evSummaryFail
Date: Sun, 18 May 2003 06:15:51 -0500

Hi ,
     When should Event  evSummaryFail be generated to DL fsm .

     1) When we receive Link Summary Nack message.

         or

     2) When we negatively acknowlege Link Summary message i.e. when we send
Link Summary Nack .

         or

         In both the cases .
Regards ,
Manoj

Delivery-date: Sun, 18 May 2003 11:10:21 +0000
From: Manoj Agiwal <[email-masked]>
To: "'Ccamp (E-mail)" <[email-masked]>
Subject: Link Summary Message
Date: Sun, 18 May 2003 06:01:41 -0500

Hi ,
       LMP darft says
 "The linksummary MUST be send periodically transmitted until (1) the node
receives a LinkSummaryAck or LinkSummaryNack message or (2) a retry limit
has been reached and no LinkSummaryAck or LinkSummaryNack message has been
received"
When a new Data Link is enabled for a TE link which is already in UP state .
Then how a Link Summary message is initiated for a new DL added to a TE link
? Which event should trigger the sending of Link Summary message in this
scenario?
Do we sent Link Summary message periodically when TE is in UP state ? 

Regards ,
Manoj

  

Delivery-date: Sat, 17 May 2003 23:31:30 +0000
From: "zafar ali" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "'Anca Zamfir'" <[email-masked]>
Subject: A new draft for Explicit Resource Control over GMPLS Link Bundles is available for your comments
Date: Sat, 17 May 2003 19:29:54 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_0038_01C31CAA.B25CCC70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Fellows, 
 
A new draft for Explicit Resource Control over GMPLS Link Bundles is
available for your comments and suggestions. Please find the draft at
the IETF Web site, 
 
http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-contr
ol-bundle-01.txt
 
Abstract 
    
   Explicit label/ resource control using the Label ERO and Label RRO 
   subobjects is defined in [RFC 3471] and [RFC 3473]. However, when TE 
   links are bundled, identification of label resource is not enough for

   the purpose of explicit resource control. Specifically, when link 
   bundling [GMPLS-BUNDLE] is used, resource identification requires 
   mechanisms to specify the component link identifier, along the TE 
   link identifier and Label. This draft defines the extensions to RSVP-
   TE [RFC2119, RFC3209] to specify component link identifiers for 
   explicit resource control and recording over GMPLS link bundles. 
 
Revision History
 
Version 00 was posted on March 4, 2003, but we just missed the cut-off
time for the 56th IETF meeting in San Francisco. Since then we have made
some minor changes. 
 
Your input will be much appreciated, as usual. 

Thanks
 
Regards... Anca & Zafar 

------=_NextPart_000_0038_01C31CAA.B25CCC70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN =
class=3D774171123-17052003>Dear=20
Fellows, </SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20
class=3D774171123-17052003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN =
class=3D774171123-17052003>A new=20
draft for Explicit Resource Control over GMPLS Link Bundles is available =
for=20
your comments and suggestions. Please find the draft at the IETF Web =
site,=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20
class=3D774171123-17052003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN =
class=3D774171123-17052003><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resourc=
e-control-bundle-01.txt">http://www.ietf.org/internet-drafts/draft-zamfir=
-explicit-resource-control-bundle-01.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20
class=3D774171123-17052003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20
class=3D774171123-17052003><U>Abstract</U> <BR>&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp;=20
Explicit label/ resource control using the Label ERO and Label RRO=20
<BR>&nbsp;&nbsp; subobjects is defined in [RFC 3471] and [RFC 3473]. =
However,=20
when TE <BR>&nbsp;&nbsp; links are bundled, identification of label =
resource is=20
not enough for <BR>&nbsp;&nbsp; the purpose of explicit resource =
control.=20
Specifically, when link <BR>&nbsp;&nbsp; bundling [GMPLS-BUNDLE] is =
used,=20
resource identification requires <BR>&nbsp;&nbsp; mechanisms to specify =
the=20
component link identifier, along the TE <BR>&nbsp;&nbsp; link identifier =
and=20
Label. This draft defines the extensions to RSVP-<BR>&nbsp;&nbsp; TE =
[RFC2119,=20
RFC3209] to specify component link identifiers for <BR>&nbsp;&nbsp; =
explicit=20
resource control and recording over GMPLS link bundles. =
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20
class=3D774171123-17052003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN =
class=3D774171123-17052003>
<DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20
class=3D774171123-17052003><U>Revision History</U></SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#000000 size=3D2><SPAN=20
class=3D774171123-17052003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20
class=3D774171123-17052003>Version 00 was posted on March 4, 2003, but =
we=20
<U>just</U> missed the cut-off time for&nbsp;the 56th IETF meeting in =
San=20
Francisco. Since then we have made some minor changes.=20
</SPAN></FONT></DIV></SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20
class=3D774171123-17052003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><SPAN class=3D774171123-17052003><FONT =
color=3D#000080=20
size=3D2>Your input will be much appreciated, as usual. </FONT></DIV>
<DIV><FONT size=3D2><BR><FONT =
color=3D#000080></FONT></FONT></DIV></SPAN></FONT>
<DIV align=3Dleft><FONT face=3DArial color=3D#000080 =
size=3D2>Thanks</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial color=3D#000080 =
size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT =
color=3D#000080>Regards...=20
<SPAN class=3D774171123-17052003>Anca &amp; Zafar=20
</SPAN></FONT></FONT></FONT></DIV></BODY></HTML>

------=_NextPart_000_0038_01C31CAA.B25CCC70--

Delivery-date: Sat, 17 May 2003 17:31:46 +0000
Date: Sat, 17 May 2003 10:31:10 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
cc: [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>, "" <[email-masked]>
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation

> In any case, this is important, there is enough support, so I will
> send the liaison off as is.

Done.  We need a couple of follow-up items:

| Based on information contained in the ITU and T1X1 liaison, as well as
| subsequent e-mail exchanges on the CCAMP mailing list, and in order to
| ensure proper interoperability in legacy SDH/SONET networks as well as
| networks in which G.7714.1 is deployed, it will be recommended by the
| editors to the CCAMP community to support only the Jx trace correlation
| procedure and not the in-band Jx procedure.  Pending agreement, the
| draft will be updated.

There was reasonable consensus (and no opposition) to this change.

| We agree that terminology differences between IETF and ITU-T wrt
| GMPLS have been confusing.  There is an ongoing effort within
| CCAMP to work together with T1X1/ITU-T on bridging the terminology
| gaps.  For example, there is a new Internet draft
| (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in
| CCAMP to do this mapping for LMP.

When the current hubbub over the ASON requirements document dies down,
I will check for WG consensus to move this forward.

| > 5. Clarification of the usage of transport and control
| > names for transport resources in the subject draft, as
| > described in G.8080 Amendment
|
| The trace correlation transport mechanism supports a separation of
| the transport and control plane identifiers.

Would it be useful to call this out explicitly in the document?

| > 6. Consideration of the ANSI 64-byte J1.
|
| This was mistakenly deleted from the latest version of the draft.
| This will be included in the next version.

Editors of the lmp-sonet-sdh doc, please update it with the change
to the in-band Jx procedure, the above clarification (if needed),
and the 64-byte J1, and resubmit it.  Thanks!

Thanks, All,
Kireeti.

Delivery-date: Sat, 17 May 2003 16:54:54 +0000
Date: Sat, 17 May 2003 09:51:16 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
cc: [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>, "" <[email-masked]>
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation

Hi All,

On Sun, 11 May 2003, Kireeti Kompella wrote:

> Please send your replies to the list (if you wish to reply privately,
> include the Liaison Coordinator and the ADs in your reply).

There was some support, no nay-sayers and no alternative text.

I'm surprised at the somewhat tepid support, as when the subject
of liaisons came up, there were heated opinions that CCAMP was
not keeping its end up, and now that we have liaisons to send,
there is limited (expressed) interest, either for or against.

In any case, this is important, there is enough support, so I will
send the liaison off as is.

I encourage those who can to attend the interim meeting in Chicago.
It's coming up soon, June 9-13.

Thanks,
Kireeti.

Delivery-date: Sat, 17 May 2003 10:18:03 +0000
Date: Sat, 17 May 2003 12:22:20 +0200
From: [email-masked]
To: Stephen Shew <[email-masked]>
Cc: "'Stephen Trowbridge'" <[email-masked]>, John Drake <[email-masked]>, "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

stephen, well for me it is entirely clear, we are at a
turning point of the whole story, either gmpls extensions
are backward/forward compatible, or you will end-up in a
way or another with two protocol sets, the issue is "who
gains something in maintaining the current confusing
situation ?" ... the response is clear ... neither the
ietf nor the itu (and unfortunately as a consequence,
both the developer and the user community)

in the note sent by fred baker (early'01), see
http://www.ietf.org/IESG/STATEMENTS/sub_area.txt

it was overwhelmingly clear that the following is the motto:
"For example, optical networking is clearly a next generation
requirement for service providers and for fiber consortia.
However, the obvious next hop router in a general network may
differ from the obvious next hop router in an optical network.
Therefore, the use of optical networking may change the results
that we need to get from routing protocols. It would be better
for us to determine how the routing protocols should model those
networks than for another body to arbitrarily change them or
substitute others."

and the exactly same applies for signalling, if this is still
not clear, i'll explain it as follows, as you want a well-
designed control plane architecture for optical networks, i
want that the corresponding protocol extensions (routing,
signalling, etc.) to be also well-designed and consistent
with the internet protocols, this is my take as an ietf'er.

stepping now in the protocol motivation behind this thread
using the stephen t. detector i would call it a 3.5 motivation:
 > Those who think that RFC 3474/G.7713.2 (ITU-T extensions) don't
 > meet fully the ASON requirements and are not GMPLS compliant, so
 > this draft is a first step not only to fix RFC 3474/G.7713.2
 > but also to make them GMPLS compliant

taking one of the main discussion points in the above i-d,
in my view, we should even look at it as follows, what are
the possible methods to achieve call/connection separation
well we have the following possibilities: "rfc3474, extend the
notify message, define a new message" then detail pros and
cons and decide upon wg consensus, which method is the more
appropriate from a technical perspective.

hope this clarifies.

thanks,
- dimitri.

Stephen Shew wrote:
 > I have read the requirements draft (and most of this thread) and tend to
 > agree with Stephen T. that the problem is not entirely clear.  However,
 > for the purpose of dialogue between standards bodies, having a CCAMP WG
 > document to liaise is helpful.  In that regard I fine with it
 > progressing to a CCAMP WG document.
 >
 > One major technical comment I have is that the ASON addressing
 > requirements aren't fully represented.  For example, "G.8080 defines a
 > UNI Transport Resource Addresses for the bearer links at the UNI
 > reference point" (from G.7713.2 and G.7713.3).  This is important for
 > ASON services.  Also, reference points and call segments are missing.  I
 > would hope these can be discussed between CCAMP and SG15.  Hence a
 > liaison would be helpful.
 >
 > -----Original Message-----
 > From: Stephen Trowbridge [mailto:[email-masked]]
 > Sent: Wednesday, May 14, 2003 11:59
 > To: John Drake
 > Cc: Ash, Gerald R (Jerry), ALABS; Wijnen, Bert (Bert); [email-masked]
 > Subject: Re: ASON reqts
 >
 >
 > John,
 > I still think it is better to argue it out now and reach agreement on
 > what problem we are trying to solve.
 >
 > If we accept this as a WG draft without doing this, we seem to be
 > accepting that we do have SOME problem to solve, and then arguing later
 > on what it was. Regards, Steve
 >
 > John Drake wrote:
 >  >
 >  > Regardless of what we do now, I'm sure there will be lots of arguments
 >  > later.
 >  >
 > <snip>
 >

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

Delivery-date: Sat, 17 May 2003 02:44:41 +0000
Date: Fri, 16 May 2003 22:43:39 -0400
To: "Jonathan Lang" <[email-masked]>
From: "Bradford, Richard" <[email-masked]>
Subject: RE: I-D ACTION:draft-rbradfor-ccamp-lmp-lol-01.txt 
Cc: "'Bradford, Richard'" <[email-masked]>, <[email-masked]>

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

Jonathan,
   Clarifications inline.
   Thanks for the feedback,
   Rich

At 01:30 PM 5/16/2003 -0700, Jonathan Lang wrote:
>Richard,
>   I read the draft and I like it.  More comments inline.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Bradford, Richard
> > Sent: Friday, May 16, 2003 7:35 AM
> > To: [email-masked]
> > Subject: Re: I-D ACTION:draft-rbradfor-ccamp-lmp-lol-01.txt
> >
> >
> > I'd like to get feedback from the list on the this draft. In
> > addition to any problems with the draft itself:
> > a) Does it solve the problem of Link Verification for OXCs?
>I think "the problem" can be solved with existing mechanisms, but I like
>your proposal.
>
> > b) If this isn't used, then how will Link Verification be
> > performed for pure OXCs? Addition of Link Termination modules
> > such as OC-48 and 10GigE? Build test circuits through the switches?
>One way to do it is switch the port to an internal "test" port.  Is this
>what you mean by "build test circuits"?
There were two other ways that I was thinking of. The first was switching 
to an internal test port, which it seems would have to be terminated in a 
compatible way with the neighbor (e,g, OC-48 or 10GigE).
Another way to verify links, but not discover them, would be to build test 
circuits between the termination capable devices surrounding a network of 
pure optical switches. This wouldn't be something LMP could do, being a 
purely local protocol.

> > c) Will carriers deploy (i.e. not just lab trials) OXCs
> > without Link Verification capabilities?
>I highly doubt it, but I'll let them add their input.
>
>Thanks,
>Jonathan

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

<html>
<font size=3>Jonathan,<br>
&nbsp; Clarifications inline.<br>
&nbsp; Thanks for the feedback,<br>
&nbsp; Rich<br>
<br>
At 01:30 PM 5/16/2003 -0700, Jonathan Lang wrote:<br>
<blockquote type=cite cite>Richard,<br>
&nbsp; I read the draft and I like it.&nbsp; More comments inline.<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: [email-masked] <br>
&gt;
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
On Behalf Of Bradford, Richard<br>
&gt; Sent: Friday, May 16, 2003 7:35 AM<br>
&gt; To: [email-masked]<br>
&gt; Subject: Re: I-D ACTION:draft-rbradfor-ccamp-lmp-lol-01.txt <br>
&gt; <br>
&gt; <br>
&gt; I'd like to get feedback from the list on the this draft. In <br>
&gt; addition to any problems with the draft itself:<br>
&gt; a) Does it solve the problem of Link Verification for OXCs?<br>
I think &quot;the problem&quot; can be solved with existing mechanisms,
but I like<br>
your proposal.<br>
<br>
&gt; b) If this isn't used, then how will Link Verification be <br>
&gt; performed for pure OXCs? Addition of Link Termination modules <br>
&gt; such as OC-48 and 10GigE? Build test circuits through the
switches?<br>
One way to do it is switch the port to an internal &quot;test&quot;
port.&nbsp; Is this<br>
what you mean by &quot;build test
circuits&quot;?</font></blockquote>There were two other ways that I was
thinking of. The first was switching to an internal test port, which it
seems would have to be terminated in a compatible way with the neighbor
(e,g, OC-48 or 10GigE).<br>
Another way to verify links, but not discover them, would be to build
test circuits between the termination capable devices surrounding a
network of pure optical switches. This wouldn't be something LMP could
do, being a purely local protocol.<br>
<br>
<br>
<blockquote type=cite cite><font size=3>&gt; c) Will carriers deploy
(i.e. not just lab trials) OXCs <br>
&gt; without Link Verification capabilities?<br>
I highly doubt it, but I'll let them add their input.<br>
<br>
Thanks,<br>
Jonathan<br>
</font></blockquote><br>

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

--=====================_123386330==_.ALT--

Delivery-date: Sat, 17 May 2003 01:29:07 +0000
From: Manoj Agiwal <[email-masked]>
To: "'Baktha Muralidharan'" <[email-masked]>, Manoj Agiwal <[email-masked]>
Cc: "'Ccamp (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: FW: LMP Message ID
Date: Fri, 16 May 2003 04:07:16 -0500

Hi Bakhta ,

     Neighbour is only interested in knowing if the message is out-of-order
or not. If retransmission algorithm sends the message with the same Message
Id , Neighbor will not
consider it as out-of-order and process it. Out of order condition being
(int)oldmsgid - (int)newmsgid > 0
In case a new message is received with a greater Message id and latter
Neighbor receives the re-transmitted message , re-transmitted message should
be discarded as it is out-of-order.

      New message identifies change in configuration and should be send with
a higher message id and should be accepted by neighbor while re-trnasmitted
message represents old values and should be discarded.

     I feel if retransmitted message is sent with the same message Id or new
message id ,
it does not matter , since in either case neighboring node will process it
completely.
Only disadvantage is one will eat away Message Id space at faster rate if
new message id is
generated for every re-transmitted message.

Regards ,
Manoj

-----Original Message-----
From: Baktha Muralidharan [mailto:[email-masked]]
Sent: Wednesday, May 14, 2003 8:33 PM
To: Manoj Agiwal
Cc: 'Ccamp (E-mail); [email-masked]'
Subject: Re: FW: LMP Message ID

At 12:37 AM 5/13/2003 -0500, Manoj Agiwal wrote:
>Hi ,
>       Lmp drafts tells that Message ID should be monotonically increasing

>
>       Section 7 also tells that "Unacknowledge messages sent with
Message_id
>object should be retransmitted until the message is
>       acknowledged or until retry limit is reached."
>
>       Do we have to sent all retransmitted messages with the same Message
Id
>as sent previously or it should be in monotonically
>       increasing order.
>
>Regards ,
>Manoj

Hi Manoj,

An unacknowledged message could have been lost; i.e. might not have reached
the neighbor. So, the neighbor has no way of determining if a message is
a re-transmit and will fail [and nack] a message with out-of-order
message-id.

So, re-transmit attempts should increase message id.

/Baktha Muralidharan
  Cisco Systems.

Delivery-date: Fri, 16 May 2003 22:37:39 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Fri, 16 May 2003 17:36:24 -0500
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, "Dieter Beller" <[email-masked]>, "Kireeti Kompella" <[email-masked]>, <[email-masked]>

Vishal,

>>> I believe the initial routing requirements are captured in ITU doc.
>>> G.7715. However, I am not sure whether, unlike signaling, the ITU =
has
>>> begun work on the protocol-specific instantiations of routing
>>> requirements.
=20
>> The conclusion drawn from some initial discussions on specific
>> routing protocols was to step back for a moment and develop a
>> so-called mid-level requirements recommendation for a link state
>> routing protocol which still should be protocol neutral. This
>> requirements recommendation will then be used for the assessment
>> of existing link state routing protocols to be applied in ASON.

> Would you know where this work currently stands within the ITU?
> Has this intermediate or mid-level document been created?
> If so, how may one get access to it, and has it been liased
> to the IETF?

There is a Liaison from ITU-T to IETF that reports the status of the =
ASON routing work at http://www.ietf.org/IESG/LIAISON/ls15-39.htm.  =
There is also a pointer to G.7715 at the bottom of the Liaison:

click the link at the bottom of the Liaison -->=20
click "Common Control and Measurement Plane (ccamp) Working Group" -->
click "I accept" at the bottom of this page -->
click "ASON Routing Activities" -->
click "download" on the G.7715 line -->
brings up G.7715

Thanks,
Jerry

Delivery-date: Fri, 16 May 2003 20:48:15 +0000
From: "Srini Datari" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Subject: RE: Proposed change to LMP Link Verification draft
Date: Fri, 16 May 2003 16:47:46 -0400

Agree with above change

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Kireeti Kompella
Sent: Monday, May 12, 2003 2:28 AM
To: [email-masked]
Subject: Proposed change to LMP Link Verification draft

Hi All,

| Based on information contained in the ITU and T1X1 liaison, as well as
| subsequent e-mail exchanges on the CCAMP mailing list, and in order to
| ensure proper interoperability in legacy SDH/SONET networks as well as
| networks in which G.7714.1 is deployed, it will be recommended by the
| editors to the CCAMP community to support only the Jx trace correlation
| procedure and not the in-band Jx procedure.

Please respond with one of the following:
 - Agree with above change; OR
 - Don't agree with above change [i.e., keep in-band Jx procedure as is].

Kireeti.

Delivery-date: Fri, 16 May 2003 20:42:54 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Dieter Beller" <[email-masked]>, "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Subject: RE: ASON reqts
Date: Fri, 16 May 2003 16:41:56 -0400

Deiter, Jerry

Thanks for your inputs. 

> -----Original Message-----
> From: Dieter Beller [mailto:[email-masked]]
> Sent: Friday, May 16, 2003 7:57 AM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: [email-masked]; Kireeti Kompella; [email-masked]
> Subject: Re: ASON reqts
> 
> <snip>
> 
> > 
> >>I believe the initial routing requirements are captured in ITU doc.
> >>G.7715. However, I am not sure whether, unlike signaling, the ITU has
> >>begun work on the protocol-specific instantiations of routing 
> >>requirements.
> > 
> 
> The conclusion drawn from some initial discussions on specific
> routing protocols was to step back for a moment and develop a
> so-called mid-level requirements recommendation for a link state
> routing protocol which still should be protocol neutral. This
> requirements recommendation will then be used for the assessment
> of existing link state routing protocols to be applied in ASON.

Would you know where this work currently stands within the ITU?
Has this intermediate or mid-level document been created?
If so, how may one get access to it, and has it been liased
to the IETF?

-Vishal

Delivery-date: Fri, 16 May 2003 20:33:47 +0000
From: "Jonathan Lang" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: FW: FW: LMP Message ID
Date: Fri, 16 May 2003 13:33:27 -0700

Sorry, I meant to cc ccamp on this.

-Jonathan

> -----Original Message-----
> From: Jonathan Lang [mailto:[email-masked]] 
> Sent: Thursday, May 15, 2003 1:02 PM
> To: 'Baktha Muralidharan'
> Subject: RE: FW: LMP Message ID
> 
> 
> Baktha,
>   Retransmitted messages should have the same Message Id as 
> the originally transmitted message.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: Baktha Muralidharan [mailto:[email-masked]]
> > Sent: Wednesday, May 14, 2003 8:03 AM
> > To: Manoj Agiwal
> > Cc: 'Ccamp (E-mail); [email-masked]'
> > Subject: Re: FW: LMP Message ID
> > 
> > 
> > At 12:37 AM 5/13/2003 -0500, Manoj Agiwal wrote:
> > >Hi ,
> > >       Lmp drafts tells that Message ID should be monotonically
> > >increasing .
> > >
> > >       Section 7 also tells that "Unacknowledge messages sent with
> > >Message_id object should be retransmitted until the message is
> > >       acknowledged or until retry limit is reached."
> > >
> > >       Do we have to sent all retransmitted messages with the same
> > >Message Id as sent previously or it should be in monotonically
> > >       increasing order.
> > >
> > >Regards ,
> > >Manoj
> > 
> > Hi Manoj,
> > 
> > An unacknowledged message could have been lost; i.e. might
> > not have reached the neighbor. So, the neighbor has no way of 
> > determining if a message is a re-transmit and will fail [and 
> > nack] a message with out-of-order message-id.
> > 
> > So, re-transmit attempts should increase message id.
> > 
> > /Baktha Muralidharan
> >   Cisco Systems.
> > 
> 

Delivery-date: Fri, 16 May 2003 20:32:24 +0000
From: "Jonathan Lang" <[email-masked]>
To: "'Bradford, Richard'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-rbradfor-ccamp-lmp-lol-01.txt 
Date: Fri, 16 May 2003 13:30:53 -0700

Richard,
  I read the draft and I like it.  More comments inline.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bradford, Richard
> Sent: Friday, May 16, 2003 7:35 AM
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-rbradfor-ccamp-lmp-lol-01.txt=20
>=20
>=20
> I'd like to get feedback from the list on the this draft. In=20
> addition to any problems with the draft itself:
> a) Does it solve the problem of Link Verification for OXCs?
I think "the problem" can be solved with existing mechanisms, but I like
your proposal.

> b) If this isn't used, then how will Link Verification be=20
> performed for pure OXCs? Addition of Link Termination modules=20
> such as OC-48 and 10GigE? Build test circuits through the switches?
One way to do it is switch the port to an internal "test" port.  Is this
what you mean by "build test circuits"?

> c) Will carriers deploy (i.e. not just lab trials) OXCs=20
> without Link Verification capabilities?
I highly doubt it, but I'll let them add their input.

Thanks,
Jonathan

>=20
>=20
>=20
>=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
>=20
>=20
>         Title           : Link Management Protocol Extensions for Link
> discovery
>                           Using Loss of Light
>         Author(s)       : R. Bradford, D. Papadimitriou, D. Tappan
>         Filename        : draft-rbradfor-ccamp-lmp-lol-01.txt
>         Pages           : 13
>         Date            : 2003-4-11
>        =20
> This document proposes an enhanced mechanism for Link=20
> Management Protocol=C6s Link Verification procedure that is=20
> independent of the data encoding type. It can be used for any=20
> point-to-point link, including both Optical Links and=20
> SONET/SDH Links. The general proposal is to use the=20
> transmission of light by the sender and recognition of the=20
> presence or absence of light by the receiver to identify port=20
> mapping.  The proposal includes minor extensions to the=20
> existing messages to implement this extension to the link=20
> verification procedure.
>=20
> A URL for this Internet-Draft is:=20
> http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-lmp-l
ol-01.txt

To remove yourself from the IETF Announcement list, send a message to=20
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-rbradfor-ccamp-lmp-lol-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
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-rbradfor-ccamp-lmp-lol-01.txt".
       =20
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.
               =20
               =20
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-rbradfor-ccamp-lmp-lol-01.txt>

Delivery-date: Fri, 16 May 2003 15:59:50 +0000
From: "Stephen Shew" <[email-masked]>
To: "'Stephen Trowbridge'" <[email-masked]>, John Drake <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Fri, 16 May 2003 11:59:15 -0400

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

------_=_NextPart_001_01C31BC4.19E6EC50
Content-Type: text/plain

I have read the requirements draft (and most of this thread) and tend to
agree with Stephen T. that the problem is not entirely clear.  However, for
the purpose of dialogue between standards bodies, having a CCAMP WG document
to liaise is helpful.  In that regard I fine with it progressing to a CCAMP
WG document.

One major technical comment I have is that the ASON addressing requirements
aren't fully represented.  For example, "G.8080 defines a UNI Transport
Resource Addresses for the bearer links at the UNI reference point" (from
G.7713.2 and G.7713.3).  This is important for ASON services.  Also,
reference points and call segments are missing.  I would hope these can be
discussed between CCAMP and SG15.  Hence a liaison would be helpful.

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]] 
Sent: Wednesday, May 14, 2003 11:59
To: John Drake
Cc: Ash, Gerald R (Jerry), ALABS; Wijnen, Bert (Bert); [email-masked]
Subject: Re: ASON reqts

John,
I still think it is better to argue it out now and reach agreement on what
problem we are trying to solve.

If we accept this as a WG draft without doing this, we seem to be accepting
that we do have SOME problem to solve, and then arguing later on what it
was. Regards, Steve

John Drake wrote:
> 
> Regardless of what we do now, I'm sure there will be lots of arguments 
> later.
> 
<snip>

------_=_NextPart_001_01C31BC4.19E6EC50
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: ASON reqts</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I have read the requirements draft (and most of this =
thread) and tend to agree with Stephen T. that the problem is not =
entirely clear.&nbsp; However, for the purpose of dialogue between =
standards bodies, having a CCAMP WG document to liaise is =
helpful.&nbsp; In that regard I fine with it progressing to a CCAMP WG =
document.</FONT></P>

<P><FONT SIZE=3D2>One major technical comment I have is that the ASON =
addressing requirements aren't fully represented.&nbsp; For example, =
&quot;G.8080 defines a UNI Transport Resource Addresses for the bearer =
links at the UNI reference point&quot; (from G.7713.2 and =
G.7713.3).&nbsp; This is important for ASON services.&nbsp; Also, =
reference points and call segments are missing.&nbsp; I would hope =
these can be discussed between CCAMP and SG15.&nbsp; Hence a liaison =
would be helpful.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stephen Trowbridge [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, May 14, 2003 11:59</FONT>
<BR><FONT SIZE=3D2>To: John Drake</FONT>
<BR><FONT SIZE=3D2>Cc: Ash, Gerald R (Jerry), ALABS; Wijnen, Bert =
(Bert); [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: ASON reqts</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>John,</FONT>
<BR><FONT SIZE=3D2>I still think it is better to argue it out now and =
reach agreement on what problem we are trying to solve.</FONT>
</P>

<P><FONT SIZE=3D2>If we accept this as a WG draft without doing this, =
we seem to be accepting that we do have SOME problem to solve, and then =
arguing later on what it was. Regards, Steve</FONT></P>

<P><FONT SIZE=3D2>John Drake wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regardless of what we do now, I'm sure there =
will be lots of arguments </FONT>
<BR><FONT SIZE=3D2>&gt; later.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C31BC4.19E6EC50--

Delivery-date: Fri, 16 May 2003 15:53:03 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'Stephen Shew' <[email-masked]>,  "'Ash, Gerald R (Jerry), ALABS'" <[email-masked]>, Jonathan Sadler <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Fri, 16 May 2003 08:54:24 -0700

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_01C31BC3.6C549100
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Folks,
 
Slightly off the topic, but for routing, I think one impact of the control and bearer
plane separation is that the identification of the link (in the transport plane)
is really separate from the identification of the routing controller advertising
the link (in the control plane).  You could also implement the routing controller
as a physically separate system from the transport node, as opposed to being
combined as in an LSR.
 
Cheers,
 
Lyndon

-----Original Message-----
From: Stephen Shew [mailto:[email-masked]]
Sent: Friday, May 16, 2003 8:08 AM
To: 'Ash, Gerald R (Jerry), ALABS'; Jonathan Sadler
Cc: [email-masked]
Subject: RE: ASON reqts

On #4, use of transport plane names is an important part of ASON architecture which separates control from bearer planes.  In G.7713.x we have the following text:

"Addressing of transport resources in the protocol is done by SNPP identifiers.  A pair of these would identify an SNPP link.  SNPP names are defined from transport name spaces (see Section 10, G.8080) and it is important to note that control plane names/addresses are not used for these.  For example, neither routing controller nor connection manager identifiers are used for bearer link names."

This affects things that describe the context of a GMPLS label.  For example, the hop objects in an explicit route.  They need to make sense to the transport plane in the absence of signalling.

-----Original Message----- 
From: Ash, Gerald R (Jerry), ALABS [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, May 15, 2003 18:52 
To: Jonathan Sadler 
Cc: Ash, Gerald R (Jerry), ALABS; [email-masked] 
Subject: RE: ASON reqts 

Jonathan, 

I've looked back over your posts, and have a few comments. 

We agree with you that at this stage we should 'focus on the requirements, not the solution'.  Regarding your suggestions on the requirements, so far I think you've suggested 4 additional requirements:

1. Discussion of required behavior at E-NNI and UNI reference points. 2. Support for complete Call/Connection separation, including 0-connection calls 3. Explicit support for connection partitioning in different administrative domains. 

4. Use of transport plane names instead of DCN addresses when referring to transport plane resources. 

#2 is clear, and we agree to add '0-connection calls' to the requirements I-D.  #1, 3, and 4 aren't very specific/clear, and we'd like some clarification:

#1 What does 'required behavior' mean here? 
#3 Connection partitions are not across ADs, perhaps this issue relates to session split across ADs? #4 We're using transport plane names, however GMPLS allows for both, perhaps this is an implementation issue?

------_=_NextPart_001_01C31BC3.6C549100
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: ASON reqts</TITLE>

<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=571024015-16052003><FONT face=Arial color=#0000ff size=2>Hi 
Folks,</FONT></SPAN></DIV>
<DIV><SPAN class=571024015-16052003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=571024015-16052003><FONT face=Arial color=#0000ff 
size=2>Slightly off the topic, but for routing, I think one impact of the 
control and bearer</FONT></SPAN></DIV>
<DIV><SPAN class=571024015-16052003><FONT face=Arial color=#0000ff size=2>plane 
separation is that the identification of the link (in the transport 
plane)</FONT></SPAN></DIV>
<DIV><SPAN class=571024015-16052003><FONT face=Arial color=#0000ff size=2>is 
really separate from the identification of the routing controller 
advertising</FONT></SPAN></DIV>
<DIV><SPAN class=571024015-16052003><FONT face=Arial color=#0000ff size=2>the 
link (in the control plane).&nbsp; You could also&nbsp;implement the routing 
controller</FONT></SPAN></DIV>
<DIV><SPAN class=571024015-16052003><FONT face=Arial color=#0000ff size=2>as a 
physically separate system&nbsp;from the transport node, as opposed to 
being</FONT></SPAN></DIV>
<DIV><SPAN class=571024015-16052003><FONT face=Arial color=#0000ff 
size=2>combined as in an LSR.</FONT></SPAN></DIV>
<DIV><SPAN class=571024015-16052003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=571024015-16052003><FONT face=Arial color=#0000ff 
size=2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=571024015-16052003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=571024015-16052003><FONT face=Arial color=#0000ff 
size=2>Lyndon</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Stephen Shew 
  [mailto:[email-masked]]<BR><B>Sent:</B> Friday, May 16, 2003 8:08 
  AM<BR><B>To:</B> 'Ash, Gerald R (Jerry), ALABS'; Jonathan Sadler<BR><B>Cc:</B> 
  [email-masked]<BR><B>Subject:</B> RE: ASON reqts<BR><BR></FONT></DIV>
  <P><FONT size=2>On #4, use of transport plane names is an important part of 
  ASON architecture which separates control from bearer planes.&nbsp; In 
  G.7713.x we have the following text:</FONT></P>
  <P><FONT size=2>"Addressing of transport resources in the protocol is done by 
  SNPP identifiers.&nbsp; A pair of these would identify an SNPP link.&nbsp; 
  SNPP names are defined from transport name spaces (see Section 10, G.8080) and 
  it is important to note that control plane names/addresses are not used for 
  these.&nbsp; For example, neither routing controller nor connection manager 
  identifiers are used for bearer link names."</FONT></P>
  <P><FONT size=2>This affects things that describe the context of a GMPLS 
  label.&nbsp; For example, the hop objects in an explicit route.&nbsp; They 
  need to make sense to the transport plane in the absence of 
  signalling.</FONT></P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Ash, 
  Gerald R (Jerry), ALABS [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT><BR><FONT 
  size=2>Sent: Thursday, May 15, 2003 18:52</FONT> <BR><FONT size=2>To: Jonathan 
  Sadler</FONT> <BR><FONT size=2>Cc: Ash, Gerald R (Jerry), ALABS; 
  [email-masked]</FONT> <BR><FONT size=2>Subject: RE: ASON reqts</FONT> 
  </P><BR>
  <P><FONT size=2>Jonathan,</FONT> </P>
  <P><FONT size=2>I've looked back over your posts, and have a few 
  comments.</FONT> </P>
  <P><FONT size=2>We agree with you that at this stage we should 'focus on the 
  requirements, not the solution'.&nbsp; Regarding your suggestions on the 
  requirements, so far I think you've suggested 4 additional 
  requirements:</FONT></P>
  <P><FONT size=2>1. Discussion of required behavior at E-NNI and UNI reference 
  points. 2. Support for complete Call/Connection separation, including 
  0-connection calls 3. Explicit support for connection partitioning in 
  different administrative domains. </FONT></P>
  <P><FONT size=2>4. Use of transport plane names instead of DCN addresses when 
  referring to transport plane resources.</FONT> </P>
  <P><FONT size=2>#2 is clear, and we agree to add '0-connection calls' to the 
  requirements I-D.&nbsp; #1, 3, and 4 aren't very specific/clear, and we'd like 
  some clarification:</FONT></P>
  <P><FONT size=2>#1 What does 'required behavior' mean here?</FONT> <BR><FONT 
  size=2>#3 Connection partitions are not across ADs, perhaps this issue relates 
  to session split across ADs? #4 We're using transport plane names, however 
  GMPLS allows for both, perhaps this is an implementation 
issue?</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C31BC3.6C549100--

Delivery-date: Fri, 16 May 2003 15:10:00 +0000
From: "Stephen Shew" <[email-masked]>
To: "'Ash, Gerald R (Jerry), ALABS'" <[email-masked]>, Jonathan Sadler <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Fri, 16 May 2003 11:08:20 -0400

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

------_=_NextPart_001_01C31BBC.FC7C8E2E
Content-Type: text/plain

On #4, use of transport plane names is an important part of ASON
architecture which separates control from bearer planes.  In G.7713.x we
have the following text:
"Addressing of transport resources in the protocol is done by SNPP
identifiers.  A pair of these would identify an SNPP link.  SNPP names are
defined from transport name spaces (see Section 10, G.8080) and it is
important to note that control plane names/addresses are not used for these.
For example, neither routing controller nor connection manager identifiers
are used for bearer link names."

This affects things that describe the context of a GMPLS label.  For
example, the hop objects in an explicit route.  They need to make sense to
the transport plane in the absence of signalling.

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
Sent: Thursday, May 15, 2003 18:52
To: Jonathan Sadler
Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: RE: ASON reqts

Jonathan,

I've looked back over your posts, and have a few comments.

We agree with you that at this stage we should 'focus on the requirements,
not the solution'.  Regarding your suggestions on the requirements, so far I
think you've suggested 4 additional requirements:

1. Discussion of required behavior at E-NNI and UNI reference points. 2.
Support for complete Call/Connection separation, including 0-connection
calls 3. Explicit support for connection partitioning in different
administrative domains. 
4. Use of transport plane names instead of DCN addresses when referring to
transport plane resources.

#2 is clear, and we agree to add '0-connection calls' to the requirements
I-D.  #1, 3, and 4 aren't very specific/clear, and we'd like some
clarification:

#1 What does 'required behavior' mean here?
#3 Connection partitions are not across ADs, perhaps this issue relates to
session split across ADs? #4 We're using transport plane names, however
GMPLS allows for both, perhaps this is an implementation issue?

------_=_NextPart_001_01C31BBC.FC7C8E2E
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: ASON reqts</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>On #4, use of transport plane names is an important =
part of ASON architecture which separates control from bearer =
planes.&nbsp; In G.7713.x we have the following text:</FONT></P>

<P><FONT SIZE=3D2>&quot;Addressing of transport resources in the =
protocol is done by SNPP identifiers.&nbsp; A pair of these would =
identify an SNPP link.&nbsp; SNPP names are defined from transport name =
spaces (see Section 10, G.8080) and it is important to note that =
control plane names/addresses are not used for these.&nbsp; For =
example, neither routing controller nor connection manager identifiers =
are used for bearer link names.&quot;</FONT></P>

<P><FONT SIZE=3D2>This affects things that describe the context of a =
GMPLS label.&nbsp; For example, the hop objects in an explicit =
route.&nbsp; They need to make sense to the transport plane in the =
absence of signalling.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ash, Gerald R (Jerry), ALABS [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, May 15, 2003 18:52</FONT>
<BR><FONT SIZE=3D2>To: Jonathan Sadler</FONT>
<BR><FONT SIZE=3D2>Cc: Ash, Gerald R (Jerry), ALABS; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: ASON reqts</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Jonathan,</FONT>
</P>

<P><FONT SIZE=3D2>I've looked back over your posts, and have a few =
comments.</FONT>
</P>

<P><FONT SIZE=3D2>We agree with you that at this stage we should 'focus =
on the requirements, not the solution'.&nbsp; Regarding your =
suggestions on the requirements, so far I think you've suggested 4 =
additional requirements:</FONT></P>

<P><FONT SIZE=3D2>1. Discussion of required behavior at E-NNI and UNI =
reference points. 2. Support for complete Call/Connection separation, =
including 0-connection calls 3. Explicit support for connection =
partitioning in different administrative domains. </FONT></P>

<P><FONT SIZE=3D2>4. Use of transport plane names instead of DCN =
addresses when referring to transport plane resources.</FONT>
</P>

<P><FONT SIZE=3D2>#2 is clear, and we agree to add '0-connection calls' =
to the requirements I-D.&nbsp; #1, 3, and 4 aren't very specific/clear, =
and we'd like some clarification:</FONT></P>

<P><FONT SIZE=3D2>#1 What does 'required behavior' mean here?</FONT>
<BR><FONT SIZE=3D2>#3 Connection partitions are not across ADs, perhaps =
this issue relates to session split across ADs? #4 We're using =
transport plane names, however GMPLS allows for both, perhaps this is =
an implementation issue?</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C31BBC.FC7C8E2E--

Delivery-date: Fri, 16 May 2003 14:42:56 +0000
From: "Hirokazu Ishimatsu" <[email-masked]>
To: <[email-masked]>
Subject: RE: ASON reqts
Date: Fri, 16 May 2003 23:42:26 +0900

List,

I have read this document and it is ready to be a CCAMP WG doc

because of 2 in Steve's email.

Hiro Ishimatsu

> I think I have detected the following motivations from 
> different posts in the thread:
> 
> 1. Those who don't want this to be a WG document (we are done with
>    this version of the specifications, lets get some experience
>    with them before considering any further change or evolution).
> 
> 2. Those who think this should be a WG document so that ASON 
> extensions
>    currently standardized in ITU-T will get standards track status in
>    IETF (no intent to change the protocol, but document the superset
>    in one place so that we don't get so many GMPLS implementations
>    that don't support the ASON extensions).
> 
> 3. Those who think there is nothing wrong with the ITU-T extensions to
>    meet the ASON requirements, but believe that RFC 3474 
> didn't translate
>    G.7713.2 properly and this draft is a first step to fixing 
> RFC 3474.
> 
> 4. Those who think that even the ITU-T extensions don't meet the ASON
>    requirements, so IETF should now take it over and do it 
> better starting
>    with this draft.
> 
> 5. Those who think that ITU-T didn't get the requirements right, so we
>    need to look at everything from scratch.
> 
> Regards,
> Steve

Delivery-date: Fri, 16 May 2003 14:40:09 +0000
Date: Fri, 16 May 2003 10:34:47 -0400
To: [email-masked]
From: "Bradford, Richard" <[email-masked]>
Subject: Re: I-D ACTION:draft-rbradfor-ccamp-lmp-lol-01.txt 

--=====================_79901342==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

I'd like to get feedback from the list on the this draft. In addition to=20
any problems with the draft itself:
a) Does it solve the problem of Link Verification for OXCs?
b) If this isn't used, then how will Link Verification be performed for=20
pure OXCs? Addition of Link Termination modules such as OC-48 and 10GigE?=20
Build test circuits through the switches?
c) Will carriers deploy (i.e. not just lab trials) OXCs without Link=20
Verification capabilities?

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

         Title           : Link Management Protocol Extensions for Link=20
discovery
                           Using Loss of Light
         Author(s)       : R. Bradford, D. Papadimitriou, D. Tappan
         Filename        : draft-rbradfor-ccamp-lmp-lol-01.txt
         Pages           : 13
         Date            : 2003-4-11

This document proposes an enhanced mechanism for Link Management
Protocol=C6s Link Verification procedure that is independent of the
data encoding type. It can be used for any point-to-point link,
including both Optical Links and SONET/SDH Links. The general
proposal is to use the transmission of light by the sender and
recognition of the presence or absence of light by the receiver
to identify port mapping.  The proposal includes minor extensions
to the existing messages to implement this extension to the link
verification procedure.

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-rbradfor-ccamp-lmp-lol-01.txt>

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

<html>
<font face=3D"Courier New, Courier" size=3D2>I'd like to get feedback from
the list on the this draft. In addition to any problems with the draft
itself:<br>
a) Does it solve the problem of Link Verification for OXCs?<br>
b) If this isn't used, then how will Link Verification be performed for
pure OXCs? Addition of Link Termination modules such as OC-48 and 10GigE?
Build test circuits through the switches?<br>
c) Will carriers deploy (i.e. not just lab trials) OXCs without Link
Verification capabilities?<br>
<br>
<br>
<br>
<br>
<br>
A New Internet-Draft is available from the on-line Internet-Drafts
directories.<br>
<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Title<x-tab>&=
nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;</x-tab>:
Link Management Protocol Extensions for Link discovery<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Using Loss of Light<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Author(s)<x-t=
ab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>:
R. Bradford, D. Papadimitriou, D. Tappan<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Filename<x-ta=
b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>:
draft-rbradfor-ccamp-lmp-lol-01.txt<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Pages<x-tab>&=
nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;</x-tab>:
13<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Date<x-tab>&n=
bsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;</x-tab>:
2003-4-11<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
This document proposes an enhanced mechanism for Link Management<br>
Protocol=C6s Link Verification procedure that is independent of the<br>
data encoding type. It can be used for any point-to-point link,<br>
including both Optical Links and SONET/SDH Links. The general<br>
proposal is to use the transmission of light by the sender and<br>
recognition of the presence or absence of light by the receiver<br>
to identify port mapping.&nbsp; The proposal includes minor
extensions<br>
to the existing messages to implement this extension to the link<br>
verification procedure.<br>
<br>
A URL for this Internet-Draft is:<br>
</font><font face=3D"Courier New, Courier" size=3D2 color=3D"#0000FF"><u><a=
 href=3D"http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-lmp-lol-01=
.txt"=
 eudora=3D"autourl">http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp=
-lmp-lol-01.</a><a=
 href=3D"http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-lmp-lol-01=
.txt" eudora=3D"autourl">txt<br>
<br>
</a></u></font><font face=3D"Courier New, Courier" size=3D2>To remove
yourself from the IETF Announcement list, send a message to <br>
ietf-announce-request with the word unsubscribe in the body of the
message.<br>
<br>
Internet-Drafts are also available by anonymous FTP. Login with the
username<br>
&quot;anonymous&quot; and a password of your e-mail address. After
logging in,<br>
type &quot;cd internet-drafts&quot; and then<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&quot;get
draft-rbradfor-ccamp-lmp-lol-01.txt&quot;.<br>
<br>
A list of Internet-Drafts directories can be found in<br>
</font><font face=3D"Courier New, Courier" size=3D2 color=3D"#0000FF"><u><a=
 href=3D"http://www.ietf.org/shadow.html"=
 eudora=3D"autourl">http://www.ietf.org/shadow.</a><a=
 href=3D"http://www.ietf.org/shadow.html"=
 eudora=3D"autourl">html</a></u></font><font face=3D"Courier New, Courier" s=
ize=3D2>
<br>
or
</font><a href=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt"=
 eudora=3D"autourl"><font face=3D"Courier New, Courier" size=3D2=
 color=3D"#0000FF"><u>ftp://ftp.ietf.org/ietf/1shadow-sites.</a><a=
 href=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" eudora=3D"autourl">txt<b=
r>
<br>
<br>
</a></u></font><font face=3D"Courier New, Courier" size=3D2>Internet-Drafts
can also be obtained by e-mail.<br>
<br>
Send a message to:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>mailserv@ietf=
.org.<br>
In the body type:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&quot;FILE
/internet-drafts/draft-rbradfor-ccamp-lmp-lol-01.txt&quot;.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
NOTE:<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>The mail server at ietf.org can
return the document in<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>MIME-encoded
form by using the &quot;mpack&quot; utility.&nbsp; To use this<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>feature,
insert the command &quot;ENCODING mime&quot; before the
&quot;FILE&quot;<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>command.&nbsp=
;
To decode the response(s), you will need &quot;munpack&quot; or<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>a
MIME-compliant mail reader.&nbsp; Different MIME-compliant mail
readers<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>exhibit
different behavior, especially when dealing with<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&quot;multipa=
rt&quot;
MIME messages (i.e. documents which have been split<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>up into
multiple messages), so check your local documentation on<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>how to
manipulate these messages.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
Below is the data which will enable a MIME compliant mail reader<br>
implementation to automatically retrieve the ASCII version of the<br>
Internet-Draft.<br>
</font><font size=3D3 color=3D"#0000FF"><u>&lt;<a=
 href=3D"ftp://ftp.ietf.org/internet-drafts/draft-rbradfor-ccamp-lmp-lol-01.=
txt"=
 eudora=3D"autourl">ftp://ftp.ietf.org/internet-drafts/draft-rbradfor-ccamp-=
lmp-lol-01.txt</a>&gt;<br>
</font></u><br>

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

--=====================_79901342==_.ALT--

Delivery-date: Fri, 16 May 2003 11:59:43 +0000
Date: Fri, 16 May 2003 13:57:17 +0200
From: Dieter Beller <[email-masked]>
Organization: Alcatel SEL AG, OND Stuttgart, Germany
To: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
CC: [email-masked], Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

Jerry, Vishal, and all,

Ash, Gerald R (Jerry), ALABS wrote:

> Vishal,
> Kireeti,
> 
> 

<snip>

> 
>>I believe the initial routing requirements are captured in ITU doc.
>>G.7715. However, I am not sure whether, unlike signaling, the ITU has
>>begun work on the protocol-specific instantiations of routing 
>>requirements.
> 

The conclusion drawn from some initial discussions on specific
routing protocols was to step back for a moment and develop a
so-called mid-level requirements recommendation for a link state
routing protocol which still should be protocol neutral. This
requirements recommendation will then be used for the assessment
of existing link state routing protocols to be applied in ASON.

> 
> That is my understanding as well.  The GMPLS-ASON routing requirements should be based on the ITU-T G.7715 requirements.  
> 
> Hopefully the IETF will progress GMPLS-ASON routing extensions to meet the requirements, so that hopefully the ITU will not need to undertake protocol-specific extensions of GMPLS routing.  And hopefully this would then avoid another G.7713.2-like debacle.
> 
> I believe that ASON routing work is the subject of an ITU-T experts' meeting of Question 14/15, to be held in Chicago 9-13 June 2003.  The ITU-T has invited the IETF GMPLS routing experts to participate, as per Wesam's presentation documented in the IETF-56/CCAMP meeting minutes http://ietf.org/proceedings/03mar/minutes/ccamp.htm.
>

I fully share your view - the idea was indeed to invite IETF GMPLS
routing experts in order to have a closer and much better cooperation
on routing compared to what happened with signaling.

Furthermore, I would like to add that I have read this document
and it is ready to be a CCAMP WG doc (being aware that some
issues need further discussion or clarification which shouldn't
preclude that this document becomes a WG doc)

Dieter

Delivery-date: Fri, 16 May 2003 09:16:46 +0000
From: Manoj Agiwal <[email-masked]>
To: 'Baktha Muralidharan' <[email-masked]>, Manoj Agiwal <[email-masked]>
Cc: "'Ccamp (E-mail)" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: FW: LMP Message ID
Date: Fri, 16 May 2003 04:07:16 -0500

Hi Bakhta ,

     Neighbour is only interested in knowing if the message is out-of-order
or not. If retransmission algorithm sends the message with the same Message
Id , Neighbor will not
consider it as out-of-order and process it. Out of order condition being
(int)oldmsgid - (int)newmsgid > 0
In case a new message is received with a greater Message id and latter
Neighbor receives the re-transmitted message , re-transmitted message should
be discarded as it is out-of-order.

      New message identifies change in configuration and should be send with
a higher message id and should be accepted by neighbor while re-trnasmitted
message represents old values and should be discarded.

     I feel if retransmitted message is sent with the same message Id or new
message id ,
it does not matter , since in either case neighboring node will process it
completely.
Only disadvantage is one will eat away Message Id space at faster rate if
new message id is
generated for every re-transmitted message.

Regards ,
Manoj

-----Original Message-----
From: Baktha Muralidharan [mailto:[email-masked]]
Sent: Wednesday, May 14, 2003 8:33 PM
To: Manoj Agiwal
Cc: 'Ccamp (E-mail); [email-masked]'
Subject: Re: FW: LMP Message ID

At 12:37 AM 5/13/2003 -0500, Manoj Agiwal wrote:
>Hi ,
>       Lmp drafts tells that Message ID should be monotonically increasing
.
>
>       Section 7 also tells that "Unacknowledge messages sent with
Message_id
>object should be retransmitted until the message is
>       acknowledged or until retry limit is reached."
>
>       Do we have to sent all retransmitted messages with the same Message
Id
>as sent previously or it should be in monotonically
>       increasing order.
>
>Regards ,
>Manoj

Hi Manoj,

An unacknowledged message could have been lost; i.e. might not have reached
the neighbor. So, the neighbor has no way of determining if a message is
a re-transmit and will fail [and nack] a message with out-of-order
message-id.

So, re-transmit attempts should increase message id.

/Baktha Muralidharan
  Cisco Systems.

Delivery-date: Thu, 15 May 2003 22:55:23 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Thu, 15 May 2003 17:52:28 -0500
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: "Jonathan Sadler" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, <[email-masked]>

Jonathan,

I've looked back over your posts, and have a few comments.

We agree with you that at this stage we should 'focus on the =
requirements, not the solution'.  Regarding your suggestions on the =
requirements, so far I think you've suggested 4 additional requirements:

1. Discussion of required behavior at E-NNI and UNI reference points.
2. Support for complete Call/Connection separation, including =
0-connection calls
3. Explicit support for connection partitioning in different =
administrative domains.=20
4. Use of transport plane names instead of DCN addresses when referring =
to transport plane resources.

#2 is clear, and we agree to add '0-connection calls' to the =
requirements I-D.  #1, 3, and 4 aren't very specific/clear, and we'd =
like some clarification:

#1 What does 'required behavior' mean here?
#3 Connection partitions are not across ADs, perhaps this issue relates =
to session split across ADs?
#4 We're using transport plane names, however GMPLS allows for both, =
perhaps this is an implementation issue?

We agree that if these are ASON requirements (regardless of whether =
signaling changes
are needed) we should list them in the I-D.  If some are ASON =
requirements that are not applicable to GMPLS we should list and say so.

Regarding G.7713.1, you pointed out that 'the ATM Forum certainly did =
add Information Elements in order to support ASON services.'

We agree with this approach, and that's the model we're following here, =
the IETF should deliver (by WG consensus) the agreed-on 'IEs' (objects) =
to support the ASON requirements.

Regarding the basis for the ASON requirements, you said that =
'draft-lin-ccamp-gmpls-ason-rsvpte-00.txt was originally contributed in =
June 2002.'

We'd like to point out that the GMPLS-ASON requirements I-D is based on =
draft-lin-ccamp-gmpls-ason-rqts-00.txt, originally contributed in August =
2002.

Thanks,
Jerry

Delivery-date: Thu, 15 May 2003 20:55:41 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Thu, 15 May 2003 15:52:54 -0500
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, <[email-masked]>

Vishal,
Kireeti,

> I should have clarified that I did not mean that the two pieces of
> work (routing and signaling) should be so tightly coupled that one
> cannot proceed independently of the other. What I did mean was that
> it would be better to initiate the routing work as well, so that=20
> any impact that routing has on signaling is captured in the signaling
> work early on. This will be useful, as it'll prevent problems later.

Agreed.  We should progress the GMPLS-ASON routing requirements in a =
separate, parallel effort to the GMPLS-ASON signaling requirements.

> I believe the initial routing requirements are captured in ITU doc.
> G.7715. However, I am not sure whether, unlike signaling, the ITU has
> begun work on the protocol-specific instantiations of routing=20
> requirements.

That is my understanding as well.  The GMPLS-ASON routing requirements =
should be based on the ITU-T G.7715 requirements. =20

Hopefully the IETF will progress GMPLS-ASON routing extensions to meet =
the requirements, so that hopefully the ITU will not need to undertake =
protocol-specific extensions of GMPLS routing.  And hopefully this would =
then avoid another G.7713.2-like debacle.

I believe that ASON routing work is the subject of an ITU-T experts' =
meeting of Question 14/15, to be held in Chicago 9-13 June 2003.  The =
ITU-T has invited the IETF GMPLS routing experts to participate, as per =
Wesam's presentation documented in the IETF-56/CCAMP meeting minutes =
http://ietf.org/proceedings/03mar/minutes/ccamp.htm.

Jerry

Delivery-date: Thu, 15 May 2003 18:42:40 +0000
From: "Ong, Lyndon" <[email-masked]>
To: "'Brungard, Deborah A, ALABS'" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, Stephen Trowbridge <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: ASON reqts
Date: Thu, 15 May 2003 11:44:02 -0700

Hi Deborah,

Regarding the requirements, it sounds to me as if the scope
of ccamp efforts is somewhat different from the scope of
the sg15 effort, so the result of discussion may be also
different.  I would hope that we can make an extra effort
to avoid diverging.

Cheers,

Lyndon

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Wednesday, May 14, 2003 1:33 PM
To: Ong, Lyndon; Stephen Trowbridge
Cc: Wijnen, Bert (Bert); [email-masked]; [email-masked]
Subject: RE: ASON reqts

Thanks Lyndon for asking clarification-

I was trying to say that ASON does not require supporting multiple address formats for a E-PC (Protocol Controller) e.g. G7713.1.

Similar to NSAP support of IP, IPv6 supports NSAP.

Can you clarify your take on the requirements discussion? If I read the email, the discussion was related to the definition of a control domain and support of a non-RSVP domain or legacy (management system). The answer for supporting a non-RSVP domain was the need for an interworking function (which was considered out of scope). This is analogous to ITU's work, both for G7713.1 (PNNI) and G7713.2, the interworking functions are considered out of scope. And support of legacy is via SPC (same as G7713.1) and it is included. Were any other requirements identified as missing?

Deborah

Delivery-date: Thu, 15 May 2003 17:47:27 +0000
Date: Thu, 15 May 2003 11:30:05 -0500
From: Ben Mack-Crane <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: ASON reqts

Hi Kireeti,

G.8080 (ASON Architecture) addresses both signaling and routing, and 
thereafter the two areas are addressed in separate documents.  I agree 
that it is good to keep these separate from a protocol perspective.  I 
suppose it is OK to write separate requirements documents for each area 
as long as requirements are not missed in the process.  This would still 
mean that routing or high-level architectural issues that impact 
signaling should be considered in determining the signaling requirements.

Considering the discussion on the list, I tend to agree with the idea 
that the ASON requirements have already been documented in G.7713 and 
G.7715 and creating additional documents that overlap these will likely 
only add additional confusion.  Therefore I'm not convinced that this 
should be a WG doc, even as signaling only.

Regards,
Ben

Kireeti Kompella wrote:
> Hi Ben,
> 
> On Wed, 14 May 2003, Ben Mack-Crane wrote:
> 
> 
>>CCAMPers,
>>
>>Having reviewed the proposed requirements draft, and some of the ensuing
>>e-mail discussion, I would say that
>>
>>"I have read this document, and it isn't ready to be a CCAMP doc"
> 
> 
> Thanks for your input (thanks too to all others who've voiced their
> opinion).
> 
> 
>>I am principally concerned that routing requirements are not included.
>>While draft's title is encompassing "GMPLS Usage and Extensions for
>>ASON," the abstract limits this to signaling only.
> 
> 
> You're right -- this document doesn't address routing (and doesn't
> profess to).  In keeping with other GMPLS work, I think it makes sense
> to have separate signaling and routing documents, be they functional
> specs, protocol details or requirements.  This view appears to be
> shared by the ITU-T as well, from what I understand.
> 
> In the light of this, I have a question for you:
>  - In your opinion, should the document under consideration become a
>    CCAMP WG _just for signaling_?  I.e., if we had a companion doc
>    that described the routing requirements for ASON, would that meet
>    your objection?
> 
> Thanks,
> Kireeti.
> 

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

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

Delivery-date: Thu, 15 May 2003 16:47:51 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: IESG approved: draft-ietf-ccamp-tracereq-02.txt for Informational
Date: Thu, 15 May 2003 18:45:59 +0200

IESG just approved this revision of the document.
Formal annoucement will follow from the IESG secretariat
in the next few days.

Thanks,
Bert 

Delivery-date: Thu, 15 May 2003 15:40:57 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>
Cc: "Ben Mack-Crane" <[email-masked]>, <[email-masked]>
Subject: RE: ASON reqts
Date: Thu, 15 May 2003 11:36:21 -0400

Kireeti,

Thanks for your note. Some clarifications in-line.

-Vishal

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Wednesday, May 14, 2003 6:03 PM
> To: Vishal Sharma
> Cc: Ben Mack-Crane; [email-masked]
> Subject: RE: ASON reqts

<snip>

> > Both documents would then have to be progressed in tandem within
> > the WG, because, as Ben rightly observed, routing specifications
> > do influence what is carried in signaling.
> 
> The progress of GMPLS signaling and routing was always separate, as
> can be seen even now: signaling has been an RFC for some time now,
> whereas routing is still in Last Call.
> 
> In fact, the charter states that signaling and routing be kept
> separate:
>  - Define signalling and measurement protocols that are independent of
>    each other.  This allows applications other than the signalling
>    protocol to use the measurement protocol; it also allows the
>    signalling protocol to use knowledge obtained by means other than the
>    measurement protocol.
> 
> This is not to say that they must be developed separately, but a
> too-strong tie between them would hurt the above goal.

I should have clarified that I did not mean that the two pieces of
work (routing and signaling) should be so tightly coupled that one
cannot proceed independently of the other. What I did mean was that
it would be better to initiate the routing work as well, so that 
any impact that routing has on signaling is captured in the signaling
work early on. This will be useful, as it'll prevent problems later.
(I think this was also largely true of the way in which 
we developed the GMPLS protocols.)

> Finally, there is a need for GMPLS for ASON signaling requirements,
> whereas there doesn't appear to be such a pressing need for GMPLS
> for ASON routing requirements.

I believe the initial routing requirements are captured in ITU doc.
G.7715. However, I am not sure whether, unlike signaling, the ITU has
begun work on the protocol-specific instantiations of routing requirements.
The apparent lack of GMPLS for ASON routing requirements might just be
a reflection of work not having begun in full swing on the routing
aspect yet. (As per my reasoning above, I would expect that the ITU too
would also be working on the routing aspect, perhaps some of the ITU 
experts here can shed more light on this.)

-Vishal

Delivery-date: Thu, 15 May 2003 11:23:45 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-tracereq-02.txt
Date: Thu, 15 May 2003 07:19:26 -0400

--NextPart

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

	Title		: Tracing Requirements for Generic Tunnels
	Author(s)	: R. Bonica, K. Kompella, D. Meyer
	Filename	: draft-ietf-ccamp-tracereq-02.txt
	Pages		: 9
	Date		: 2003-5-14
	
This document specifies requirements for a generic route-tracing
application.  It also specifies requirements for a protocol that will
support the generic route-tracing application. Network operators will
use the generic route-tracing application to verify proper operation
of the IP forwarding plane. They also use the application to discover
details regarding tunnels that support IP forwarding.

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 15 May 2003 00:30:54 +0000
From: "Ong, Lyndon" <[email-masked]>
To: "'Brungard, Deborah A, ALABS'" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, Stephen Trowbridge <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 17:33:22 -0700

Hi Deborah,

One more clarification, by legacy I meant a domain with a centralized
control structure, such as a controlling EMS or NMS.
SPC seems like more of a service type to me, which
can be supported by distributed or centralized control.

Cheers,

Lyndon  

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Wednesday, May 14, 2003 1:33 PM
To: Ong, Lyndon; Stephen Trowbridge
Cc: Wijnen, Bert (Bert); [email-masked]; [email-masked]
Subject: RE: ASON reqts

Thanks Lyndon for asking clarification-

I was trying to say that ASON does not require supporting multiple address formats for a E-PC (Protocol Controller) e.g. G7713.1.

Similar to NSAP support of IP, IPv6 supports NSAP.

Can you clarify your take on the requirements discussion? If I read the email, the discussion was related to the definition of a control domain and support of a non-RSVP domain or legacy (management system). The answer for supporting a non-RSVP domain was the need for an interworking function (which was considered out of scope). This is analogous to ITU's work, both for G7713.1 (PNNI) and G7713.2, the interworking functions are considered out of scope. And support of legacy is via SPC (same as G7713.1) and it is included. Were any other requirements identified as missing?

Deborah

Delivery-date: Wed, 14 May 2003 22:20:24 +0000
Date: Wed, 14 May 2003 22:17:03 -0500
From: Jonathan Sadler <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>
CC: Stephen Trowbridge <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: ASON reqts

Deborah -

Let me clarify:

"Brungard, Deborah A, ALABS" wrote:

> G7713.2 as you are noting (and Jonathan's mail) is using a subset of GMPLS signaling.

I am unware of making such a statement.  If anything, I see G.7713.2 as a superset of GMPLS signaling as it addresses the gaps that exist relative to ASON requirements.

> It is not based on GMPLS i.e. it uses a different addressing scheme ( based on OIF addresses, not based on IP).

Actually, the issues that I brought up are not based on any addressing implementation offered by the OIF (or any other body), but are based on the implementation-independant requirements stated in G.8080 Amd.1.  Lets focus on the requirements, not the solution.

> G7713.2 requires an interworking function plus upgrades to a RFC 3473 domain. And as G7713.2 states it "focuses on the UNI and E-NNI.. the I-NNI ..is for further study". G7713.2 is not based on any I-NNI.

G7713.2 is a solution that meets the requirements.  The extensions are necessary as the base GMPLS signalling protocol specs don't meet the requirements as-is.

> The rsvp-te-ason draft provides extensions to RFC3473 to support ASON. It is analogous to G7713.1 (for non-ITU, G7713.1 is ASON PNNI-based E-NNI/I-NNI). No one questioned the need for G7713.1 (or that it only supports NSAP addresses for E-NNI). And no one questioned a potential conflict of G7713.1 and G7713.2. And we (ITU) used G7713.1 and our relationship with the ATM Forum as an example of our expectations for working with IETF. It is really confusing to have ITU participants now questioning the need for IETF's work on a "G7713.1".

I'm not certain what your trying to get at here.  The ATM Forum certainly did add Information Elements in order to support ASON services -- and they didn't need to write a new requirements document (with "overlooked" requirements) in the process.

As for G.7713.1 only supporting NSAP addresses at the E-NNI: NSAPs have an Address Format Identifier (AFI) as the first octet that describes the remaining information in the Address.  An AFI exists for IPv6 (AFI 34 -- see ISO/IEC 8348 Amd.1) allowing for IPv6 and IPv4 addresses to be turned in NSAPs.  No separate IE Type is necessary to support IPv4 or IPv6 when NSAP support exists.

G.7713.2 could have done the same thing as G.7713.1 and only supported NSAP addresses.  However, since IPv4, and IPv6 address C-types had already been defined, they were included for backward compatability purposes.

> If you think G7713.2 meets the requirements for extending RFC3473, contribute it.

draft-lin-ccamp-gmpls-ason-rsvpte-00.txt was originally contributed in June 2002.  .01 was contributed in August 2002, and .02 was contributed in Sept 2002...

> The problem statement is "use of GMPLS (RFC3471) to provide call and connection management". The problem statement is aligned with G7713.1 on control domain definition, addressing, and functionality.

Its interesting to see that:
 - G7713.1 includes text and pictures defining control domains and how G.7713.1 fits into the definition,
 - G.7713.1 includes text describing how to support both NSAP and IP addressing
while the proposed ASON requirements draft does not...

Jonathan Sadler

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

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

Delivery-date: Wed, 14 May 2003 22:03:17 +0000
Date: Wed, 14 May 2003 15:02:34 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Vishal Sharma <[email-masked]>
cc: Ben Mack-Crane <[email-masked]>, "" <[email-masked]>
Subject: RE: ASON reqts

Hi Vishal,

On Wed, 14 May 2003, Vishal Sharma wrote:

> I've been following this discussion for some time now, and would
> like to second the proposal you've made below. Namely, that
> we have a companion document that covers extensions for routing
> as well.

Okay, noted.

> Both documents would then have to be progressed in tandem within
> the WG, because, as Ben rightly observed, routing specifications
> do influence what is carried in signaling.

The progress of GMPLS signaling and routing was always separate, as
can be seen even now: signaling has been an RFC for some time now,
whereas routing is still in Last Call.

In fact, the charter states that signaling and routing be kept
separate:
 - Define signalling and measurement protocols that are independent of
   each other.  This allows applications other than the signalling
   protocol to use the measurement protocol; it also allows the
   signalling protocol to use knowledge obtained by means other than the
   measurement protocol.

This is not to say that they must be developed separately, but a
too-strong tie between them would hurt the above goal.

Finally, there is a need for GMPLS for ASON signaling requirements,
whereas there doesn't appear to be such a pressing need for GMPLS
for ASON routing requirements.

Kireeti.

Delivery-date: Wed, 14 May 2003 21:43:14 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, "Ben Mack-Crane" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 17:42:07 -0400

Kireeti,

I've been following this discussion for some time now, and would
like to second the proposal you've made below. Namely, that
we have a companion document that covers extensions for routing
as well.

Both documents would then have to be progressed in tandem within
the WG, because, as Ben rightly observed, routing specifications
do influence what is carried in signaling.

Regards,
-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kireeti Kompella
> Sent: Wednesday, May 14, 2003 5:03 PM
> To: Ben Mack-Crane
> Cc: [email-masked]
> Subject: Re: ASON reqts
>
>
> Hi Ben,
>
> On Wed, 14 May 2003, Ben Mack-Crane wrote:
>
> > CCAMPers,
> >
> > Having reviewed the proposed requirements draft, and some of the ensuing
> > e-mail discussion, I would say that
> >
> > "I have read this document, and it isn't ready to be a CCAMP doc"
>
> Thanks for your input (thanks too to all others who've voiced their
> opinion).
>
> > I am principally concerned that routing requirements are not included.
> > While draft's title is encompassing "GMPLS Usage and Extensions for
> > ASON," the abstract limits this to signaling only.
>
> You're right -- this document doesn't address routing (and doesn't
> profess to).  In keeping with other GMPLS work, I think it makes sense
> to have separate signaling and routing documents, be they functional
> specs, protocol details or requirements.  This view appears to be
> shared by the ITU-T as well, from what I understand.
>
> In the light of this, I have a question for you:
>  - In your opinion, should the document under consideration become a
>    CCAMP WG _just for signaling_?  I.e., if we had a companion doc
>    that described the routing requirements for ASON, would that meet
>    your objection?
>
> Thanks,
> Kireeti.
>
>

Delivery-date: Wed, 14 May 2003 21:03:19 +0000
Date: Wed, 14 May 2003 14:02:35 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Ben Mack-Crane <[email-masked]>
cc: [email-masked]
Subject: Re: ASON reqts

Hi Ben,

On Wed, 14 May 2003, Ben Mack-Crane wrote:

> CCAMPers,
>
> Having reviewed the proposed requirements draft, and some of the ensuing
> e-mail discussion, I would say that
>
> "I have read this document, and it isn't ready to be a CCAMP doc"

Thanks for your input (thanks too to all others who've voiced their
opinion).

> I am principally concerned that routing requirements are not included.
> While draft's title is encompassing "GMPLS Usage and Extensions for
> ASON," the abstract limits this to signaling only.

You're right -- this document doesn't address routing (and doesn't
profess to).  In keeping with other GMPLS work, I think it makes sense
to have separate signaling and routing documents, be they functional
specs, protocol details or requirements.  This view appears to be
shared by the ITU-T as well, from what I understand.

In the light of this, I have a question for you:
 - In your opinion, should the document under consideration become a
   CCAMP WG _just for signaling_?  I.e., if we had a companion doc
   that described the routing requirements for ASON, would that meet
   your objection?

Thanks,
Kireeti.

Delivery-date: Wed, 14 May 2003 20:48:40 +0000
Date: Wed, 14 May 2003 13:48:11 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Adrian Farrel <[email-masked]>
cc: [email-masked]
Subject: Re: ASON reqts - Moving on?

On Wed, 14 May 2003, Adrian Farrel wrote:

> Can we back off a bit and just look at the ASON requirements draft?

Thanks, Adrian.

> Having had a quick chat with a couple of the authors (not all) we are in
> agreement that this draft is to state clearly the requirements of the ASON
> architecture as applicable to GMPLS signaling within the context of the IETF.

Okay.

> The motives are to
> - make those requirements accessible to the IETF community
>    in a form and format with which they are familiar

I would encourage adding "terminology" to the above, if the document
doesn't already do so.

> - provide a basis for determining whether current protocol
>   solutions fully address the requirements.

Okay: so this document is _setting the stage_ for a meaningful discussion
of solutions.  I'll just note that we have a precedent in CCAMP for this:
there were no requirements for OLI until there was (vigorous) debate on
the relative merits of two different solutions.  The emergence of a reqts
doc helped clarify issues.

> The second point is the one that might give rise to debate in the future. That
> is, once the requirements have been exposed in a way we understand, we may
> discover that the existing work is exemplary or we may determine there are holes
> to be plugged.

Sounds fine.

> Views on this are premature until the requirements draft is solid
> (although the prematurity of views will in no way prevent them from being
> expressed).

Too true.

> Kireeti, what are the next steps?

Let's see what the WG says about ASON reqts first.

Kireeti.

Delivery-date: Wed, 14 May 2003 20:34:07 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 15:32:48 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>, "Stephen Trowbridge" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, <[email-masked]>, <[email-masked]>

Thanks Lyndon for asking clarification-

I was trying to say that ASON does not require supporting multiple =
address formats for a E-PC (Protocol Controller) e.g. G7713.1.

Similar to NSAP support of IP, IPv6 supports NSAP.

Can you clarify your take on the requirements discussion? If I read the =
email, the discussion was related to the definition of a control domain =
and support of a non-RSVP domain or legacy (management system). The =
answer for supporting a non-RSVP domain was the need for an interworking =
function (which was considered out of scope). This is analogous to ITU's =
work, both for G7713.1 (PNNI) and G7713.2, the interworking functions =
are considered out of scope. And support of legacy is via SPC (same as =
G7713.1) and it is included. Were any other requirements identified as =
missing?

Deborah

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]
Sent: Wednesday, May 14, 2003 1:09 PM
To: Brungard, Deborah A, ALABS; Stephen Trowbridge
Cc: Wijnen, Bert (Bert); [email-masked]; [email-masked]
Subject: RE: ASON reqts

Hi Deborah,

Just wanted to clear up a point - 7713.1 supports NSAP format
addresses, however there are methods of mapping IPv4 and IPv6
addresses into the NSAP format, so there is no fundamental
limitation in this (also, I believe the ATMF has or is working
on a document on address format mapping).

I think the discussion seems to be pointing out that some
ASON requirements just don't fall within the scope of IETF
work, so it may not be appropriate to address them in IETF
(hmm, sounds like how 3474 was created...)

Cheers,

Lyndon

Delivery-date: Wed, 14 May 2003 19:52:41 +0000
Date: Wed, 14 May 2003 14:40:15 -0500
From: Ben Mack-Crane <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: ASON reqts

CCAMPers,

Having reviewed the proposed requirements draft, and some of the ensuing 
e-mail discussion, I would say that

"I have read this document, and it isn't ready to be a CCAMP doc"

I am principally concerned that routing requirements are not included. 
While draft's title is encompassing "GMPLS Usage and Extensions for 
ASON," the abstract limits this to signaling only.  I do not think 
addressing signaling in a vacuum is a good idea, as there are 
requirements in the routing area that have impact on the signaling 
protocols (in so far as they carry routing information) and other 
general requirements that impact both signaling and routing (such as not 
exposing network topology information across untrusted interfaces).

I am concerned that if adopted as a WG doc in this state, this would be 
considered agreement to the limited scope of the draft.

Regards,
Ben

Kireeti Kompella wrote:
> Hi All,
> 
> On Fri, 2 May 2003, Kireeti Kompella wrote:
> 
> 
>>To take things one at a time, it would be very useful to read and comment
>>on the ASON reqts draft, as this was deemed tremendously important, and
>>a rich source of misunderstanding and cross-talk; and coming to a common
>>understanding over this should help get the IETF and the ITU working
>>together.
> 
> 
> I haven't seen many comments, so the assumption is either that no
> one cares, or that folks have read it and have no issues.
> 
> I'd like to get a reading on whether this doc is ready to be a
> CCAMP WG document.  Please respond (preferably publicly) with one of:
>  - "I have read this document and it is ready to be a CCAMP WG doc" OR
>  - "I have read this document, and it isn't ready to be a CCAMP doc".
> 
> Note that if there aren't enough responses, the default assumption is
> that the document is either not of interest or not ready, and in
> either case will not become a CCAMP WG doc.  Note too that this doc
> is an attempt to bridge some gaps between the IETF and the ITU-T,
> and as such is fairly important.  It would be useful to give an
> update on its status at the interim T1X1 meeting in June.
> 
> Please get your responses in by COB Friday May 16th.
> 
> Thanks,
> Kireeti.
> 

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

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

Delivery-date: Wed, 14 May 2003 18:56:07 +0000
Date: Wed, 14 May 2003 11:54:53 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Stephen Trowbridge <[email-masked]>
cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "" <[email-masked]>
Subject: Re: ASON reqts

Hi Steve,

On Wed, 14 May 2003, Stephen Trowbridge wrote:

> I have a growing sense of unease that we could be headed
> for trouble here because, among those who seem to support that
> this becomes a WG document, there seem to be (among those who
> indicate a reason) a wide variety of different motivations about
> WHY this should be a WG document and what the posters expect
> will happen as a result.

As I just said in a private email exchange, I've given up trying to
infer motivations, intentions and purposes -- I don't have a degree
in political science or in psychology (and I'm beginning to wish I
had one in psychiatry).  Fortunately, that's not my job as a chair;
my job as a chair is to progress technically accurate, relevant
documents that fall within the CCAMP charter.

> Perhaps more helpful than just a Yes/No preference, it would
> be more helpful to characterize the reasons so that, if this
> becomes a WG document, we know we have a consensus on why we
> are doing this and what we are trying to accomplish.

Well, thanks, Steve for telling me how to do my job.  The IETF
progresses (or not) documents based on rough consensus -- raising
hands, hums, and their electronic equivalents.  Any discussion that
accompanies the call for consensus is very useful, but its purpose
is (or should be) to persuade others to your point of view.

> I think I have detected the following motivations from different
> posts in the thread:

You may have captured the motivations.  It makes interesting reading,
in any case.  You may then persuade people to decide which of positions
A-Z they subscribe to -- but ultimately, whether on the basis of
motivations or technical content or political leaning, each one needs
to state their preference on progressing, holding back or dumping the
requirements document.

As a WG chair, I sincerely hope that the basis will be technical
merit and relevance.  That makes the chairs' job easier.

Perhaps it would be useful to emphasize the following:
 o This is not a call to make the doc an RFC, it's to make the doc a
   CCAMP WG document.  The document doesn't have to be perfect, it
   doesn't have to satisfy rfc2223bis, references are minor details.
 o Making a doc a WG doc does not automatically mean it gets published.
   It is a statement that the WG thinks that this work is useful, and
   should be pursued.  It does give the document a certain legitimacy
   both within the IETF and with other SDOs, which means that the
   decision to make a doc a WG doc is not to be taken lightly; on the
   other hand, there are cases where a WG doc has either been altered
   drastically, or abandoned as a result of WG deliberations.
 o Making any one document a WG doc has no direct effect on another doc.
   So, for those who think that making the reqts doc a WG doc means that
   a solutions doc (such as draft-dimitri-ccamp-gmpls-rsvp-te-ason) also
   becomes a WG doc are mistaken.

Finally, the above is not to be taken as a deterrent to discussion.
I encourage discussion, whether it be on technical content, motivations,
or future activity.  All I ask is that the discussion be conducted
professionally, and the material be relevant to the CCAMP list.  I
thank you all that this discussion has so far been all of the above.

Kireeti.

Delivery-date: Wed, 14 May 2003 17:40:16 +0000
Date: Wed, 14 May 2003 11:38:33 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Adrian Farrel <[email-masked]>
CC: [email-masked], "'Kireeti Kompella'" <[email-masked]>
Subject: Re: ASON reqts - Moving on?

Adrian,

Adrian Farrel wrote:
snip
> The motives are to
> - make those requirements accessible to the IETF community
>    in a form and format with which they are familiar
Two issues here: "accessibility" and "form and format"
In terms of accessibility, the "original" ASON requirements
(G.8080, G.7713, etc.) have all been sent via liaison from
ITU-T to IETF. Those that haven't been translated to html
or pdf by the secretariat for direct access from the IETF site
are available from the SG15 FTP site.

In terms of form and format, give me a break. There have been
multiple forms/formats/sets of vocabulary involved with
virtually every corner of the telecom field that I have
been involved with over the last 25 years. But many of the
smartest people I know are also in this field, and as long
as people are willing to work together and try to understand,
there has never been a problem. For example, SONET and SDH
have different names for almost everything, but by now
anyone involved with these technologies is bi-lingual and
can understand a concept perfectly well no matter which
terminology it is described in. SONET people even understand
it when Maarten Vissers describes equipment functions using
triangles and tapezoids. So I don't think there is a pressing
need to "translate" these specifications to ASCII/IETF-ese.

Doing translations creates its own set of problems. First of
all, one has to worry about the accuracy of the translation.
Second, it creates a maintenance problem: once something is
documented in two places, which is the controlling document?
When a correction or update needs to occur, it now needs to
happen in both places.

Of course, if people aren't willing to work together and try
to understand, no amount of spoon feeding, ASCII translation,
etc. will help this.

> - provide a basis for determining whether current protocol
>   solutions fully address the requirements.
So we started with requirements documents (not all IETF) and
produced protocol solutions, and now we should decide whether
the protocol solutions met the requirements by producing a
translation of the requirements? It seems like it would be
better to do this kind of validation against the ORIGINAL
requirements than against a translation: then you don't need
to decide whether an apparent mismatch is an unmet requirement
or a bad translation. If a problem is found, it can be fixed
at its source instead of in some downstream document.

To assess the motivation you expressed for embarking on this
effort, it kind of sounds like "2 (keep the protocol the same
and document everythinig in IETF) unless the editors decide
to switch to 3, 4, or 5 later*!?)

Regards,
Steve

Delivery-date: Wed, 14 May 2003 17:26:33 +0000
Date: Wed, 14 May 2003 13:18:58 -0400
From: Sudheer Dharanikota <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: ASON reqts

"I have read this document and it is ready to be a CCAMP WG doc"

Regards,

sudheer

Kireeti Kompella wrote:

> Hi All,
>
> On Fri, 2 May 2003, Kireeti Kompella wrote:
>
> > To take things one at a time, it would be very useful to read and comment
> > on the ASON reqts draft, as this was deemed tremendously important, and
> > a rich source of misunderstanding and cross-talk; and coming to a common
> > understanding over this should help get the IETF and the ITU working
> > together.
>
> I haven't seen many comments, so the assumption is either that no
> one cares, or that folks have read it and have no issues.
>
> I'd like to get a reading on whether this doc is ready to be a
> CCAMP WG document.  Please respond (preferably publicly) with one of:
>  - "I have read this document and it is ready to be a CCAMP WG doc" OR
>  - "I have read this document, and it isn't ready to be a CCAMP doc".
>
> Note that if there aren't enough responses, the default assumption is
> that the document is either not of interest or not ready, and in
> either case will not become a CCAMP WG doc.  Note too that this doc
> is an attempt to bridge some gaps between the IETF and the ITU-T,
> and as such is fairly important.  It would be useful to give an
> update on its status at the interim T1X1 meeting in June.
>
> Please get your responses in by COB Friday May 16th.
>
> Thanks,
> Kireeti.

Delivery-date: Wed, 14 May 2003 17:06:48 +0000
From: "Ong, Lyndon" <[email-masked]>
To: "'Brungard, Deborah A, ALABS'" <[email-masked]>, Stephen Trowbridge <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 10:09:26 -0700

Hi Deborah,

Just wanted to clear up a point - 7713.1 supports NSAP format
addresses, however there are methods of mapping IPv4 and IPv6
addresses into the NSAP format, so there is no fundamental
limitation in this (also, I believe the ATMF has or is working
on a document on address format mapping).

I think the discussion seems to be pointing out that some
ASON requirements just don't fall within the scope of IETF
work, so it may not be appropriate to address them in IETF
(hmm, sounds like how 3474 was created...)

Cheers,

Lyndon

Envelope-to: [email-masked]
Delivery-date: Wed, 14 May 2003 16:54:17 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: ASON reqts - Moving on?
Date: Wed, 14 May 2003 12:53:13 -0400

Can we back off a bit and just look at the ASON requirements draft?

Having had a quick chat with a couple of the authors (not all) we are in
agreement that this draft is to state clearly the requirements of the ASON
architecture as applicable to GMPLS signaling within the context of the IETF.

The motives are to
- make those requirements accessible to the IETF community
   in a form and format with which they are familiar
- provide a basis for determining whether current protocol
  solutions fully address the requirements.

We believe the former is a necessity notwithstanding the prior work. At the very
least it rehashes old ground with which the informed reader should already be
familiar. At best it puts added clarity and context on top of the existing work.

The second point is the one that might give rise to debate in the future. That
is, once the requirements have been exposed in a way we understand, we may
discover that the existing work is exemplary or we may determine there are holes
to be plugged. Views on this are premature until the requirements draft is solid
(although the prematurity of views will in no way prevent them from being
expressed).

As has been pointed out by several people, there are areas in the current draft
which need clarification and extension. There have also been some topics raised
which the authors need to examine - prinicpally whether certain requirements
*are* requirements and whether they have been omitted.  This is good, and why
the mailing list exists.

My personal view is
- the authors need to do more work on the draft
- it would help widen the discussion of the draft outside the IETF if it were a
WG draft
- the material is relevant to the WG
- it may be a repeat of work that is already done, but we can't tell until we've
done it.

Kireeti, what are the next steps?

Adrian

Delivery-date: Wed, 14 May 2003 16:00:26 +0000
Date: Wed, 14 May 2003 09:59:21 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

John,
I still think it is better to argue it out now and reach agreement
on what problem we are trying to solve.

If we accept this as a WG draft without doing this, we seem to be
accepting that we do have SOME problem to solve, and then arguing
later on what it was.
Regards,
Steve

John Drake wrote:
> 
> Regardless of what we do now, I'm sure there will be lots of arguments
> later.
> 
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Wednesday, May 14, 2003 8:24 AM
> > To: John Drake
> > Cc: Ash, Gerald R (Jerry), ALABS; Wijnen, Bert (Bert);
> > [email-masked]
> > Subject: Re: ASON reqts
> >
> >
> > John,
> > First, I think there is a big difference between 3 and 4 and
> > what should
> > be done about it:
> > For 3, G.7713.2 is OK, RFC 3474 is broken, and we just need
> > to fix RFC 3474
> >   by superceding with something aligned with G.7713.2.
> > For 4, G.7713.2 is broken (as is, by extension RFC 3474).
> > Here we need to
> >   coordinate with ITU-T to fix both. It seems like a bad
> > strategy to try
> >   to have IETF fly solo and develop a "better" solution to
> > ITU-T requirements
> >   than what ITU-T did.
> 
> JD:  Given that G.7713.2 == RFC3474, what does it matter?  If it
> is broken in one venue, there's a good chance it's broken in the
> other.
> 
> >
> > Back to why it is important to decide where we are going with
> > this first:
> > I think that some who support this as a WG document are doing
> > so because
> > they want to see the base protocol and the ASON extensions
> > documented in
> > a common place, and NOT because they were intending to open
> > the door to
> > changing the protocol now.
> 
> JD:  I don't buy this at all.  Until we get agreement on requirements
> how do we know whether a given document supports those requirements?
> 
> > If we can get agreement over why
> > we are doing
> > this now, I think we can avoid a lot of arguments later.
> 
> JD:  I completely disagree.  Regardless of what we do now, there will
> be plenty of arguments later.
> 
> > Regards,
> > Steve
> >
> > John Drake wrote:
> > >
> > > Stephen,
> > >
> > > If this I-D is progressed, it will be used as the basis for
> > deciding between
> > > 2, 3, and 4, although I don't see any practical difference
> > between 3 and 4.
> > > I haven't seen 5 expressed by anyone (at least in the
> > context of this I-D).
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > > Sent: Wednesday, May 14, 2003 6:49 AM
> > > > To: Ash, Gerald R (Jerry), ALABS
> > > > Cc: Wijnen, Bert (Bert); [email-masked]
> > > > Subject: Re: ASON reqts
> > > >
> > > >
> > > > All,
> > > > I have a growing sense of unease that we could be headed
> > > > for trouble here because, among those who seem to support that
> > > > this becomes a WG document, there seem to be (among those who
> > > > indicate a reason) a wide variety of different motivations about
> > > > WHY this should be a WG document and what the posters expect
> > > > will happen as a result.
> > > >
> > > > Perhaps more helpful than just a Yes/No preference, it would
> > > > be more helpful to characterize the reasons so that, if this
> > > > becomes a WG document, we know we have a consensus on why we
> > > > are doing this and what we are trying to accomplish.
> > > >
> > > > I think I have detected the following motivations from different
> > > > posts in the thread:
> > > >
> > > > 1. Those who don't want this to be a WG document (we are done with
> > > >    this version of the specifications, lets get some experience
> > > >    with them before considering any further change or evolution).
> > > >
> > > > 2. Those who think this should be a WG document so that ASON
> > > > extensions
> > > >    currently standardized in ITU-T will get standards
> > track status in
> > > >    IETF (no intent to change the protocol, but document
> > the superset
> > > >    in one place so that we don't get so many GMPLS implementations
> > > >    that don't support the ASON extensions).
> > > >
> > > > 3. Those who think there is nothing wrong with the ITU-T
> > extensions to
> > > >    meet the ASON requirements, but believe that RFC 3474
> > > > didn't translate
> > > >    G.7713.2 properly and this draft is a first step to fixing
> > > > RFC 3474.
> > > >
> > > > 4. Those who think that even the ITU-T extensions don't
> > meet the ASON
> > > >    requirements, so IETF should now take it over and do it
> > > > better starting
> > > >    with this draft.
> > > >
> > > > 5. Those who think that ITU-T didn't get the requirements
> > right, so we
> > > >    need to look at everything from scratch.
> > > >
> > > > There may be other motivations which I haven't detected or
> > > > characterized,
> > > > but these seem to be the main camps.
> > > >
> > > > So I don't think it is enough to just count how many say
> > it should be
> > > > a WG document. I think that those in camp #2 above might be
> > > > pretty upset
> > > > if the result of making this a WG document turns out to be a
> > > > rototilling
> > > > of the protocol driven by those in camps #4 and #5. We will
> > > > have a much
> > > > smoother time if we agree on why we are doing this and what
> > > > we are trying
> > > > to accomplish as a result.
> > > >
> > > > Once we settle on which of 1-5 we are trying to accomplish:
> > > > - If it is 1, 2, or 3, we can handle in IETF.
> > > > - If it is 4 or 5, we had better send a liaison to ITU-T.
> > > >
> > > > Please let me know if I missed any proposed purposes for
> > this draft.
> > > > Otherwise, for those of you who support this being a WG
> > draft, I think
> > > > it might be helpful if you would indicate which of (2-5)
> > characterizes
> > > > why you support this so we can make sure we are on the
> > same page as to
> > > > what we are trying to accomplish.
> > > >
> > > > Regards,
> > > > Steve
> > > >
> >

Delivery-date: Wed, 14 May 2003 15:49:44 +0000
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 08:48:57 -0700

Regardless of what we do now, I'm sure there will be lots of arguments
later.  

> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Wednesday, May 14, 2003 8:24 AM
> To: John Drake
> Cc: Ash, Gerald R (Jerry), ALABS; Wijnen, Bert (Bert);
> [email-masked]
> Subject: Re: ASON reqts
> 
> 
> John,
> First, I think there is a big difference between 3 and 4 and 
> what should
> be done about it:
> For 3, G.7713.2 is OK, RFC 3474 is broken, and we just need 
> to fix RFC 3474
>   by superceding with something aligned with G.7713.2.
> For 4, G.7713.2 is broken (as is, by extension RFC 3474). 
> Here we need to
>   coordinate with ITU-T to fix both. It seems like a bad 
> strategy to try
>   to have IETF fly solo and develop a "better" solution to 
> ITU-T requirements
>   than what ITU-T did.

JD:  Given that G.7713.2 == RFC3474, what does it matter?  If it
is broken in one venue, there's a good chance it's broken in the
other.

> 
> Back to why it is important to decide where we are going with 
> this first:
> I think that some who support this as a WG document are doing 
> so because
> they want to see the base protocol and the ASON extensions 
> documented in
> a common place, and NOT because they were intending to open 
> the door to
> changing the protocol now. 

JD:  I don't buy this at all.  Until we get agreement on requirements
how do we know whether a given document supports those requirements?

> If we can get agreement over why 
> we are doing
> this now, I think we can avoid a lot of arguments later.

JD:  I completely disagree.  Regardless of what we do now, there will
be plenty of arguments later.

> Regards,
> Steve
> 
> John Drake wrote:
> > 
> > Stephen,
> > 
> > If this I-D is progressed, it will be used as the basis for 
> deciding between
> > 2, 3, and 4, although I don't see any practical difference 
> between 3 and 4.
> > I haven't seen 5 expressed by anyone (at least in the 
> context of this I-D).
> > 
> > Thanks,
> > 
> > John
> > 
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > Sent: Wednesday, May 14, 2003 6:49 AM
> > > To: Ash, Gerald R (Jerry), ALABS
> > > Cc: Wijnen, Bert (Bert); [email-masked]
> > > Subject: Re: ASON reqts
> > >
> > >
> > > All,
> > > I have a growing sense of unease that we could be headed
> > > for trouble here because, among those who seem to support that
> > > this becomes a WG document, there seem to be (among those who
> > > indicate a reason) a wide variety of different motivations about
> > > WHY this should be a WG document and what the posters expect
> > > will happen as a result.
> > >
> > > Perhaps more helpful than just a Yes/No preference, it would
> > > be more helpful to characterize the reasons so that, if this
> > > becomes a WG document, we know we have a consensus on why we
> > > are doing this and what we are trying to accomplish.
> > >
> > > I think I have detected the following motivations from different
> > > posts in the thread:
> > >
> > > 1. Those who don't want this to be a WG document (we are done with
> > >    this version of the specifications, lets get some experience
> > >    with them before considering any further change or evolution).
> > >
> > > 2. Those who think this should be a WG document so that ASON
> > > extensions
> > >    currently standardized in ITU-T will get standards 
> track status in
> > >    IETF (no intent to change the protocol, but document 
> the superset
> > >    in one place so that we don't get so many GMPLS implementations
> > >    that don't support the ASON extensions).
> > >
> > > 3. Those who think there is nothing wrong with the ITU-T 
> extensions to
> > >    meet the ASON requirements, but believe that RFC 3474
> > > didn't translate
> > >    G.7713.2 properly and this draft is a first step to fixing
> > > RFC 3474.
> > >
> > > 4. Those who think that even the ITU-T extensions don't 
> meet the ASON
> > >    requirements, so IETF should now take it over and do it
> > > better starting
> > >    with this draft.
> > >
> > > 5. Those who think that ITU-T didn't get the requirements 
> right, so we
> > >    need to look at everything from scratch.
> > >
> > > There may be other motivations which I haven't detected or
> > > characterized,
> > > but these seem to be the main camps.
> > >
> > > So I don't think it is enough to just count how many say 
> it should be
> > > a WG document. I think that those in camp #2 above might be
> > > pretty upset
> > > if the result of making this a WG document turns out to be a
> > > rototilling
> > > of the protocol driven by those in camps #4 and #5. We will
> > > have a much
> > > smoother time if we agree on why we are doing this and what
> > > we are trying
> > > to accomplish as a result.
> > >
> > > Once we settle on which of 1-5 we are trying to accomplish:
> > > - If it is 1, 2, or 3, we can handle in IETF.
> > > - If it is 4 or 5, we had better send a liaison to ITU-T.
> > >
> > > Please let me know if I missed any proposed purposes for 
> this draft.
> > > Otherwise, for those of you who support this being a WG 
> draft, I think
> > > it might be helpful if you would indicate which of (2-5) 
> characterizes
> > > why you support this so we can make sure we are on the 
> same page as to
> > > what we are trying to accomplish.
> > >
> > > Regards,
> > > Steve
> > >
> 

Delivery-date: Wed, 14 May 2003 15:25:09 +0000
Date: Wed, 14 May 2003 09:24:25 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

John,
First, I think there is a big difference between 3 and 4 and what should
be done about it:
For 3, G.7713.2 is OK, RFC 3474 is broken, and we just need to fix RFC 3474
  by superceding with something aligned with G.7713.2.
For 4, G.7713.2 is broken (as is, by extension RFC 3474). Here we need to
  coordinate with ITU-T to fix both. It seems like a bad strategy to try
  to have IETF fly solo and develop a "better" solution to ITU-T requirements
  than what ITU-T did.

Back to why it is important to decide where we are going with this first:
I think that some who support this as a WG document are doing so because
they want to see the base protocol and the ASON extensions documented in
a common place, and NOT because they were intending to open the door to
changing the protocol now. If we can get agreement over why we are doing
this now, I think we can avoid a lot of arguments later.
Regards,
Steve

John Drake wrote:
> 
> Stephen,
> 
> If this I-D is progressed, it will be used as the basis for deciding between
> 2, 3, and 4, although I don't see any practical difference between 3 and 4.
> I haven't seen 5 expressed by anyone (at least in the context of this I-D).
> 
> Thanks,
> 
> John
> 
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Wednesday, May 14, 2003 6:49 AM
> > To: Ash, Gerald R (Jerry), ALABS
> > Cc: Wijnen, Bert (Bert); [email-masked]
> > Subject: Re: ASON reqts
> >
> >
> > All,
> > I have a growing sense of unease that we could be headed
> > for trouble here because, among those who seem to support that
> > this becomes a WG document, there seem to be (among those who
> > indicate a reason) a wide variety of different motivations about
> > WHY this should be a WG document and what the posters expect
> > will happen as a result.
> >
> > Perhaps more helpful than just a Yes/No preference, it would
> > be more helpful to characterize the reasons so that, if this
> > becomes a WG document, we know we have a consensus on why we
> > are doing this and what we are trying to accomplish.
> >
> > I think I have detected the following motivations from different
> > posts in the thread:
> >
> > 1. Those who don't want this to be a WG document (we are done with
> >    this version of the specifications, lets get some experience
> >    with them before considering any further change or evolution).
> >
> > 2. Those who think this should be a WG document so that ASON
> > extensions
> >    currently standardized in ITU-T will get standards track status in
> >    IETF (no intent to change the protocol, but document the superset
> >    in one place so that we don't get so many GMPLS implementations
> >    that don't support the ASON extensions).
> >
> > 3. Those who think there is nothing wrong with the ITU-T extensions to
> >    meet the ASON requirements, but believe that RFC 3474
> > didn't translate
> >    G.7713.2 properly and this draft is a first step to fixing
> > RFC 3474.
> >
> > 4. Those who think that even the ITU-T extensions don't meet the ASON
> >    requirements, so IETF should now take it over and do it
> > better starting
> >    with this draft.
> >
> > 5. Those who think that ITU-T didn't get the requirements right, so we
> >    need to look at everything from scratch.
> >
> > There may be other motivations which I haven't detected or
> > characterized,
> > but these seem to be the main camps.
> >
> > So I don't think it is enough to just count how many say it should be
> > a WG document. I think that those in camp #2 above might be
> > pretty upset
> > if the result of making this a WG document turns out to be a
> > rototilling
> > of the protocol driven by those in camps #4 and #5. We will
> > have a much
> > smoother time if we agree on why we are doing this and what
> > we are trying
> > to accomplish as a result.
> >
> > Once we settle on which of 1-5 we are trying to accomplish:
> > - If it is 1, 2, or 3, we can handle in IETF.
> > - If it is 4 or 5, we had better send a liaison to ITU-T.
> >
> > Please let me know if I missed any proposed purposes for this draft.
> > Otherwise, for those of you who support this being a WG draft, I think
> > it might be helpful if you would indicate which of (2-5) characterizes
> > why you support this so we can make sure we are on the same page as to
> > what we are trying to accomplish.
> >
> > Regards,
> > Steve
> >

Delivery-date: Wed, 14 May 2003 15:03:11 +0000
Date: Wed, 14 May 2003 11:02:32 -0400
To: Manoj Agiwal <[email-masked]>
From: Baktha Muralidharan <[email-masked]>
Subject: Re: FW: LMP Message ID
Cc: "'Ccamp (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>

At 12:37 AM 5/13/2003 -0500, Manoj Agiwal wrote:
>Hi ,
>       Lmp drafts tells that Message ID should be monotonically increasing .
>
>       Section 7 also tells that "Unacknowledge messages sent with Message_id
>object should be retransmitted until the message is
>       acknowledged or until retry limit is reached."
>
>       Do we have to sent all retransmitted messages with the same Message Id
>as sent previously or it should be in monotonically
>       increasing order.
>
>Regards ,
>Manoj

Hi Manoj,

An unacknowledged message could have been lost; i.e. might not have reached
the neighbor. So, the neighbor has no way of determining if a message is
a re-transmit and will fail [and nack] a message with out-of-order message-id.

So, re-transmit attempts should increase message id.

/Baktha Muralidharan
  Cisco Systems.

Delivery-date: Wed, 14 May 2003 14:51:06 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 09:49:50 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Stephen Trowbridge" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Steve,

Thanks for asking specifically..

RFC3473 is to support multi-layer equipment. IP-subnetworks? Generic =
transport networks using ASON extensions? Using G8080 terminology, =
RFC3473 supports a control domain (multi-(transport)layer /multi-vendor) =
based on GMPLS (i.e. uses IP addressing).

G7713.2 as you are noting (and Jonathan's mail) is using a subset of =
GMPLS signaling. It is not based on GMPLS i.e. it uses a different =
addressing scheme ( based on OIF addresses, not based on IP). G7713.2 =
requires an interworking function plus upgrades to a RFC 3473 domain. =
And as G7713.2 states it "focuses on the UNI and E-NNI.. the I-NNI ..is =
for further study". G7713.2 is not based on any I-NNI.

The rsvp-te-ason draft provides extensions to RFC3473 to support ASON. =
It is analogous to G7713.1 (for non-ITU, G7713.1 is ASON PNNI-based =
E-NNI/I-NNI). No one questioned the need for G7713.1 (or that it only =
supports NSAP addresses for E-NNI). And no one questioned a potential =
conflict of G7713.1 and G7713.2. And we (ITU) used G7713.1 and our =
relationship with the ATM Forum as an example of our expectations for =
working with IETF. It is really confusing to have ITU participants now =
questioning the need for IETF's work on a "G7713.1".

If you think G7713.2 meets the requirements for extending RFC3473, =
contribute it. The problem statement is "use of GMPLS (RFC3471) to =
provide call and connection management". The problem statement is =
aligned with G7713.1 on control domain definition, addressing, and =
functionality.

Deborah

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Wednesday, May 14, 2003 10:04 AM
To: Brungard, Deborah A, ALABS
Cc: Wijnen, Bert (Bert); [email-masked]; [email-masked]
Subject: Re: ASON reqts

Deborah,
I am a little confused here:
We have two versions of the protocol:
- Base GMPLS, developed to the requirements for controlling TDM, WDM =
layers
  that are used below the packet layer(s) in IP networks.
- GMPLS plus ASON extensions, developed to also address requirements of
  general (not necessarily IP) transport networks.
What I think you are suggesting is to address how these versions of the
protocol interwork. The primary case that I can envision is the =
following:
- IP subnetworks using base GMPLS, interconnected across generic =
transport
  networks using ASON extensions. With the IP subnetworks on the edge =
and
  the generic transport in the middle, I think there is no problem with
  the current protocols.
But what you seem to suggest is the following:
- Subnetworks using ASON extensions interconnected across a core using
  only base GMPLS.
This case seems a little farfetched - that you would interconnect =
subnetworks
that support a combination of circuit and packet traffic across a base =
GMPLS
only (non-circuit traffic aware?) core. Lets make sure this is a real =
network
configuration before we undertake an effort to change the protocols to =
support
it.
Regards,
Steve

"Brungard, Deborah A, ALABS" wrote:
>=20
> Hi Bert,
>=20
> Can you provide clarification on your email?
>=20
> - the January ASON email exchange and the previous ITU-T liaisons =
clearly identified RFC-3471 and RFC-3473 lacked ASON support. The two =
ason drafts submitted are to initiate this work.
> - majority of the email supports the reqs draft becoming a WG =
document. And hopefully, those concerned will also support as WG =
document based on the understanding a WG doc is a work in progress as =
posted by one email:
> > There are a few issues that I don't quite understand and/or need
> > clarification on, but the current vote is WG acceptance, not =
last-call.
> > I have no issues with it that would keep it out from the WG.
>=20
> Most of the email is on clarifying G7713.2 and the rsvp-te-ason draft. =
This draft addresses a totally different application/solution than =
G7713.2. The rsvp-te-ason draft covers the necessary extensions to =
RFC-3473 to support ASON for a GMPLS network. The difference of this =
draft and G7713.2 is that this draft is backward and forward compatible =
for GMPLS networks; i.e. transit nodes (ITU term: Internal Protocol =
Controller (I-PC)) do not need to be updated.  G7713.2 is an E-NNI which =
is using GMPLS but it is not based on GMPLS e.g. G7713.2 does not =
provide call and connection functional separation because it was not =
based on use with an RFC-3473 network. Eve's mail clarifies this =
regarding the domain definitions. If the draft is confusing in this =
regard, we can work on the wording.
>=20
> The draft is on extending RFC-3473 to support ASON. If IETF does not =
extend RFC-3473, then GMPLS will not support ASON. This work is totally =
independent of the existence of G7713.2. As we discuss the draft, we can =
clarify if this is confusing.
>=20
> Deborah
>=20
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 10:38 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: ASON reqts
>=20
> AD-hat on.
>=20
> Bart writes:
> >
> >
> > Stephen,
> >
> > I think the point was rather to go back to
> > just a single GMPLS spec instead of two (let alone three) =
variants...
> >
> If that is the case, and if we want to do that in IETF CCAMP
> (not sure it is part of the current CCAMP charter),
> then it seems to me that we (CCAMP) should excercise these steps:
>=20
> - send some liason to ITU-T SG 15 to explain that we found that
>   there seems to be a GMPLS (for IETF) and a GMPLS-ASON standard
> - that we think that this is NOT goodness, and that we regret that
>   we did send the ASON people away a few years back and did not
>   closely follow their work in ITU
> - that we now believe that we should have worked better together,
> - that we would like to explore ways to try and mrege the two
>   solution back into one common solution
>=20
> And then await the response and hope ITU will agree and then see
> how the work can be organized.
>=20
> >
> > Bart
> >
> Bert

Delivery-date: Wed, 14 May 2003 14:15:29 +0000
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>,  "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 07:15:02 -0700

Stephen,

If this I-D is progressed, it will be used as the basis for deciding between
2, 3, and 4, although I don't see any practical difference between 3 and 4.
I haven't seen 5 expressed by anyone (at least in the context of this I-D).

Thanks,

John

> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Wednesday, May 14, 2003 6:49 AM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: Wijnen, Bert (Bert); [email-masked]
> Subject: Re: ASON reqts
> 
> 
> All,
> I have a growing sense of unease that we could be headed
> for trouble here because, among those who seem to support that
> this becomes a WG document, there seem to be (among those who
> indicate a reason) a wide variety of different motivations about
> WHY this should be a WG document and what the posters expect
> will happen as a result.
> 
> Perhaps more helpful than just a Yes/No preference, it would
> be more helpful to characterize the reasons so that, if this
> becomes a WG document, we know we have a consensus on why we
> are doing this and what we are trying to accomplish.
> 
> I think I have detected the following motivations from different
> posts in the thread:
> 
> 1. Those who don't want this to be a WG document (we are done with
>    this version of the specifications, lets get some experience
>    with them before considering any further change or evolution).
> 
> 2. Those who think this should be a WG document so that ASON 
> extensions
>    currently standardized in ITU-T will get standards track status in
>    IETF (no intent to change the protocol, but document the superset
>    in one place so that we don't get so many GMPLS implementations
>    that don't support the ASON extensions).
> 
> 3. Those who think there is nothing wrong with the ITU-T extensions to
>    meet the ASON requirements, but believe that RFC 3474 
> didn't translate
>    G.7713.2 properly and this draft is a first step to fixing 
> RFC 3474.
> 
> 4. Those who think that even the ITU-T extensions don't meet the ASON
>    requirements, so IETF should now take it over and do it 
> better starting
>    with this draft.
> 
> 5. Those who think that ITU-T didn't get the requirements right, so we
>    need to look at everything from scratch.
> 
> There may be other motivations which I haven't detected or 
> characterized,
> but these seem to be the main camps.
> 
> So I don't think it is enough to just count how many say it should be
> a WG document. I think that those in camp #2 above might be 
> pretty upset
> if the result of making this a WG document turns out to be a 
> rototilling
> of the protocol driven by those in camps #4 and #5. We will 
> have a much
> smoother time if we agree on why we are doing this and what 
> we are trying
> to accomplish as a result.
> 
> Once we settle on which of 1-5 we are trying to accomplish:
> - If it is 1, 2, or 3, we can handle in IETF.
> - If it is 4 or 5, we had better send a liaison to ITU-T.
> 
> Please let me know if I missed any proposed purposes for this draft.
> Otherwise, for those of you who support this being a WG draft, I think
> it might be helpful if you would indicate which of (2-5) characterizes
> why you support this so we can make sure we are on the same page as to
> what we are trying to accomplish.
> 
> Regards,
> Steve
> 

Delivery-date: Wed, 14 May 2003 14:14:09 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 09:13:14 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Stephen Trowbridge" <[email-masked]>, "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, <[email-masked]>

Steve,

Your mail is recommending "we break out a couple dozen eggs and continue =
to throw them between the ITU and the IETF" as one email suggested;-)

We are discussing specific comments on the draft which are serious =
enough to prevent it from being a WG document. We are not discussing =
personal/company motivations.

And we are discussing the reqs draft, not the rsvp draft, and not =
G7713.2.

The count is going. If you have specific comments on the problem =
statement, please provide. Personal motivations and egg throwing are =
off-line discussion.

Deborah

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Wednesday, May 14, 2003 9:49 AM
To: Ash, Gerald R (Jerry), ALABS
Cc: Wijnen, Bert (Bert); [email-masked]
Subject: Re: ASON reqts

All,
I have a growing sense of unease that we could be headed
for trouble here because, among those who seem to support that
this becomes a WG document, there seem to be (among those who
indicate a reason) a wide variety of different motivations about
WHY this should be a WG document and what the posters expect
will happen as a result.

Perhaps more helpful than just a Yes/No preference, it would
be more helpful to characterize the reasons so that, if this
becomes a WG document, we know we have a consensus on why we
are doing this and what we are trying to accomplish.

I think I have detected the following motivations from different
posts in the thread:

1. Those who don't want this to be a WG document (we are done with
   this version of the specifications, lets get some experience
   with them before considering any further change or evolution).

2. Those who think this should be a WG document so that ASON extensions
   currently standardized in ITU-T will get standards track status in
   IETF (no intent to change the protocol, but document the superset
   in one place so that we don't get so many GMPLS implementations
   that don't support the ASON extensions).

3. Those who think there is nothing wrong with the ITU-T extensions to
   meet the ASON requirements, but believe that RFC 3474 didn't =
translate
   G.7713.2 properly and this draft is a first step to fixing RFC 3474.

4. Those who think that even the ITU-T extensions don't meet the ASON
   requirements, so IETF should now take it over and do it better =
starting
   with this draft.

5. Those who think that ITU-T didn't get the requirements right, so we
   need to look at everything from scratch.

There may be other motivations which I haven't detected or =
characterized,
but these seem to be the main camps.

So I don't think it is enough to just count how many say it should be
a WG document. I think that those in camp #2 above might be pretty upset
if the result of making this a WG document turns out to be a rototilling
of the protocol driven by those in camps #4 and #5. We will have a much
smoother time if we agree on why we are doing this and what we are =
trying
to accomplish as a result.

Once we settle on which of 1-5 we are trying to accomplish:
- If it is 1, 2, or 3, we can handle in IETF.
- If it is 4 or 5, we had better send a liaison to ITU-T.

Please let me know if I missed any proposed purposes for this draft.
Otherwise, for those of you who support this being a WG draft, I think
it might be helpful if you would indicate which of (2-5) characterizes
why you support this so we can make sure we are on the same page as to
what we are trying to accomplish.

Regards,
Steve

Delivery-date: Wed, 14 May 2003 14:06:14 +0000
From: John Drake <[email-masked]>
To: "'Varma, Eve L (Eve)'" <[email-masked]>, "'Ong, Lyndon'" <[email-masked]>, 'Adrian Farrel' <[email-masked]>, Jonathan Sadler <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 07:03:36 -0700

Eve,

I read Steve's e-mail very carefully, but I didn't see 'domain' mentioned
once.

Thanks,

John
> -----Original Message-----
> From: Varma, Eve L (Eve) [mailto:[email-masked]]
> Sent: Wednesday, May 14, 2003 6:59 AM
> To: John Drake; Varma, Eve L (Eve); 'Ong, Lyndon'; 'Adrian Farrel';
> Jonathan Sadler
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Please see Steve's email.
> 
> Eve
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Wednesday, May 14, 2003 9:56 AM
> To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan
> Sadler
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Eve,
> 
> I am having trouble parsing your e-mail.
> 
> I thought my previous e-mail was stating what was, to use
> Yakov's phrase, "obvious to the informed reader".
> 
> Thanks,
> 
> John
> 
> > -----Original Message-----
> > From: Varma, Eve L (Eve) [mailto:[email-masked]]
> > Sent: Wednesday, May 14, 2003 6:47 AM
> > To: John Drake; Varma, Eve L (Eve); 'Ong, Lyndon'; 'Adrian Farrel';
> > Jonathan Sadler
> > Cc: [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > Hi,
> > 
> > Then the purpose of the reqts. draft is not explaining ITU-T 
> > requirements for
> > ASON in an IETF friendly way.
> > 
> > Eve
> > 
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Wednesday, May 14, 2003 9:42 AM
> > To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan
> > Sadler
> > Cc: [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > Eve,
> > 
> > Let me try again.  We are talking about the support of ASON in GMPLS
> > networks, and
> > we are trying to identify the ASON requirements on GMPLS signalling
> > (RSVP-TE).  By
> > definition, the E-NNI/I-NNI in a GMPLS network will be 
> > RSVP-TE (with IP
> > addressing).
> > If the signalling protocol within a domain is also RSVP-TE 
> > then the only
> > thing a
> > domain boundary node will do is modify the RSVP signalling 
> > messages subject
> > to local
> > policy.
> > 
> > If the signalling protocol within a domain is not RSVP-TE, 
> > then a domain
> > boundary
> > node for such a domain will have to build an interworking 
> > function between
> > its
> > signalling protocol and RSVP-TE.  This is not within the 
> > scope of this work.
> > 
> > Thanks,
> > 
> > John
> > 
> > 
> > > -----Original Message-----
> > > From: Varma, Eve L (Eve) [mailto:[email-masked]]
> > > Sent: Wednesday, May 14, 2003 5:27 AM
> > > To: John Drake; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
> > > Cc: [email-masked]
> > > Subject: RE: ASON reqts
> > > 
> > > 
> > > Hi,
> > > 
> > > I strongly disagree.  The concept of control domains is 
> one of the 
> > > key elements of G.8080 Am. 1, and support for such is part of the
> > > requirements.  This makes no statement re proprietary protocols.
> > > 
> > > Eve
> > > 
> > > -----Original Message-----
> > > From: John Drake [mailto:[email-masked]]
> > > Sent: Tuesday, May 13, 2003 5:36 PM
> > > To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
> > > Cc: [email-masked]
> > > Subject: RE: ASON reqts
> > > 
> > > 
> > > Lyndon,
> > > 
> > > I think it is out of scope.  The only requirement is that a 
> > > group of one or
> > > more nodes running a proprietary control plane (e.g., OSRP) 
> > > must appear to
> > > be one or more GMPLS nodes, and this is a requirement on 
> the vendor
> > > implementing the proprietary control plane.
> > > 
> > > Thanks,
> > > 
> > > John 
> > > 
> > > > -----Original Message-----
> > > > From: Ong, Lyndon [mailto:[email-masked]]
> > > > Sent: Tuesday, May 13, 2003 2:03 PM
> > > > To: 'Adrian Farrel'; Jonathan Sadler
> > > > Cc: [email-masked]; Ong, Lyndon
> > > > Subject: RE: ASON reqts
> > > > 
> > > > 
> > > > Hi Folks,
> > > > 
> > > > I think one aspect that may not come out clearly in the draft
> > > > is that ASON defines a concept of "control domains" (which is
> > > > included in the terminology section of the draft) and in the
> > > > amendment goes on to say that the structure and protocols used
> > > > in each domain may be different (e.g., centralized control in
> > > > one domain and distributed in another, RSVP in one and non-RSVP
> > > > in another).
> > > > 
> > > > I suggested that this be added to the draft, but we did not
> > > > get agreement on this before we decided to send it out, perhaps
> > > > because it was considered to be out of scope (?).
> > > > 
> > > > Cheers,
> > > > 
> > > > Lyndon
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > 
> 

Delivery-date: Wed, 14 May 2003 14:05:40 +0000
Date: Wed, 14 May 2003 08:03:33 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Brungard, Deborah A, ALABS" <[email-masked]>
CC: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: ASON reqts

Deborah,
I am a little confused here:
We have two versions of the protocol:
- Base GMPLS, developed to the requirements for controlling TDM, WDM layers
  that are used below the packet layer(s) in IP networks.
- GMPLS plus ASON extensions, developed to also address requirements of
  general (not necessarily IP) transport networks.
What I think you are suggesting is to address how these versions of the
protocol interwork. The primary case that I can envision is the following:
- IP subnetworks using base GMPLS, interconnected across generic transport
  networks using ASON extensions. With the IP subnetworks on the edge and
  the generic transport in the middle, I think there is no problem with
  the current protocols.
But what you seem to suggest is the following:
- Subnetworks using ASON extensions interconnected across a core using
  only base GMPLS.
This case seems a little farfetched - that you would interconnect subnetworks
that support a combination of circuit and packet traffic across a base GMPLS
only (non-circuit traffic aware?) core. Lets make sure this is a real network
configuration before we undertake an effort to change the protocols to support
it.
Regards,
Steve

"Brungard, Deborah A, ALABS" wrote:
> 
> Hi Bert,
> 
> Can you provide clarification on your email?
> 
> - the January ASON email exchange and the previous ITU-T liaisons clearly identified RFC-3471 and RFC-3473 lacked ASON support. The two ason drafts submitted are to initiate this work.
> - majority of the email supports the reqs draft becoming a WG document. And hopefully, those concerned will also support as WG document based on the understanding a WG doc is a work in progress as posted by one email:
> > There are a few issues that I don't quite understand and/or need
> > clarification on, but the current vote is WG acceptance, not last-call.
> > I have no issues with it that would keep it out from the WG.
> 
> Most of the email is on clarifying G7713.2 and the rsvp-te-ason draft. This draft addresses a totally different application/solution than G7713.2. The rsvp-te-ason draft covers the necessary extensions to RFC-3473 to support ASON for a GMPLS network. The difference of this draft and G7713.2 is that this draft is backward and forward compatible for GMPLS networks; i.e. transit nodes (ITU term: Internal Protocol Controller (I-PC)) do not need to be updated.  G7713.2 is an E-NNI which is using GMPLS but it is not based on GMPLS e.g. G7713.2 does not provide call and connection functional separation because it was not based on use with an RFC-3473 network. Eve's mail clarifies this regarding the domain definitions. If the draft is confusing in this regard, we can work on the wording.
> 
> The draft is on extending RFC-3473 to support ASON. If IETF does not extend RFC-3473, then GMPLS will not support ASON. This work is totally independent of the existence of G7713.2. As we discuss the draft, we can clarify if this is confusing.
> 
> Deborah
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 10:38 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> AD-hat on.
> 
> Bart writes:
> >
> >
> > Stephen,
> >
> > I think the point was rather to go back to
> > just a single GMPLS spec instead of two (let alone three) variants...
> >
> If that is the case, and if we want to do that in IETF CCAMP
> (not sure it is part of the current CCAMP charter),
> then it seems to me that we (CCAMP) should excercise these steps:
> 
> - send some liason to ITU-T SG 15 to explain that we found that
>   there seems to be a GMPLS (for IETF) and a GMPLS-ASON standard
> - that we think that this is NOT goodness, and that we regret that
>   we did send the ASON people away a few years back and did not
>   closely follow their work in ITU
> - that we now believe that we should have worked better together,
> - that we would like to explore ways to try and mrege the two
>   solution back into one common solution
> 
> And then await the response and hope ITU will agree and then see
> how the work can be organized.
> 
> >
> > Bart
> >
> Bert

Delivery-date: Wed, 14 May 2003 13:59:27 +0000
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'John Drake'" <[email-masked]>, "Varma, Eve L (Eve)" <[email-masked]>, "'Ong, Lyndon'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, Jonathan Sadler <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 09:47:17 -0400

Hi,

Then the purpose of the reqts. draft is not explaining ITU-T requirements for
ASON in an IETF friendly way.

Eve

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Wednesday, May 14, 2003 9:42 AM
To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan
Sadler
Cc: [email-masked]
Subject: RE: ASON reqts

Eve,

Let me try again.  We are talking about the support of ASON in GMPLS
networks, and
we are trying to identify the ASON requirements on GMPLS signalling
(RSVP-TE).  By
definition, the E-NNI/I-NNI in a GMPLS network will be RSVP-TE (with IP
addressing).
If the signalling protocol within a domain is also RSVP-TE then the only
thing a
domain boundary node will do is modify the RSVP signalling messages subject
to local
policy.

If the signalling protocol within a domain is not RSVP-TE, then a domain
boundary
node for such a domain will have to build an interworking function between
its
signalling protocol and RSVP-TE.  This is not within the scope of this work.

Thanks,

John

> -----Original Message-----
> From: Varma, Eve L (Eve) [mailto:[email-masked]]
> Sent: Wednesday, May 14, 2003 5:27 AM
> To: John Drake; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Hi,
> 
> I strongly disagree.  The concept of control domains is one of the 
> key elements of G.8080 Am. 1, and support for such is part of the
> requirements.  This makes no statement re proprietary protocols.
> 
> Eve
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 5:36 PM
> To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Lyndon,
> 
> I think it is out of scope.  The only requirement is that a 
> group of one or
> more nodes running a proprietary control plane (e.g., OSRP) 
> must appear to
> be one or more GMPLS nodes, and this is a requirement on the vendor
> implementing the proprietary control plane.
> 
> Thanks,
> 
> John 
> 
> > -----Original Message-----
> > From: Ong, Lyndon [mailto:[email-masked]]
> > Sent: Tuesday, May 13, 2003 2:03 PM
> > To: 'Adrian Farrel'; Jonathan Sadler
> > Cc: [email-masked]; Ong, Lyndon
> > Subject: RE: ASON reqts
> > 
> > 
> > Hi Folks,
> > 
> > I think one aspect that may not come out clearly in the draft
> > is that ASON defines a concept of "control domains" (which is
> > included in the terminology section of the draft) and in the
> > amendment goes on to say that the structure and protocols used
> > in each domain may be different (e.g., centralized control in
> > one domain and distributed in another, RSVP in one and non-RSVP
> > in another).
> > 
> > I suggested that this be added to the draft, but we did not
> > get agreement on this before we decided to send it out, perhaps
> > because it was considered to be out of scope (?).
> > 
> > Cheers,
> > 
> > Lyndon
> > 
> > 
> > 
> > 
> > 
> > 
> 

Delivery-date: Wed, 14 May 2003 13:59:22 +0000
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'John Drake'" <[email-masked]>, "Varma, Eve L (Eve)" <[email-masked]>, "'Ong, Lyndon'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, Jonathan Sadler <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 09:58:55 -0400

Please see Steve's email.

Eve

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Wednesday, May 14, 2003 9:56 AM
To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan
Sadler
Cc: [email-masked]
Subject: RE: ASON reqts

Eve,

I am having trouble parsing your e-mail.

I thought my previous e-mail was stating what was, to use
Yakov's phrase, "obvious to the informed reader".

Thanks,

John

> -----Original Message-----
> From: Varma, Eve L (Eve) [mailto:[email-masked]]
> Sent: Wednesday, May 14, 2003 6:47 AM
> To: John Drake; Varma, Eve L (Eve); 'Ong, Lyndon'; 'Adrian Farrel';
> Jonathan Sadler
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Hi,
> 
> Then the purpose of the reqts. draft is not explaining ITU-T 
> requirements for
> ASON in an IETF friendly way.
> 
> Eve
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Wednesday, May 14, 2003 9:42 AM
> To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan
> Sadler
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Eve,
> 
> Let me try again.  We are talking about the support of ASON in GMPLS
> networks, and
> we are trying to identify the ASON requirements on GMPLS signalling
> (RSVP-TE).  By
> definition, the E-NNI/I-NNI in a GMPLS network will be 
> RSVP-TE (with IP
> addressing).
> If the signalling protocol within a domain is also RSVP-TE 
> then the only
> thing a
> domain boundary node will do is modify the RSVP signalling 
> messages subject
> to local
> policy.
> 
> If the signalling protocol within a domain is not RSVP-TE, 
> then a domain
> boundary
> node for such a domain will have to build an interworking 
> function between
> its
> signalling protocol and RSVP-TE.  This is not within the 
> scope of this work.
> 
> Thanks,
> 
> John
> 
> 
> > -----Original Message-----
> > From: Varma, Eve L (Eve) [mailto:[email-masked]]
> > Sent: Wednesday, May 14, 2003 5:27 AM
> > To: John Drake; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
> > Cc: [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > Hi,
> > 
> > I strongly disagree.  The concept of control domains is one of the 
> > key elements of G.8080 Am. 1, and support for such is part of the
> > requirements.  This makes no statement re proprietary protocols.
> > 
> > Eve
> > 
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Tuesday, May 13, 2003 5:36 PM
> > To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
> > Cc: [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > Lyndon,
> > 
> > I think it is out of scope.  The only requirement is that a 
> > group of one or
> > more nodes running a proprietary control plane (e.g., OSRP) 
> > must appear to
> > be one or more GMPLS nodes, and this is a requirement on the vendor
> > implementing the proprietary control plane.
> > 
> > Thanks,
> > 
> > John 
> > 
> > > -----Original Message-----
> > > From: Ong, Lyndon [mailto:[email-masked]]
> > > Sent: Tuesday, May 13, 2003 2:03 PM
> > > To: 'Adrian Farrel'; Jonathan Sadler
> > > Cc: [email-masked]; Ong, Lyndon
> > > Subject: RE: ASON reqts
> > > 
> > > 
> > > Hi Folks,
> > > 
> > > I think one aspect that may not come out clearly in the draft
> > > is that ASON defines a concept of "control domains" (which is
> > > included in the terminology section of the draft) and in the
> > > amendment goes on to say that the structure and protocols used
> > > in each domain may be different (e.g., centralized control in
> > > one domain and distributed in another, RSVP in one and non-RSVP
> > > in another).
> > > 
> > > I suggested that this be added to the draft, but we did not
> > > get agreement on this before we decided to send it out, perhaps
> > > because it was considered to be out of scope (?).
> > > 
> > > Cheers,
> > > 
> > > Lyndon
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> 

Delivery-date: Wed, 14 May 2003 13:56:58 +0000
From: John Drake <[email-masked]>
To: "'Varma, Eve L (Eve)'" <[email-masked]>, "'Ong, Lyndon'" <[email-masked]>, 'Adrian Farrel' <[email-masked]>, Jonathan Sadler <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 06:56:20 -0700

Eve,

I am having trouble parsing your e-mail.

I thought my previous e-mail was stating what was, to use
Yakov's phrase, "obvious to the informed reader".

Thanks,

John

> -----Original Message-----
> From: Varma, Eve L (Eve) [mailto:[email-masked]]
> Sent: Wednesday, May 14, 2003 6:47 AM
> To: John Drake; Varma, Eve L (Eve); 'Ong, Lyndon'; 'Adrian Farrel';
> Jonathan Sadler
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Hi,
> 
> Then the purpose of the reqts. draft is not explaining ITU-T 
> requirements for
> ASON in an IETF friendly way.
> 
> Eve
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Wednesday, May 14, 2003 9:42 AM
> To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan
> Sadler
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Eve,
> 
> Let me try again.  We are talking about the support of ASON in GMPLS
> networks, and
> we are trying to identify the ASON requirements on GMPLS signalling
> (RSVP-TE).  By
> definition, the E-NNI/I-NNI in a GMPLS network will be 
> RSVP-TE (with IP
> addressing).
> If the signalling protocol within a domain is also RSVP-TE 
> then the only
> thing a
> domain boundary node will do is modify the RSVP signalling 
> messages subject
> to local
> policy.
> 
> If the signalling protocol within a domain is not RSVP-TE, 
> then a domain
> boundary
> node for such a domain will have to build an interworking 
> function between
> its
> signalling protocol and RSVP-TE.  This is not within the 
> scope of this work.
> 
> Thanks,
> 
> John
> 
> 
> > -----Original Message-----
> > From: Varma, Eve L (Eve) [mailto:[email-masked]]
> > Sent: Wednesday, May 14, 2003 5:27 AM
> > To: John Drake; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
> > Cc: [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > Hi,
> > 
> > I strongly disagree.  The concept of control domains is one of the 
> > key elements of G.8080 Am. 1, and support for such is part of the
> > requirements.  This makes no statement re proprietary protocols.
> > 
> > Eve
> > 
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Tuesday, May 13, 2003 5:36 PM
> > To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
> > Cc: [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > Lyndon,
> > 
> > I think it is out of scope.  The only requirement is that a 
> > group of one or
> > more nodes running a proprietary control plane (e.g., OSRP) 
> > must appear to
> > be one or more GMPLS nodes, and this is a requirement on the vendor
> > implementing the proprietary control plane.
> > 
> > Thanks,
> > 
> > John 
> > 
> > > -----Original Message-----
> > > From: Ong, Lyndon [mailto:[email-masked]]
> > > Sent: Tuesday, May 13, 2003 2:03 PM
> > > To: 'Adrian Farrel'; Jonathan Sadler
> > > Cc: [email-masked]; Ong, Lyndon
> > > Subject: RE: ASON reqts
> > > 
> > > 
> > > Hi Folks,
> > > 
> > > I think one aspect that may not come out clearly in the draft
> > > is that ASON defines a concept of "control domains" (which is
> > > included in the terminology section of the draft) and in the
> > > amendment goes on to say that the structure and protocols used
> > > in each domain may be different (e.g., centralized control in
> > > one domain and distributed in another, RSVP in one and non-RSVP
> > > in another).
> > > 
> > > I suggested that this be added to the draft, but we did not
> > > get agreement on this before we decided to send it out, perhaps
> > > because it was considered to be out of scope (?).
> > > 
> > > Cheers,
> > > 
> > > Lyndon
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> 

Delivery-date: Wed, 14 May 2003 13:49:45 +0000
Date: Wed, 14 May 2003 07:49:15 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
CC: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

All,
I have a growing sense of unease that we could be headed
for trouble here because, among those who seem to support that
this becomes a WG document, there seem to be (among those who
indicate a reason) a wide variety of different motivations about
WHY this should be a WG document and what the posters expect
will happen as a result.

Perhaps more helpful than just a Yes/No preference, it would
be more helpful to characterize the reasons so that, if this
becomes a WG document, we know we have a consensus on why we
are doing this and what we are trying to accomplish.

I think I have detected the following motivations from different
posts in the thread:

1. Those who don't want this to be a WG document (we are done with
   this version of the specifications, lets get some experience
   with them before considering any further change or evolution).

2. Those who think this should be a WG document so that ASON extensions
   currently standardized in ITU-T will get standards track status in
   IETF (no intent to change the protocol, but document the superset
   in one place so that we don't get so many GMPLS implementations
   that don't support the ASON extensions).

3. Those who think there is nothing wrong with the ITU-T extensions to
   meet the ASON requirements, but believe that RFC 3474 didn't translate
   G.7713.2 properly and this draft is a first step to fixing RFC 3474.

4. Those who think that even the ITU-T extensions don't meet the ASON
   requirements, so IETF should now take it over and do it better starting
   with this draft.

5. Those who think that ITU-T didn't get the requirements right, so we
   need to look at everything from scratch.

There may be other motivations which I haven't detected or characterized,
but these seem to be the main camps.

So I don't think it is enough to just count how many say it should be
a WG document. I think that those in camp #2 above might be pretty upset
if the result of making this a WG document turns out to be a rototilling
of the protocol driven by those in camps #4 and #5. We will have a much
smoother time if we agree on why we are doing this and what we are trying
to accomplish as a result.

Once we settle on which of 1-5 we are trying to accomplish:
- If it is 1, 2, or 3, we can handle in IETF.
- If it is 4 or 5, we had better send a liaison to ITU-T.

Please let me know if I missed any proposed purposes for this draft.
Otherwise, for those of you who support this being a WG draft, I think
it might be helpful if you would indicate which of (2-5) characterizes
why you support this so we can make sure we are on the same page as to
what we are trying to accomplish.

Regards,
Steve

Delivery-date: Wed, 14 May 2003 13:43:30 +0000
From: John Drake <[email-masked]>
To: "'Varma, Eve L (Eve)'" <[email-masked]>, "'Ong, Lyndon'" <[email-masked]>, 'Adrian Farrel' <[email-masked]>, Jonathan Sadler <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 06:42:20 -0700

Eve,

Let me try again.  We are talking about the support of ASON in GMPLS
networks, and
we are trying to identify the ASON requirements on GMPLS signalling
(RSVP-TE).  By
definition, the E-NNI/I-NNI in a GMPLS network will be RSVP-TE (with IP
addressing).
If the signalling protocol within a domain is also RSVP-TE then the only
thing a
domain boundary node will do is modify the RSVP signalling messages subject
to local
policy.

If the signalling protocol within a domain is not RSVP-TE, then a domain
boundary
node for such a domain will have to build an interworking function between
its
signalling protocol and RSVP-TE.  This is not within the scope of this work.

Thanks,

John

> -----Original Message-----
> From: Varma, Eve L (Eve) [mailto:[email-masked]]
> Sent: Wednesday, May 14, 2003 5:27 AM
> To: John Drake; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Hi,
> 
> I strongly disagree.  The concept of control domains is one of the 
> key elements of G.8080 Am. 1, and support for such is part of the
> requirements.  This makes no statement re proprietary protocols.
> 
> Eve
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 5:36 PM
> To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Lyndon,
> 
> I think it is out of scope.  The only requirement is that a 
> group of one or
> more nodes running a proprietary control plane (e.g., OSRP) 
> must appear to
> be one or more GMPLS nodes, and this is a requirement on the vendor
> implementing the proprietary control plane.
> 
> Thanks,
> 
> John 
> 
> > -----Original Message-----
> > From: Ong, Lyndon [mailto:[email-masked]]
> > Sent: Tuesday, May 13, 2003 2:03 PM
> > To: 'Adrian Farrel'; Jonathan Sadler
> > Cc: [email-masked]; Ong, Lyndon
> > Subject: RE: ASON reqts
> > 
> > 
> > Hi Folks,
> > 
> > I think one aspect that may not come out clearly in the draft
> > is that ASON defines a concept of "control domains" (which is
> > included in the terminology section of the draft) and in the
> > amendment goes on to say that the structure and protocols used
> > in each domain may be different (e.g., centralized control in
> > one domain and distributed in another, RSVP in one and non-RSVP
> > in another).
> > 
> > I suggested that this be added to the draft, but we did not
> > get agreement on this before we decided to send it out, perhaps
> > because it was considered to be out of scope (?).
> > 
> > Cheers,
> > 
> > Lyndon
> > 
> > 
> > 
> > 
> > 
> > 
> 

Delivery-date: Wed, 14 May 2003 12:29:43 +0000
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'John Drake'" <[email-masked]>, "'Ong, Lyndon'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, Jonathan Sadler <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Wed, 14 May 2003 08:27:21 -0400

Hi,

I strongly disagree.  The concept of control domains is one of the 
key elements of G.8080 Am. 1, and support for such is part of the
requirements.  This makes no statement re proprietary protocols.

Eve

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Tuesday, May 13, 2003 5:36 PM
To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
Cc: [email-masked]
Subject: RE: ASON reqts

Lyndon,

I think it is out of scope.  The only requirement is that a group of one or
more nodes running a proprietary control plane (e.g., OSRP) must appear to
be one or more GMPLS nodes, and this is a requirement on the vendor
implementing the proprietary control plane.

Thanks,

John 

> -----Original Message-----
> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 2:03 PM
> To: 'Adrian Farrel'; Jonathan Sadler
> Cc: [email-masked]; Ong, Lyndon
> Subject: RE: ASON reqts
> 
> 
> Hi Folks,
> 
> I think one aspect that may not come out clearly in the draft
> is that ASON defines a concept of "control domains" (which is
> included in the terminology section of the draft) and in the
> amendment goes on to say that the structure and protocols used
> in each domain may be different (e.g., centralized control in
> one domain and distributed in another, RSVP in one and non-RSVP
> in another).
> 
> I suggested that this be added to the draft, but we did not
> get agreement on this before we decided to send it out, perhaps
> because it was considered to be out of scope (?).
> 
> Cheers,
> 
> Lyndon
> 
> 
> 
> 
> 
> 

Delivery-date: Wed, 14 May 2003 06:36:04 +0000
Date: Wed, 14 May 2003 08:40:57 +0200
From: [email-masked]
To: Lou Berger <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, [email-masked], Bert Wijnen <[email-masked]>
Subject: Re: ASON reqts

"I have read this document and it is ready to be a CCAMP WG doc"

Lou Berger wrote:
> 
> 
> At 12:39 PM 5/13/2003, Brungard, Deborah A, ALABS wrote:
> 
>> - majority of the email supports the reqs draft becoming a WG 
>> document. And hopefully, those concerned will also support as WG 
>> document based on the understanding a WG doc is a work in progress as 
>> posted by one email:
> 
> 
> I think Deborah has a good point here.  Yes, there are some point 
> discussions and proposed additions to the draft (it is a rev -00 after 
> all!) but it seems the general tenor of the conversation is that this 
> document is a good foundation for the WG to start with.
> 
> Oh WG chair(s),
>         Can you give us your read of the "humm" level of the list?  Can 
> we "officially" move on from the question of draft's filename to how it 
> should be modified?
> 
> Thanks,
> Lou
> 
> PS "I have read this document and it is ready to be a CCAMP WG doc"
> 
> 

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

Delivery-date: Wed, 14 May 2003 01:38:45 +0000
Date: Tue, 13 May 2003 21:37:27 -0400
From: Matt Squire <[email-masked]>
Reply-To: [email-masked]
To: John Drake <[email-masked]>
CC: "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

Ditto the "I have read the document and it is ready to be a CCAMP doc".

Either that or we break out a couple dozen eggs and continue to throw 
them between the ITU and the IETF.  I can go either way.

- Matt

John Drake wrote:
> "I have read this document and it is ready to be a CCAMP WG doc"
> 
> 
>>-----Original Message-----
>>From: Kireeti Kompella [mailto:[email-masked]]
>>Sent: Monday, May 12, 2003 8:25 AM
>>To: [email-masked]
>>Subject: Re: ASON reqts
>>
>>
>>I'd like to get a reading on whether this doc is ready to be a
>>CCAMP WG document.  Please respond (preferably publicly) with one of:
>> - "I have read this document and it is ready to be a CCAMP WG doc" OR
>> - "I have read this document, and it isn't ready to be a CCAMP doc".
>>

Delivery-date: Tue, 13 May 2003 23:50:54 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'John Drake' <[email-masked]>, "Ong, Lyndon" <[email-masked]>,  'Adrian Farrel' <[email-masked]>, Jonathan Sadler <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 16:53:52 -0700

Hi John,

The smart vendor will do what they know works,
first and foremost ;o)

But we're straying off topic...

Lyndon

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Tuesday, May 13, 2003 2:59 PM
To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
Cc: [email-masked]
Subject: RE: ASON reqts

JD:  But the smart vendor does it in such a way that it is
interoperable

Delivery-date: Tue, 13 May 2003 23:46:01 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 18:44:51 -0500
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, <[email-masked]>

Bert,

I think much of this discussion between ITU-T and IETF, and what you are =
proposing, has already occurred, some time ago:

dimitri> as of today we have two flavors "ASON/GMPLS" and "GMPLS"

steve> Can we please avoid creating a third variant of the protocol?

bart> I think the point was rather to go back to just a single
bart> GMPLS spec instead of two (let alone three) variants...

bert> If that is the case, and if we want to do that in IETF CCAMP=20
bert> (not sure it is part of the current CCAMP charter),
bert> then it seems to me that we (CCAMP) should exercise these steps:
bert>=20
bert> - send some liaison to ITU-T SG 15 to explain that we found that
bert>   there seems to be a GMPLS (for IETF) and a GMPLS-ASON standard
bert> - that we think that this is NOT goodness, and that we regret that
bert>   we did send the ASON people away a few years back and did not
bert>   closely follow their work in ITU
bert> - that we now believe that we should have worked better together,
bert> - that we would like to explore ways to try and merge the two
bert>   solution back into one common solution
bert>=20
bert> And then await the response and hope ITU will agree and then see
bert> how the work can be organized.

Recall that we had extended discussions last January regarding the =
ASON-GMPLS issues, wherein many of the same points were made, and =
conclusions reached:

1. Brief History of ASON-GMPLS extensions:

In February 2002, ITU-T sent IETF/CCAMP a liaison statement identifying =
the 'gaps' between the ITU-T ASON requirements (sent 7 months earlier) =
and GMPLS protocols, which included:
a. call & connection separation,=20
b. additional error codes/values,=20
c. restart mechanisms,
d. support of crankback capability.

The liaison was presented to IETF/CCAMP at IETF-53/Minneapolis (March =
2002), and requested assistance in closing the gaps and invited input =
from IETF.  IETF/CCAMP proposed to 'close the gaps' and CCAMP charter =
extensions to address same were suggested at IETF-54/Yokohama, but were =
not made.  This caused frustration within ITU-T in not getting attention =
to the needed ASON requirements in IETF/CCAMP. =20

ITU decided to extend GMPLS protocols themselves, leading to the present =
interoperability concerns with ITU-GMPLS and GMPLS.  At the April/May =
2002 ITU-T meeting, draft Recommendations were put forward to close the =
gaps, namely, draft Recommendations G.7713.2 (RSVP-TE ITU-GMPLS =
extensions) and G.7713.3 (CR-LDP ITU-GMPLS extensions). =20

ITU-T sent a liaison in May 2002 to ask for comments on the draft =
Recommendations, and to request alignment with GMPLS, as follows: =
"Please consider including the proposed solutions provided in G.7713.2 =
and G.7713.3 to update the existing GMPLS signaling work in support of =
ASON requirements."  This request shows that the intent was to have =
extensions made by CCAMP to GMPLS protocols based on the ASON =
requirements and thus close the 'gaps'.

Steve Trowbridge noted that "After some private communication with the =
Area directors, we received some advice that one tool that might be used =
to finally get the IANA codepoint assignment complete would be to =
publish what we were doing in ITU-T as informational RFCs.  This is the =
stage we are at today."

In summary, ITU-T kept the IETF informed of its work, invited help to =
address the ITU-T ASON requirements, invited alignment of the base GMPLS =
protocols, but there was no response or interest from the IETF to do =
this.  The unfortunate outcome of this is to be standardizing 2 versions =
of GMPLS: ITU-GMPLS and GMPLS.

2. Several concerns were raised to this outcome, such as:

a. "I'm concerned with non-IETF groups like ITU-T deciding to develop =
their own incompatible extensions.  Groups like these should not be =
extending IETF protocols without consulting with the relevant IETF =
working groups.  Otherwise we end up with extensions that duplicate =
existing IETF functionality, don't coexist gracefully, and/or break =
interoperability."

b. "Which spec does a vendor implement and an operator use, given =
interoperability needs, etc.?  It would be analogous to the IETF =
specifying their version of G.709."

c. "The ITU has developed protocol extensions for GMPLS, something =
outside the charter of the ITU."

3. A resolution to the problem was proposed and got some agreement:

"It would be worthwhile to package the needed ASON extensions into a =
proposed GMPLS upgrade and presented to CCAMP as such: bring the =
requirements to CCAMP as a requirements draft, thrash them out, and get =
the necessary extensions adopted in CCAMP."

There were many who agreed with this approach, that is, to extend GMPLS =
(as originally proposed by the ITU-T) to meet the ITU-T ASON =
requirements.  Several of us joined the current effort with the intent =
that this is the direction we were taking.

IMO, you have proposed something that is quite consistent with all of =
the above.  However, much of what you propose has already transpired =
(perhaps 'unofficially') between the IETF and ITU-T.

Thanks,
Jerry

Delivery-date: Tue, 13 May 2003 22:14:37 +0000
Date: Tue, 13 May 2003 18:13:10 -0400
To: Kireeti Kompella <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: ASON reqts
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>, Bert Wijnen <[email-masked]>

At 12:39 PM 5/13/2003, Brungard, Deborah A, ALABS wrote:
>- majority of the email supports the reqs draft becoming a WG document. 
>And hopefully, those concerned will also support as WG document based on 
>the understanding a WG doc is a work in progress as posted by one email:

I think Deborah has a good point here.  Yes, there are some point 
discussions and proposed additions to the draft (it is a rev -00 after 
all!) but it seems the general tenor of the conversation is that this 
document is a good foundation for the WG to start with.

Oh WG chair(s),
         Can you give us your read of the "humm" level of the list?  Can we 
"officially" move on from the question of draft's filename to how it should 
be modified?

Thanks,
Lou

PS "I have read this document and it is ready to be a CCAMP WG doc"

Delivery-date: Tue, 13 May 2003 21:59:51 +0000
From: John Drake <[email-masked]>
To: "'Ong, Lyndon'" <[email-masked]>, 'Adrian Farrel' <[email-masked]>,  Jonathan Sadler <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 14:59:21 -0700

> -----Original Message-----
> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 2:54 PM
> To: John Drake; Ong, Lyndon; 'Adrian Farrel'; Jonathan Sadler
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Hi John,
> 
> I think it's not just an issue of non-RSVP domains, but
> also how to interwork legacy systems that are centrally
> controlled, and maybe variants in-between.  It's reasonable
> to see if extensions or changes are needed in the protocols
> to support this, given that carriers are not building
> networks from scratch anymore.

JD:  You can always put a GMPLS front end on a centralized NMS
system without changing GMPLS in any way

> 
> BTW, in order to deploy distributed control on large 
> networks today you necessarily have to go beyond the
> standards in order to provide the set of functions a
> carrier needs.  That's just that state of things at this
> point in time.

JD:  But the smart vendor does it in such a way that it is
interoperable

> 
> Cheers,
> 
> Lyndon
> 
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 2:36 PM
> To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Lyndon,
> 
> I think it is out of scope.  The only requirement is that a 
> group of one or
> more nodes running a proprietary control plane (e.g., OSRP) 
> must appear to
> be one or more GMPLS nodes, and this is a requirement on the vendor
> implementing the proprietary control plane.
> 
> Thanks,
> 
> John 
> 
> > -----Original Message-----
> > From: Ong, Lyndon [mailto:[email-masked]]
> > Sent: Tuesday, May 13, 2003 2:03 PM
> > To: 'Adrian Farrel'; Jonathan Sadler
> > Cc: [email-masked]; Ong, Lyndon
> > Subject: RE: ASON reqts
> > 
> > 
> > Hi Folks,
> > 
> > I think one aspect that may not come out clearly in the draft
> > is that ASON defines a concept of "control domains" (which is
> > included in the terminology section of the draft) and in the
> > amendment goes on to say that the structure and protocols used
> > in each domain may be different (e.g., centralized control in
> > one domain and distributed in another, RSVP in one and non-RSVP
> > in another).
> > 
> > I suggested that this be added to the draft, but we did not
> > get agreement on this before we decided to send it out, perhaps
> > because it was considered to be out of scope (?).
> > 
> > Cheers,
> > 
> > Lyndon
> > 
> > 
> > 
> > 
> > 
> > 
> 

Delivery-date: Tue, 13 May 2003 21:51:27 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'John Drake' <[email-masked]>, "Ong, Lyndon" <[email-masked]>,  'Adrian Farrel' <[email-masked]>, Jonathan Sadler <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 14:54:22 -0700

Hi John,

I think it's not just an issue of non-RSVP domains, but
also how to interwork legacy systems that are centrally
controlled, and maybe variants in-between.  It's reasonable
to see if extensions or changes are needed in the protocols
to support this, given that carriers are not building
networks from scratch anymore.

BTW, in order to deploy distributed control on large 
networks today you necessarily have to go beyond the
standards in order to provide the set of functions a
carrier needs.  That's just that state of things at this
point in time.

Cheers,

Lyndon

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Tuesday, May 13, 2003 2:36 PM
To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
Cc: [email-masked]
Subject: RE: ASON reqts

Lyndon,

I think it is out of scope.  The only requirement is that a group of one or
more nodes running a proprietary control plane (e.g., OSRP) must appear to
be one or more GMPLS nodes, and this is a requirement on the vendor
implementing the proprietary control plane.

Thanks,

John 

> -----Original Message-----
> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 2:03 PM
> To: 'Adrian Farrel'; Jonathan Sadler
> Cc: [email-masked]; Ong, Lyndon
> Subject: RE: ASON reqts
> 
> 
> Hi Folks,
> 
> I think one aspect that may not come out clearly in the draft
> is that ASON defines a concept of "control domains" (which is
> included in the terminology section of the draft) and in the
> amendment goes on to say that the structure and protocols used
> in each domain may be different (e.g., centralized control in
> one domain and distributed in another, RSVP in one and non-RSVP
> in another).
> 
> I suggested that this be added to the draft, but we did not
> get agreement on this before we decided to send it out, perhaps
> because it was considered to be out of scope (?).
> 
> Cheers,
> 
> Lyndon
> 
> 
> 
> 
> 
> 

Delivery-date: Tue, 13 May 2003 21:45:10 +0000
From: "jvluciani" <[email-masked]>
To: "'Osama Aboul-Magd'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, "'Jonathan Sadler'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 17:44:39 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_005B_01C31977.5507E810
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Actually this is not factual.  I emailed Osama several times to ask for
status and to have the draft updated and there was no reply.  Whether
there is interest outside of the authors is less clear, however it was
most certainly not dropped without several attempts to urge progress
onward.

IPO is shutting down.  The draft would more likely be appropriate as an
individual contribution draft at this point.

--Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Osama Aboul-Magd
Sent: Tuesday, May 13, 2003 5:06 PM
To: Adrian Farrel; Jonathan Sadler
Cc: [email-masked]
Subject: RE: ASON reqts

The IPO-ASON draft was dropped unceremoniously from the IPO WG drafts
some time ago. It probably is a victim to the current state of the IPO
WG and the level of interest in its activities. The fact that the draft
expired doesn't explain why it was removed from the WG drafts. Other
expired drafts are still sitting their.

If there is interest, a new revision could be worked out to include the
latest ASON related work as per the ITU meeting in January 2003. However
I don't think IPO is the right place for it. 

Regards; 

>Ah, OK. No new references. Just a query about whether IPO-ASON is ood. 
>It may be ood but it also provides relevant IETF b/g. 
>So it stays for the moment and either it gets republished, or the ref
gets 
>dropped later. 

>Thanks, 
>Adrian 

------=_NextPart_000_005B_01C31977.5507E810
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title>RE: ASON reqts</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Actually this is not factual.&nbsp; =
I
emailed Osama several times to ask for status and to have the draft =
updated and
there was no reply.&nbsp; Whether there is interest outside of the =
authors is
less clear, however it was most certainly not dropped without several =
attempts
to urge progress onward.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>IPO is shutting down.&nbsp; The =
draft
would more likely be appropriate as an individual contribution draft at =
this
point.</span></font></p>

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

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

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

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]] <b><span style=3D'font-weight:bold'>On =
Behalf
Of </span></b>Osama Aboul-Magd<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, May 13, =
2003 5:06
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Adrian Farrel; =
Jonathan Sadler<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: ASON =
reqts</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal =
style=3D'margin-right:0in;margin-bottom:12.0pt;margin-left:
.5in'><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><br>
<br>
</span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>The IPO-ASON draft was dropped =
unceremoniously from
the IPO WG drafts some time ago. It probably is a victim to the current =
state
of the IPO WG and the level of interest in its activities. The fact that =
the
draft expired doesn't explain why it was removed from the WG drafts. =
Other
expired drafts are still sitting their.</span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>If there is interest, a new revision could be =
worked
out to include the latest ASON related work as per the ITU meeting in =
January
2003. However I don't think IPO is the right place for it. =
</span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Regards;</span></font> </p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&gt;Ah, OK. No new references. Just a query =
about
whether IPO-ASON is ood.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;It may be ood but it =
also
provides relevant IETF b/g.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;So it stays for the =
moment and
either it gets republished, or the ref gets</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;dropped =
later.</span></font> </p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&gt;Thanks,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Adrian</span></font> =
</p>

</div>

</body>

</html>

------=_NextPart_000_005B_01C31977.5507E810--

Delivery-date: Tue, 13 May 2003 21:36:36 +0000
From: John Drake <[email-masked]>
To: "'Ong, Lyndon'" <[email-masked]>, 'Adrian Farrel' <[email-masked]>,  Jonathan Sadler <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 14:35:51 -0700

Lyndon,

I think it is out of scope.  The only requirement is that a group of one or
more nodes running a proprietary control plane (e.g., OSRP) must appear to
be one or more GMPLS nodes, and this is a requirement on the vendor
implementing the proprietary control plane.

Thanks,

John 

> -----Original Message-----
> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 2:03 PM
> To: 'Adrian Farrel'; Jonathan Sadler
> Cc: [email-masked]; Ong, Lyndon
> Subject: RE: ASON reqts
> 
> 
> Hi Folks,
> 
> I think one aspect that may not come out clearly in the draft
> is that ASON defines a concept of "control domains" (which is
> included in the terminology section of the draft) and in the
> amendment goes on to say that the structure and protocols used
> in each domain may be different (e.g., centralized control in
> one domain and distributed in another, RSVP in one and non-RSVP
> in another).
> 
> I suggested that this be added to the draft, but we did not
> get agreement on this before we decided to send it out, perhaps
> because it was considered to be out of scope (?).
> 
> Cheers,
> 
> Lyndon
> 
> 
> 
> 
> 
> 

Delivery-date: Tue, 13 May 2003 21:06:54 +0000
From: "Osama Aboul-Magd" <[email-masked]>
To: Adrian Farrel <[email-masked]>, Jonathan Sadler <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 17:05:32 -0400

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

------_=_NextPart_001_01C31993.63E8917E
Content-Type: text/plain

The IPO-ASON draft was dropped unceremoniously from the IPO WG drafts some
time ago. It probably is a victim to the current state of the IPO WG and the
level of interest in its activities. The fact that the draft expired doesn't
explain why it was removed from the WG drafts. Other expired drafts are
still sitting their.

If there is interest, a new revision could be worked out to include the
latest ASON related work as per the ITU meeting in January 2003. However I
don't think IPO is the right place for it. 

Regards;

>Ah, OK. No new references. Just a query about whether IPO-ASON is ood.
>It may be ood but it also provides relevant IETF b/g.
>So it stays for the moment and either it gets republished, or the ref gets
>dropped later.

>Thanks,
>Adrian

------_=_NextPart_001_01C31993.63E8917E
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: ASON reqts</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>The IPO-ASON draft was dropped unceremoniously from =
the IPO WG drafts some time ago. It probably is a victim to the current =
state of the IPO WG and the level of interest in its activities. The =
fact that the draft expired doesn't explain why it was removed from the =
WG drafts. Other expired drafts are still sitting their.</FONT></P>

<P><FONT SIZE=3D2>If there is interest, a new revision could be worked =
out to include the latest ASON related work as per the ITU meeting in =
January 2003. However I don't think IPO is the right place for it. =
</FONT></P>

<P><FONT SIZE=3D2>Regards;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;Ah, OK. No new references. Just a query about =
whether IPO-ASON is ood.</FONT>
<BR><FONT SIZE=3D2>&gt;It may be ood but it also provides relevant IETF =
b/g.</FONT>
<BR><FONT SIZE=3D2>&gt;So it stays for the moment and either it gets =
republished, or the ref gets</FONT>
<BR><FONT SIZE=3D2>&gt;dropped later.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt;Adrian</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C31993.63E8917E--

Delivery-date: Tue, 13 May 2003 21:04:14 +0000
Date: Tue, 13 May 2003 21:00:17 -0500
From: Jonathan Sadler <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: "Brungard, Deborah A, ALABS" <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

Adrian -

Some more information on the issues raised previously, and a
couple more missing requirements...

Jonathan Sadler

Adrian Farrel wrote:

> Jonathan,
>
> > Likewise, dropping
> > the items handled in RFC 3474 would requires an active decision to
> > be made by the authors.  The document should include this reasoning.
>
> Perhaps you have an example or two of things in RFC 3474 that are dropped by
> ASON-REQ but are ASON architectural requirements?

In addition to the two in my previous email, here are some more:
  - Explicit support for connection partitioning in different
    administrative domains. (G.8080 Amd.1)
  - Use of transport plane names instead of DCN addresses when
    refering to transport plane resources. (G.8080 Amd.1)

Again, I'm interested in why these and the previously mentioned
two items which were covered in RFC 3474 have not been included in
the ASON-REQ draft.

> > For those unfamiliar with some of the differences, a cursorary review
> > of the G.7713 reveals:
> >   - Discussion of required behavior at E-NNI and UNI reference points
>
> I should say that this is covered in the Problem Statement in section 3
>
>    The ASON control plane specification is meant to be applicable to
>    different transport technologies (e.g., SDH/SONET, OTN) in various
>    networking environments (e.g., inter-carrier, intra-carrier). Also,
>    ASON model distinguishes reference points (representing points of
>    protocol information exchange) defined (1) between an administrative
>    domain and a user (2) between administrative domains and (3) between
>    areas of the same administrative domain and when needed between
>    control components (or simply controllers) within areas. A full
>    description of the ASON terms and relationship between ASON model
>    and GMPLS protocol suite may be found in [IPO-ASON].
>
> Further in section 4
>
>    Note: support of the above functions is independent of any user-to-
>    network interface and is therefore not constrained nor restricted by
>    its implementation specifics (see [ITU-T G.8080] and [ITU-T G.7713])

However, the text above is not a discussion of required
behavior -- its just an acknowledgement that the reference
points exist.

For example, G.8080 defines separation of the address spaces
used by the Network and used by Users.  RFC 3474 provides for this
separation in defining new UNI and E-NNI Address C-types.

The requirements document is remarkably silent on this issue.

> >   - Support for complete Call/Connection separation, including
> >     0-connection calls
>
> Hmmm?
> Are you saying that ASON-REQ doesn't include a discussion of complete
> call/connection separation?
> 4.2 seems to have that covered.

Sorry, I wasn't completely clear.  G.8080 allows for 0-connection
calls -- Section 4.2 of the proposed document does not deal with
this.  RFC 3474 provides a mechanism that allows nodes that have
implemented the CALL_OPS object to handle this case.

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

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

Delivery-date: Tue, 13 May 2003 21:00:20 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'Adrian Farrel' <[email-masked]>, Jonathan Sadler <[email-masked]>
Cc: [email-masked], "Ong, Lyndon" <[email-masked]>
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 14:02:59 -0700

Hi Folks,

I think one aspect that may not come out clearly in the draft
is that ASON defines a concept of "control domains" (which is
included in the terminology section of the draft) and in the
amendment goes on to say that the structure and protocols used
in each domain may be different (e.g., centralized control in
one domain and distributed in another, RSVP in one and non-RSVP
in another).

I suggested that this be added to the draft, but we did not
get agreement on this before we decided to send it out, perhaps
because it was considered to be out of scope (?).

Cheers,

Lyndon

Envelope-to: [email-masked]
Delivery-date: Tue, 13 May 2003 20:37:13 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Jonathan Sadler" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ASON reqts
Date: Tue, 13 May 2003 16:36:32 -0400

Jonathan,

> The authors should provide them, along with their reasoning why.

???

> Stating compliance with the requirements docs requires being
> familiar with the material in those documents.

Yes, and...?

> Likewise, dropping
> the items handled in RFC 3474 would requires an active decision to
> be made by the authors.  The document should include this reasoning.

Perhaps you have an example or two of things in RFC 3474 that are dropped by
ASON-REQ but are ASON architectural requirements?

> For those unfamiliar with some of the differences, a cursorary review
> of the G.7713 reveals:
>   - Discussion of required behavior at E-NNI and UNI reference points

I should say that this is covered in the Problem Statement in section 3

   The ASON control plane specification is meant to be applicable to
   different transport technologies (e.g., SDH/SONET, OTN) in various
   networking environments (e.g., inter-carrier, intra-carrier). Also,
   ASON model distinguishes reference points (representing points of
   protocol information exchange) defined (1) between an administrative
   domain and a user (2) between administrative domains and (3) between
   areas of the same administrative domain and when needed between
   control components (or simply controllers) within areas. A full
   description of the ASON terms and relationship between ASON model
   and GMPLS protocol suite may be found in [IPO-ASON].

Further in section 4

   Note: support of the above functions is independent of any user-to-
   network interface and is therefore not constrained nor restricted by
   its implementation specifics (see [ITU-T G.8080] and [ITU-T G.7713])

Was there something more specific you were after?

>   - Support for complete Call/Connection separation, including
>     0-connection calls

Hmmm?
Are you saying that ASON-REQ doesn't include a discussion of complete
call/connection separation?
4.2 seems to have that covered.

I can see how there may be benefit in adding text to clarify the separation
options. Perhpas you could suggest some.

Cheers,
Adrian

Envelope-to: [email-masked]
Delivery-date: Tue, 13 May 2003 20:24:08 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Jonathan Sadler" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ASON reqts
Date: Tue, 13 May 2003 16:23:44 -0400

> > > Currently, the document excludes a number of requirements specified in
G.8080,
> > > and G.7713 that are handled by RFC 3474.  No information is provided in
the
> > > document or on the CCAMP list why these were dropped.
> >
> > Pointers please.
> > There was no intention to drop any requirement so please let us know what is
> > missing.
>
> See my previous email to Deborah, as well as G.7713, G.8080, and G.8080 Amd.
1.
>
> NB: All of these documents have been liaised to the IETF.  The liaison
statements
> including the documents can be found under the CCAMP link at:
>
>
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/in
dex.html

Will respond to you email to Deborah separately.
With regards to your comments here...
This isn't an accademic guessing game - if you have specific constructive
comments along the lines of "requirement xyz as specificed in dogument G.1234
section a.b.c is missing" then please say so. The authors are trying to do their
best and are asking for helpful input.

> > > I would also like to know why it is referencing outdated documents (ex.
> > > [IPO-ASON] was published in March 2002) when more recent
> > > requirements/architecture material is available.
> >
> > Well, there is no reason not to reference this material at this stage.
Indeed,
> > someone just asked for it to be referenced, I think.
>
> Unfortunately, the IPO-ASON draft referenced doesn't include a number of the
> conceptual items developed after the consent of G.8080 in Oct. 2001.  Many of
these
> items were added in G.8080 Amd. 1 and G.7713.2, both of which were consented
in
> January of 2003.
>
> > With regard to other material, again please provide pointers and we will
happily
> > read and reference is as appropriate.
>
> G.8080 as updated by G.8080 Amd. 1, and G.7713.2 are more up to date.

Ah, OK. No new references. Just a query about whether IPO-ASON is ood.
It may be ood but it also provides relevant IETF b/g.
So it stays for the moment and either it gets republished, or the ref gets
dropped later.

Thanks,
Adrian

Delivery-date: Tue, 13 May 2003 20:20:17 +0000
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'Ong, Lyndon'" <[email-masked]>, "'Brungard, Deborah A, ALABS'" <[email-masked]>, "Varma, Eve L (Eve)" <[email-masked]>, John Drake <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 16:19:39 -0400

Hi,

In terms of requirements, these come from G.807, G.8080 & Am. 1, and
G.7713.  The IPO-ASON draft elaborated on a number of these (though
some of the material re domains was outdated vis-a-vis G.8080 Am. 1).

As Lyndon mentioned, the ITU-T reqts. work was influenced by contributions
from companies that sent representatives to the meetings, as well as from material from
other standards and industry fora that was liaised to these meetings.   Many of
these companies sent representatives to IETF as well.

Eve

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]
Sent: Tuesday, May 13, 2003 4:14 PM
To: 'Brungard, Deborah A, ALABS'; Varma, Eve L (Eve); John Drake;
Wijnen, Bert (Bert)
Cc: [email-masked]; Ong, Lyndon
Subject: RE: ASON reqts

Hi Deborah,

I kind of agree and disagree...

The requirements draft attempts to summarize 8080 specifically
regarding its impacts on signaling, so it does not repeat 8080
but may of course not be complete.

Regarding the IETF GMPLS experts, that seems a bit unfair, the
ITU work was naturally influenced by who was there at the meeting;
this included a number of folks who are also very active at IETF
and implemented GMPLS protocols.

I still think the issue that most people had with RFC 3474 was
that process-wise they would rather that it had gone through the
ccamp group or alternatively asked for FCFS codepoints...

Cheers,

Lyndon

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Tuesday, May 13, 2003 12:20 PM
To: Varma, Eve L (Eve); John Drake; Wijnen, Bert (Bert)
Cc: [email-masked]
Subject: RE: ASON reqts

The intention of gmpls-ason-reqs is not to repeat G8080. And it is not about G7713.2. It is to address GMPLS support of G8080. If it becomes a WG document, any/all comments are welcome. Individuals' participation will depend on company interests. We can not "require" anyone to participate. This is not a hobby for most of us;-)

This email is more appropriate as a private exchange - naming of individuals severely lacks in recognition of the many who contribute in the T1X1/ITU and the IETF work. As T1X1.5 chair/vice chair for many years, including the birth of ASON, I wish I could say, that I was too young too remember, but I was there, actually Malcolm could say he was too young;-). And I am not the primary player for T1X1.5 work, there are no primary players, it is a committee representing companies. One could ask, why were none of the IETF GMPLS experts asked to participate in the ITU work?

We are trying to progress an IETF draft on GMPLS support of ASON. I am a carrier interested in GMPLS. None of us are writing resumes. Let's progress with specific comments on the drafts.

Deborah

Delivery-date: Tue, 13 May 2003 20:15:52 +0000
Date: Tue, 13 May 2003 20:12:01 -0500
From: Jonathan Sadler <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: ASON reqts

Adrian -

See inline...

Jonathan Sadler

Adrian Farrel wrote:

> > Currently, the document excludes a number of requirements specified in G.8080,
> > and G.7713 that are handled by RFC 3474.  No information is provided in the
> > document or on the CCAMP list why these were dropped.
>
> Pointers please.
> There was no intention to drop any requirement so please let us know what is
> missing.

See my previous email to Deborah, as well as G.7713, G.8080, and G.8080 Amd. 1.

NB: All of these documents have been liaised to the IETF.  The liaison statements
including the documents can be found under the CCAMP link at:

ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html

> > I would also like to know why it is referencing outdated documents (ex.
> > [IPO-ASON] was published in March 2002) when more recent
> > requirements/architecture material is available.
>
> Well, there is no reason not to reference this material at this stage. Indeed,
> someone just asked for it to be referenced, I think.

Unfortunately, the IPO-ASON draft referenced doesn't include a number of the
conceptual items developed after the consent of G.8080 in Oct. 2001.  Many of these
items were added in G.8080 Amd. 1 and G.7713.2, both of which were consented in
January of 2003.

> With regard to other material, again please provide pointers and we will happily
> read and reference is as appropriate.

G.8080 as updated by G.8080 Amd. 1, and G.7713.2 are more up to date.

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

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

Delivery-date: Tue, 13 May 2003 20:11:13 +0000
From: "Ong, Lyndon" <[email-masked]>
To: "'Brungard, Deborah A, ALABS'" <[email-masked]>,  "Varma, Eve L (Eve)" <[email-masked]>, John Drake <[email-masked]>,  "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked], "Ong, Lyndon" <[email-masked]>
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 13:14:07 -0700

Hi Deborah,

I kind of agree and disagree...

The requirements draft attempts to summarize 8080 specifically
regarding its impacts on signaling, so it does not repeat 8080
but may of course not be complete.

Regarding the IETF GMPLS experts, that seems a bit unfair, the
ITU work was naturally influenced by who was there at the meeting;
this included a number of folks who are also very active at IETF
and implemented GMPLS protocols.

I still think the issue that most people had with RFC 3474 was
that process-wise they would rather that it had gone through the
ccamp group or alternatively asked for FCFS codepoints...

Cheers,

Lyndon

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Tuesday, May 13, 2003 12:20 PM
To: Varma, Eve L (Eve); John Drake; Wijnen, Bert (Bert)
Cc: [email-masked]
Subject: RE: ASON reqts

The intention of gmpls-ason-reqs is not to repeat G8080. And it is not about G7713.2. It is to address GMPLS support of G8080. If it becomes a WG document, any/all comments are welcome. Individuals' participation will depend on company interests. We can not "require" anyone to participate. This is not a hobby for most of us;-)

This email is more appropriate as a private exchange - naming of individuals severely lacks in recognition of the many who contribute in the T1X1/ITU and the IETF work. As T1X1.5 chair/vice chair for many years, including the birth of ASON, I wish I could say, that I was too young too remember, but I was there, actually Malcolm could say he was too young;-). And I am not the primary player for T1X1.5 work, there are no primary players, it is a committee representing companies. One could ask, why were none of the IETF GMPLS experts asked to participate in the ITU work?

We are trying to progress an IETF draft on GMPLS support of ASON. I am a carrier interested in GMPLS. None of us are writing resumes. Let's progress with specific comments on the drafts.

Deborah

Delivery-date: Tue, 13 May 2003 20:05:15 +0000
Date: Tue, 13 May 2003 19:56:51 -0500
From: Jonathan Sadler <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

Deborah -

The authors should provide them, along with their reasoning why.

Stating compliance with the requirements docs requires being
familiar with the material in those documents.  Likewise, dropping
the items handled in RFC 3474 would requires an active decision to
be made by the authors.  The document should include this reasoning.

For those unfamiliar with some of the differences, a cursorary review
of the G.7713 reveals:
  - Discussion of required behavior at E-NNI and UNI reference points
  - Support for complete Call/Connection separation, including
    0-connection calls

These are documented by RFC 3474.

Others can be found by looking at G.8080, and G.8080 Amd. 1.

Jonathan Sadler

"Brungard, Deborah A, ALABS" wrote:

> Hi Jonathan,
>
> We need specifics-
> Deborah
>
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 7:57 PM
> To: Kireeti Kompella
> Cc: [email-masked]
> Subject: Re: ASON reqts
>
> Kireeti -
>
> "I have read this document, and it isn't ready to be a CCAMP doc".
>
> Currently, the document excludes a number of requirements specified in G.8080,
> and G.7713 that are handled by RFC 3474.  No information is provided in the
> document or on the CCAMP list why these were dropped.
>
> I would also like to know why it is referencing outdated documents (ex.
> [IPO-ASON] was published in March 2002) when more recent
> requirements/architecture material is available.
>
> Jonathan Sadler
>
> Kireeti Kompella wrote:
>
> > Hi All,
> >
> > On Fri, 2 May 2003, Kireeti Kompella wrote:
> >
> > > To take things one at a time, it would be very useful to read and comment
> > > on the ASON reqts draft, as this was deemed tremendously important, and
> > > a rich source of misunderstanding and cross-talk; and coming to a common
> > > understanding over this should help get the IETF and the ITU working
> > > together.
> >
> > I haven't seen many comments, so the assumption is either that no
> > one cares, or that folks have read it and have no issues.
> >
> > I'd like to get a reading on whether this doc is ready to be a
> > CCAMP WG document.  Please respond (preferably publicly) with one of:
> >  - "I have read this document and it is ready to be a CCAMP WG doc" OR
> >  - "I have read this document, and it isn't ready to be a CCAMP doc".
> >
> > Note that if there aren't enough responses, the default assumption is
> > that the document is either not of interest or not ready, and in
> > either case will not become a CCAMP WG doc.  Note too that this doc
> > is an attempt to bridge some gaps between the IETF and the ITU-T,
> > and as such is fairly important.  It would be useful to give an
> > update on its status at the interim T1X1 meeting in June.
> >
> > Please get your responses in by COB Friday May 16th.
> >
> > Thanks,
> > Kireeti.
>
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure.  If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
>
> Thank you.
> Tellabs
> ============================================================

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

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

Delivery-date: Tue, 13 May 2003 20:02:45 +0000
From: John Drake <[email-masked]>
To: 'Jonathan Sadler' <[email-masked]>
Cc: 'Stephen Trowbridge' <[email-masked]>,  "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 13:02:04 -0700

We've been through all of this before many times.  Because the call, even in
complete separation mode, is established using Path/Resv, intermediate nodes
that don't understand what is going on will instantiate state and allocate
resources as if a connection is being established.

> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 4:59 PM
> To: John Drake
> Cc: 'Stephen Trowbridge'; 'Wijnen, Bert (Bert)'; Kireeti Kompella;
> [email-masked]
> Subject: Re: ASON reqts
> 
> 
> John -
> 
> What does section 9.2 of RFC 3474 accomplish then?  (For 
> those unaware, Sect.
> 9.2 is titled "Complete Separation of Call and Connection")
> 
> Jonathan Sadler
> 
> John Drake wrote:
> 
> > I think that the problem is that RFC 3474, in addition to 
> its technical
> > issues, doesn't address all of the ASON requirements.  For 
> example, it does
> > not address full call/connection separation.  So we're 
> following the post
> > 3474 procees of documenting the ASON requirements relevant to GMPLS
> > signalling in order to have a common understanding of what 
> problem is to be
> > solved.
> >
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > Sent: Monday, May 12, 2003 2:27 PM
> > > To: John Drake
> > > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> > > Subject: Re: ASON reqts
> > >
> > >
> > > Bert & John,
> > > I think this document has nothing to do with the issue Bert
> > > mentioned. This was a protocol issue, not a requirements issue.
> > > A decision was made to leave the message out of 3474 with the
> > > belief that:
> > > - The protocol works without it; and
> > > - The presence of the message violates the protocol.
> > > The appropriate next step here would be a liaison back to ITU-T
> > > explaining what was done and why, and if the ITU-T agrees with
> > > the reasoning, they can align their protocol document (in this
> > > case, G.7713.2).
> > >
> > > Back to Bert's original questions:
> > > > > > > - is there or do we see any conflict?
> > > - As Zhi said, this is not (yet) fully aligned with ITU-T 
> requirements
> > >   and should not be advanced to a WG document until it is.
> > > However, before
> > >   we do, I think we need to understand why this is necessary
> > > - see below.
> > >
> > > > > > > - are we duplicating some work?
> > > - Almost certainly. If we take the kind of alignment with ITU-T
> > >   requirements that Zhi mentions as a "gate" for progressing
> > > this, then
> > >   what is in this document that is different from G.8080 and
> > > G.7713 and
> > >   why do we need this in place of a normative reference?
> > >
> > > > > > > - what is the purpose of this draft?
> > > Excellent question.
> > > > > > >   - is it after the fact documenting of requirements?
> > > If it is, why bother? Also, we already have the requirements
> > > (developed
> > > before the protocol) in G.8080 and G.7713.
> > >
> > > > > > >   - is it getting ITU-T documented requirements 
> in RFC form?
> > > This could be a reasonable goal, if this document is to be an info
> > > track requirements document characterizing G.8080 and G.7713 for
> > > IETF folks in the same way that RFC 3474 does for G.7713.2 and
> > > RFC 3475 does for G.7713.3. But it is hard to understand 
> why producing
> > > an IETF translation of the ITU-T question would be very 
> high priority
> > > when we already have an IETF translation of the answer, but
> > > fundamentally
> > > there would be no problem if this were the objective.
> > >
> > > > > > >   - is it extending ITU-T documented requirements?
> > > I don't think so. If it is, I hope we start with a liaison rather
> > > than trying to extend ITU-T requirements without talking to
> > > ITU-T first.
> > >
> > > > > > >   - is it contrdicting them?
> > > This is my biggest worry. I don't think we should start 
> the process
> > > over again and open the door that we come up with yet another
> > > protocol solution to address the same requirements. Vendors are
> > > already building to G.7713.2, G.7713.3 (and by extension, to
> > > RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT
> > > start a new work item with an objective to develop a new protocol
> > > solution to the same problem.
> > >
> > > > > > >   - is it meant to be used as communication to ITU?
> > > I haven't seen this proposed, but I think that if the goal is
> > > to capture ITU-T requirements in RFC form, it would be a good
> > > idea to ask ITU-T whether the proposed document accurately
> > > captures their requirements.
> > >
> > > /Steve
> > >
> > >
> > > John Drake wrote:
> > > >
> > > > Bert,
> > > >
> > > > I think so.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > > -----Original Message-----
> > > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > > Sent: Monday, May 12, 2003 1:27 PM
> > > > > To: John Drake; Kireeti Kompella; [email-masked]
> > > > > Subject: RE: ASON reqts
> > > > >
> > > > >
> > > > > I know that some people had issues with the way that ITU-T
> > > > > had defined the RSVP-TE extensions for ASON. In fact there
> > > > > was/is a claim that it is broken. So we removed the offending
> > > > > text from the RFC3474.
> > > > >
> > > > > The next thing we were going to do (as far as I understood it)
> > > > > is to document why we (or some of us in IETF) think that the
> > > > > ITU-T solution is broken, potentially with suggested fixes.
> > > > > That we would send to ITU-T SG15.
> > > > >
> > > > > Is this the first step of that process?
> > > > >
> > > > > Thanks,
> > > > > Bert
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: John Drake [mailto:[email-masked]]
> > > > > > Sent: maandag 12 mei 2003 22:24
> > > > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; 
> [email-masked]
> > > > > > Subject: RE: ASON reqts
> > > > > >
> > > > > >
> > > > > > Bert,
> > > > > >
> > > > > > I thought that the post 3474/3475 process started with a
> > > > > requirements
> > > > > > document.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > John
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > > > > Sent: Monday, May 12, 2003 1:14 PM
> > > > > > > To: Kireeti Kompella; [email-masked]
> > > > > > > Subject: RE: ASON reqts
> > > > > > >
> > > > > > >
> > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents
> > > > > > > that those 2 RFCs point to, then I wonder:
> > > > > > > - is there or do we see any conflict?
> > > > > > > - are we duplicating some work?
> > > > > > > - what is the purpose of this draft?
> > > > > > >   - is it after the fact documenting of requirements?
> > > > > > >   - is it getting ITU-T documented requirements 
> in RFC form?
> > > > > > >   - is it extending ITU-T documented requirements?
> > > > > > >   - is it contrdicting them?
> > > > > > >   - is it meant to be used as communication to ITU?
> > > > > > >
> > > > > > > Just wondering what is happening here.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Bert
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Kireeti Kompella [mailto:[email-masked]]
> > > > > > > > Sent: maandag 12 mei 2003 17:25
> > > > > > > > To: [email-masked]
> > > > > > > > Subject: Re: ASON reqts
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi All,
> > > > > > > >
> > > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > > > > > > >
> > > > > > > > > To take things one at a time, it would be 
> very useful to
> > > > > > > > read and comment
> > > > > > > > > on the ASON reqts draft, as this was deemed 
> tremendously
> > > > > > > > important, and
> > > > > > > > > a rich source of misunderstanding and cross-talk; and
> > > > > > > > coming to a common
> > > > > > > > > understanding over this should help get the 
> IETF and the
> > > > > > > ITU working
> > > > > > > > > together.
> > > > > > > >
> > > > > > > > I haven't seen many comments, so the assumption is
> > > > > either that no
> > > > > > > > one cares, or that folks have read it and have 
> no issues.
> > > > > > > >
> > > > > > > > I'd like to get a reading on whether this doc is
> > > ready to be a
> > > > > > > > CCAMP WG document.  Please respond (preferably publicly)
> > > > > > > with one of:
> > > > > > > >  - "I have read this document and it is ready 
> to be a CCAMP
> > > > > > > WG doc" OR
> > > > > > > >  - "I have read this document, and it isn't 
> ready to be a
> > > > > > > CCAMP doc".
> > > > > > > >
> > > > > > > > Note that if there aren't enough responses, the default
> > > > > > > assumption is
> > > > > > > > that the document is either not of interest or not
> > > ready, and in
> > > > > > > > either case will not become a CCAMP WG doc.  Note too
> > > > > > that this doc
> > > > > > > > is an attempt to bridge some gaps between the IETF and
> > > > > the ITU-T,
> > > > > > > > and as such is fairly important.  It would be
> > > useful to give an
> > > > > > > > update on its status at the interim T1X1 
> meeting in June.
> > > > > > > >
> > > > > > > > Please get your responses in by COB Friday May 16th.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Kireeti.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> 
> ============================================================
> The information contained in this message may be privileged 
> and confidential and protected from disclosure.  If the 
> reader of this message is not the intended recipient, or an 
> employee or agent responsible for delivering this message to 
> the intended recipient, you are hereby notified that any 
> reproduction, dissemination or distribution of this 
> communication is strictly prohibited. If you have received 
> this communication in error, please notify us immediately by 
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
> 

Envelope-to: [email-masked]
Delivery-date: Tue, 13 May 2003 19:45:49 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Jonathan Sadler" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ASON reqts
Date: Tue, 13 May 2003 15:44:59 -0400

> Currently, the document excludes a number of requirements specified in G.8080,
> and G.7713 that are handled by RFC 3474.  No information is provided in the
> document or on the CCAMP list why these were dropped.

Pointers please.
There was no intention to drop any requirement so please let us know what is
missing.
Thanks.

> I would also like to know why it is referencing outdated documents (ex.
> [IPO-ASON] was published in March 2002) when more recent
> requirements/architecture material is available.

Well, there is no reason not to reference this material at this stage. Indeed,
someone just asked for it to be referenced, I think.
With regard to other material, again please provide pointers and we will happily
read and reference is as appropriate.

This is what the review process is all about (and it is orthogonal to whether
the WG adopts the draft IMHO)

Cheers,
Adrian

Delivery-date: Tue, 13 May 2003 19:23:22 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 14:22:33 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Jonathan Sadler" <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: <[email-masked]>

Hi Jonathan,

We need specifics-
Deborah

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Tuesday, May 13, 2003 7:57 PM
To: Kireeti Kompella
Cc: [email-masked]
Subject: Re: ASON reqts

Kireeti -

"I have read this document, and it isn't ready to be a CCAMP doc".

Currently, the document excludes a number of requirements specified in =
G.8080,
and G.7713 that are handled by RFC 3474.  No information is provided in =
the
document or on the CCAMP list why these were dropped.

I would also like to know why it is referencing outdated documents (ex.
[IPO-ASON] was published in March 2002) when more recent
requirements/architecture material is available.

Jonathan Sadler

Kireeti Kompella wrote:

> Hi All,
>
> On Fri, 2 May 2003, Kireeti Kompella wrote:
>
> > To take things one at a time, it would be very useful to read and =
comment
> > on the ASON reqts draft, as this was deemed tremendously important, =
and
> > a rich source of misunderstanding and cross-talk; and coming to a =
common
> > understanding over this should help get the IETF and the ITU working
> > together.
>
> I haven't seen many comments, so the assumption is either that no
> one cares, or that folks have read it and have no issues.
>
> I'd like to get a reading on whether this doc is ready to be a
> CCAMP WG document.  Please respond (preferably publicly) with one of:
>  - "I have read this document and it is ready to be a CCAMP WG doc" OR
>  - "I have read this document, and it isn't ready to be a CCAMP doc".
>
> Note that if there aren't enough responses, the default assumption is
> that the document is either not of interest or not ready, and in
> either case will not become a CCAMP WG doc.  Note too that this doc
> is an attempt to bridge some gaps between the IETF and the ITU-T,
> and as such is fairly important.  It would be useful to give an
> update on its status at the interim T1X1 meeting in June.
>
> Please get your responses in by COB Friday May 16th.
>
> Thanks,
> Kireeti.

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

Thank you.
Tellabs
=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

Delivery-date: Tue, 13 May 2003 19:20:46 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 14:19:52 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Varma, Eve L (Eve)" <[email-masked]>, "John Drake" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: <[email-masked]>

The intention of gmpls-ason-reqs is not to repeat G8080. And it is not =
about G7713.2. It is to address GMPLS support of G8080. If it becomes a =
WG document, any/all comments are welcome. Individuals' participation =
will depend on company interests. We can not "require" anyone to =
participate. This is not a hobby for most of us;-)

This email is more appropriate as a private exchange - naming of =
individuals severely lacks in recognition of the many who contribute in =
the T1X1/ITU and the IETF work. As T1X1.5 chair/vice chair for many =
years, including the birth of ASON, I wish I could say, that I was too =
young too remember, but I was there, actually Malcolm could say he was =
too young;-). And I am not the primary player for T1X1.5 work, there are =
no primary players, it is a committee representing companies. One could =
ask, why were none of the IETF GMPLS experts asked to participate in the =
ITU work?

We are trying to progress an IETF draft on GMPLS support of ASON. I am a =
carrier interested in GMPLS. None of us are writing resumes. Let's =
progress with specific comments on the drafts.

Deborah

-----Original Message-----
From: Varma, Eve L (Eve) [mailto:[email-masked]]
Sent: Tuesday, May 13, 2003 1:30 PM
To: 'John Drake'; Wijnen, Bert (Bert)
Cc: [email-masked]'
Subject: RE: ASON reqts

Hi John,

If you want to work with the primary contributors to the development of =
G.8080, then it is essential you be engaged in conversations with Alan =
McGuire, George Newsome, Malcolm Betts, Mike Mayer at least (my =
apologies to other contributors of text that I have not acknowledged). =
In terms of RSVP extensions aspects, direct engagement with the editor =
of G.7713.2 (Dimitrios Penderakis) and the former editor of G.7713, who =
worked through early Feb. '03 on this document (Zhi-Wei Lin) would be =
advisable as well.  Your constructive interaction with these players =
would do much to improve the relationship.  Deborah's involvement is =
more recent, as I'm sure she would acknowledge.

With best regards,
Eve

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Tuesday, May 13, 2003 12:18 PM
To: John Drake; 'Wijnen, Bert (Bert)'
Cc: [email-masked]'
Subject: RE: ASON reqts

Bert,

Also, I don't know if you noticed but Deborah Brungard, who was a major
contributor to G.8080 (ASON), helped us out with the RSVP extensions I-D
(http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-as=
on-
00.txt).

So we really are trying to make the ITU/IETF working relationship =
better.

Thanks,

John=20

> -----Original Message-----
> From: John Drake=20
> Sent: Tuesday, May 13, 2003 9:09 AM
> To: 'Wijnen, Bert (Bert)'
> Cc: [email-masked]
> Subject: RE: ASON reqts
>=20
>=20
> Bert,
>=20
> We're discussing submitting the two drafts=20
> (http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp
> -gmpls-ason-reqts-00.txt,=20
> http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-
> rsvp-te-ason-00.txt) as contributions to the ITU meeting in=20
> Chicago next month.
>=20
> The intention is to work closely with T1X1 and ITU in order=20
> to get them a satisfactory GMPLS solution, but we still need=20
> to follow the IETF process for work done in the IETF.
>=20
> Thanks,
>=20
> John
>=20
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Tuesday, May 13, 2003 8:56 AM
> > To: John Drake
> > Cc: [email-masked]
> > Subject: RE: ASON reqts
> >=20
> >=20
> > >=20
> > >=20
> > http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chn
> > g-proc-00.txt.
> > > (It's the one you co-authored.)
> > >=20
> > Aha... OK, that doc still needs approval.
> > We have sort of agreed that we would test-run a document from MPLS
> > WG through the process to see how/if it works.
> >=20
> > But more to the point, that document is on how we control=20
> work brought
> > to the IETF. It does not control how we interact as decent=20
> > human beings
> > and decent organisations with our counterparts.
> >=20
> > The ASON specs (including how to do GMPLS for ASON) were done=20
> > by ITU-T.
> > So we cannot just assume that we need to take over. I do not believe
> > that tha above change-control-procedures are intended to specify
> > how we take away or steal or whatever-term-you-want-use work from
> > other organisations.
> >=20
> > That is why I suggested the decent communication path in my earlier
> > posting.
> >=20
> > Bert
> > > > -----Original Message-----
> > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > Sent: Tuesday, May 13, 2003 8:11 AM
> > > > To: John Drake
> > > > Cc: [email-masked]
> > > > Subject: RE: ASON reqts
> > > >=20
> > > >=20
> > > > >=20
> > > > > Bert,
> > > > >=20
> > > > > I thought that we had a process - the post RFC3474 process. =20
> > > >=20
> > > > I guess I must have missed that.=20
> > > > Where is that or what are you referring to?
> > > >=20
> > > > I also know that some of you do not believe we did send the ASON
> > > > people away... but for me that it what it boiled down to.
> > > > YMMV
> > > >=20
> > > > Bert
> > > >=20
> > >=20
> >=20
>=20

Delivery-date: Tue, 13 May 2003 19:07:23 +0000
Date: Tue, 13 May 2003 18:59:27 -0500
From: Jonathan Sadler <[email-masked]>
To: John Drake <[email-masked]>
CC: "'Stephen Trowbridge'" <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

John -

What does section 9.2 of RFC 3474 accomplish then?  (For those unaware, Sect.
9.2 is titled "Complete Separation of Call and Connection")

Jonathan Sadler

John Drake wrote:

> I think that the problem is that RFC 3474, in addition to its technical
> issues, doesn't address all of the ASON requirements.  For example, it does
> not address full call/connection separation.  So we're following the post
> 3474 procees of documenting the ASON requirements relevant to GMPLS
> signalling in order to have a common understanding of what problem is to be
> solved.
>
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Monday, May 12, 2003 2:27 PM
> > To: John Drake
> > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> > Subject: Re: ASON reqts
> >
> >
> > Bert & John,
> > I think this document has nothing to do with the issue Bert
> > mentioned. This was a protocol issue, not a requirements issue.
> > A decision was made to leave the message out of 3474 with the
> > belief that:
> > - The protocol works without it; and
> > - The presence of the message violates the protocol.
> > The appropriate next step here would be a liaison back to ITU-T
> > explaining what was done and why, and if the ITU-T agrees with
> > the reasoning, they can align their protocol document (in this
> > case, G.7713.2).
> >
> > Back to Bert's original questions:
> > > > > > - is there or do we see any conflict?
> > - As Zhi said, this is not (yet) fully aligned with ITU-T requirements
> >   and should not be advanced to a WG document until it is.
> > However, before
> >   we do, I think we need to understand why this is necessary
> > - see below.
> >
> > > > > > - are we duplicating some work?
> > - Almost certainly. If we take the kind of alignment with ITU-T
> >   requirements that Zhi mentions as a "gate" for progressing
> > this, then
> >   what is in this document that is different from G.8080 and
> > G.7713 and
> >   why do we need this in place of a normative reference?
> >
> > > > > > - what is the purpose of this draft?
> > Excellent question.
> > > > > >   - is it after the fact documenting of requirements?
> > If it is, why bother? Also, we already have the requirements
> > (developed
> > before the protocol) in G.8080 and G.7713.
> >
> > > > > >   - is it getting ITU-T documented requirements in RFC form?
> > This could be a reasonable goal, if this document is to be an info
> > track requirements document characterizing G.8080 and G.7713 for
> > IETF folks in the same way that RFC 3474 does for G.7713.2 and
> > RFC 3475 does for G.7713.3. But it is hard to understand why producing
> > an IETF translation of the ITU-T question would be very high priority
> > when we already have an IETF translation of the answer, but
> > fundamentally
> > there would be no problem if this were the objective.
> >
> > > > > >   - is it extending ITU-T documented requirements?
> > I don't think so. If it is, I hope we start with a liaison rather
> > than trying to extend ITU-T requirements without talking to
> > ITU-T first.
> >
> > > > > >   - is it contrdicting them?
> > This is my biggest worry. I don't think we should start the process
> > over again and open the door that we come up with yet another
> > protocol solution to address the same requirements. Vendors are
> > already building to G.7713.2, G.7713.3 (and by extension, to
> > RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT
> > start a new work item with an objective to develop a new protocol
> > solution to the same problem.
> >
> > > > > >   - is it meant to be used as communication to ITU?
> > I haven't seen this proposed, but I think that if the goal is
> > to capture ITU-T requirements in RFC form, it would be a good
> > idea to ask ITU-T whether the proposed document accurately
> > captures their requirements.
> >
> > /Steve
> >
> >
> > John Drake wrote:
> > >
> > > Bert,
> > >
> > > I think so.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > Sent: Monday, May 12, 2003 1:27 PM
> > > > To: John Drake; Kireeti Kompella; [email-masked]
> > > > Subject: RE: ASON reqts
> > > >
> > > >
> > > > I know that some people had issues with the way that ITU-T
> > > > had defined the RSVP-TE extensions for ASON. In fact there
> > > > was/is a claim that it is broken. So we removed the offending
> > > > text from the RFC3474.
> > > >
> > > > The next thing we were going to do (as far as I understood it)
> > > > is to document why we (or some of us in IETF) think that the
> > > > ITU-T solution is broken, potentially with suggested fixes.
> > > > That we would send to ITU-T SG15.
> > > >
> > > > Is this the first step of that process?
> > > >
> > > > Thanks,
> > > > Bert
> > > >
> > > > > -----Original Message-----
> > > > > From: John Drake [mailto:[email-masked]]
> > > > > Sent: maandag 12 mei 2003 22:24
> > > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> > > > > Subject: RE: ASON reqts
> > > > >
> > > > >
> > > > > Bert,
> > > > >
> > > > > I thought that the post 3474/3475 process started with a
> > > > requirements
> > > > > document.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > John
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > > > Sent: Monday, May 12, 2003 1:14 PM
> > > > > > To: Kireeti Kompella; [email-masked]
> > > > > > Subject: RE: ASON reqts
> > > > > >
> > > > > >
> > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents
> > > > > > that those 2 RFCs point to, then I wonder:
> > > > > > - is there or do we see any conflict?
> > > > > > - are we duplicating some work?
> > > > > > - what is the purpose of this draft?
> > > > > >   - is it after the fact documenting of requirements?
> > > > > >   - is it getting ITU-T documented requirements in RFC form?
> > > > > >   - is it extending ITU-T documented requirements?
> > > > > >   - is it contrdicting them?
> > > > > >   - is it meant to be used as communication to ITU?
> > > > > >
> > > > > > Just wondering what is happening here.
> > > > > >
> > > > > > Thanks,
> > > > > > Bert
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Kireeti Kompella [mailto:[email-masked]]
> > > > > > > Sent: maandag 12 mei 2003 17:25
> > > > > > > To: [email-masked]
> > > > > > > Subject: Re: ASON reqts
> > > > > > >
> > > > > > >
> > > > > > > Hi All,
> > > > > > >
> > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > > > > > >
> > > > > > > > To take things one at a time, it would be very useful to
> > > > > > > read and comment
> > > > > > > > on the ASON reqts draft, as this was deemed tremendously
> > > > > > > important, and
> > > > > > > > a rich source of misunderstanding and cross-talk; and
> > > > > > > coming to a common
> > > > > > > > understanding over this should help get the IETF and the
> > > > > > ITU working
> > > > > > > > together.
> > > > > > >
> > > > > > > I haven't seen many comments, so the assumption is
> > > > either that no
> > > > > > > one cares, or that folks have read it and have no issues.
> > > > > > >
> > > > > > > I'd like to get a reading on whether this doc is
> > ready to be a
> > > > > > > CCAMP WG document.  Please respond (preferably publicly)
> > > > > > with one of:
> > > > > > >  - "I have read this document and it is ready to be a CCAMP
> > > > > > WG doc" OR
> > > > > > >  - "I have read this document, and it isn't ready to be a
> > > > > > CCAMP doc".
> > > > > > >
> > > > > > > Note that if there aren't enough responses, the default
> > > > > > assumption is
> > > > > > > that the document is either not of interest or not
> > ready, and in
> > > > > > > either case will not become a CCAMP WG doc.  Note too
> > > > > that this doc
> > > > > > > is an attempt to bridge some gaps between the IETF and
> > > > the ITU-T,
> > > > > > > and as such is fairly important.  It would be
> > useful to give an
> > > > > > > update on its status at the interim T1X1 meeting in June.
> > > > > > >
> > > > > > > Please get your responses in by COB Friday May 16th.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Kireeti.
> > > > > > >
> > > > > >
> > > > >
> > > >
> >

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

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

Delivery-date: Tue, 13 May 2003 19:04:26 +0000
Date: Tue, 13 May 2003 18:56:56 -0500
From: Jonathan Sadler <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: ASON reqts

Kireeti -

"I have read this document, and it isn't ready to be a CCAMP doc".

Currently, the document excludes a number of requirements specified in G.8080,
and G.7713 that are handled by RFC 3474.  No information is provided in the
document or on the CCAMP list why these were dropped.

I would also like to know why it is referencing outdated documents (ex.
[IPO-ASON] was published in March 2002) when more recent
requirements/architecture material is available.

Jonathan Sadler

Kireeti Kompella wrote:

> Hi All,
>
> On Fri, 2 May 2003, Kireeti Kompella wrote:
>
> > To take things one at a time, it would be very useful to read and comment
> > on the ASON reqts draft, as this was deemed tremendously important, and
> > a rich source of misunderstanding and cross-talk; and coming to a common
> > understanding over this should help get the IETF and the ITU working
> > together.
>
> I haven't seen many comments, so the assumption is either that no
> one cares, or that folks have read it and have no issues.
>
> I'd like to get a reading on whether this doc is ready to be a
> CCAMP WG document.  Please respond (preferably publicly) with one of:
>  - "I have read this document and it is ready to be a CCAMP WG doc" OR
>  - "I have read this document, and it isn't ready to be a CCAMP doc".
>
> Note that if there aren't enough responses, the default assumption is
> that the document is either not of interest or not ready, and in
> either case will not become a CCAMP WG doc.  Note too that this doc
> is an attempt to bridge some gaps between the IETF and the ITU-T,
> and as such is fairly important.  It would be useful to give an
> update on its status at the interim T1X1 meeting in June.
>
> Please get your responses in by COB Friday May 16th.
>
> Thanks,
> Kireeti.

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

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

Delivery-date: Tue, 13 May 2003 17:32:37 +0000
From: John Drake <[email-masked]>
To: "'Varma, Eve L (Eve)'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 10:32:12 -0700

Great, thanks

> -----Original Message-----
> From: Varma, Eve L (Eve) [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 10:30 AM
> To: John Drake; Wijnen, Bert (Bert)
> Cc: [email-masked]'
> Subject: RE: ASON reqts
> 
> 
> Hi John,
> 
> If you want to work with the primary contributors to the 
> development of G.8080, then it is essential you be engaged in 
> conversations with Alan McGuire, George Newsome, Malcolm 
> Betts, Mike Mayer at least (my apologies to other 
> contributors of text that I have not acknowledged). In terms 
> of RSVP extensions aspects, direct engagement with the editor 
> of G.7713.2 (Dimitrios Penderakis) and the former editor of 
> G.7713, who worked through early Feb. '03 on this document 
> (Zhi-Wei Lin) would be advisable as well.  Your constructive 
> interaction with these players would do much to improve the 
> relationship.  Deborah's involvement is more recent, as I'm 
> sure she would acknowledge.
> 
> With best regards,
> Eve
> 
> 
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 12:18 PM
> To: John Drake; 'Wijnen, Bert (Bert)'
> Cc: [email-masked]'
> Subject: RE: ASON reqts
> 
> 
> Bert,
> 
> Also, I don't know if you noticed but Deborah Brungard, who 
> was a major
> contributor to G.8080 (ASON), helped us out with the RSVP 
> extensions I-D
> (http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls
> -rsvp-te-ason-
> 00.txt).
> 
> So we really are trying to make the ITU/IETF working 
> relationship better.
> 
> Thanks,
> 
> John 
> 
> > -----Original Message-----
> > From: John Drake 
> > Sent: Tuesday, May 13, 2003 9:09 AM
> > To: 'Wijnen, Bert (Bert)'
> > Cc: [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > Bert,
> > 
> > We're discussing submitting the two drafts 
> > (http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp
> > -gmpls-ason-reqts-00.txt, 
> > http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-
> > rsvp-te-ason-00.txt) as contributions to the ITU meeting in 
> > Chicago next month.
> > 
> > The intention is to work closely with T1X1 and ITU in order 
> > to get them a satisfactory GMPLS solution, but we still need 
> > to follow the IETF process for work done in the IETF.
> > 
> > Thanks,
> > 
> > John
> > 
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > Sent: Tuesday, May 13, 2003 8:56 AM
> > > To: John Drake
> > > Cc: [email-masked]
> > > Subject: RE: ASON reqts
> > > 
> > > 
> > > > 
> > > > 
> > > http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chn
> > > g-proc-00.txt.
> > > > (It's the one you co-authored.)
> > > > 
> > > Aha... OK, that doc still needs approval.
> > > We have sort of agreed that we would test-run a document from MPLS
> > > WG through the process to see how/if it works.
> > > 
> > > But more to the point, that document is on how we control 
> > work brought
> > > to the IETF. It does not control how we interact as decent 
> > > human beings
> > > and decent organisations with our counterparts.
> > > 
> > > The ASON specs (including how to do GMPLS for ASON) were done 
> > > by ITU-T.
> > > So we cannot just assume that we need to take over. I do 
> not believe
> > > that tha above change-control-procedures are intended to specify
> > > how we take away or steal or whatever-term-you-want-use work from
> > > other organisations.
> > > 
> > > That is why I suggested the decent communication path in 
> my earlier
> > > posting.
> > > 
> > > Bert
> > > > > -----Original Message-----
> > > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > > Sent: Tuesday, May 13, 2003 8:11 AM
> > > > > To: John Drake
> > > > > Cc: [email-masked]
> > > > > Subject: RE: ASON reqts
> > > > > 
> > > > > 
> > > > > > 
> > > > > > Bert,
> > > > > > 
> > > > > > I thought that we had a process - the post RFC3474 
> process.  
> > > > > 
> > > > > I guess I must have missed that. 
> > > > > Where is that or what are you referring to?
> > > > > 
> > > > > I also know that some of you do not believe we did 
> send the ASON
> > > > > people away... but for me that it what it boiled down to.
> > > > > YMMV
> > > > > 
> > > > > Bert
> > > > > 
> > > > 
> > > 
> > 
> 

Delivery-date: Tue, 13 May 2003 17:30:57 +0000
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'John Drake'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 13:30:02 -0400

Hi John,

If you want to work with the primary contributors to the development of G.8080, then it is essential you be engaged in conversations with Alan McGuire, George Newsome, Malcolm Betts, Mike Mayer at least (my apologies to other contributors of text that I have not acknowledged). In terms of RSVP extensions aspects, direct engagement with the editor of G.7713.2 (Dimitrios Penderakis) and the former editor of G.7713, who worked through early Feb. '03 on this document (Zhi-Wei Lin) would be advisable as well.  Your constructive interaction with these players would do much to improve the relationship.  Deborah's involvement is more recent, as I'm sure she would acknowledge.

With best regards,
Eve

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Tuesday, May 13, 2003 12:18 PM
To: John Drake; 'Wijnen, Bert (Bert)'
Cc: [email-masked]'
Subject: RE: ASON reqts

Bert,

Also, I don't know if you noticed but Deborah Brungard, who was a major
contributor to G.8080 (ASON), helped us out with the RSVP extensions I-D
(http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-ason-
00.txt).

So we really are trying to make the ITU/IETF working relationship better.

Thanks,

John 

> -----Original Message-----
> From: John Drake 
> Sent: Tuesday, May 13, 2003 9:09 AM
> To: 'Wijnen, Bert (Bert)'
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Bert,
> 
> We're discussing submitting the two drafts 
> (http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp
> -gmpls-ason-reqts-00.txt, 
> http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-
> rsvp-te-ason-00.txt) as contributions to the ITU meeting in 
> Chicago next month.
> 
> The intention is to work closely with T1X1 and ITU in order 
> to get them a satisfactory GMPLS solution, but we still need 
> to follow the IETF process for work done in the IETF.
> 
> Thanks,
> 
> John
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Tuesday, May 13, 2003 8:56 AM
> > To: John Drake
> > Cc: [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > > 
> > > 
> > http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chn
> > g-proc-00.txt.
> > > (It's the one you co-authored.)
> > > 
> > Aha... OK, that doc still needs approval.
> > We have sort of agreed that we would test-run a document from MPLS
> > WG through the process to see how/if it works.
> > 
> > But more to the point, that document is on how we control 
> work brought
> > to the IETF. It does not control how we interact as decent 
> > human beings
> > and decent organisations with our counterparts.
> > 
> > The ASON specs (including how to do GMPLS for ASON) were done 
> > by ITU-T.
> > So we cannot just assume that we need to take over. I do not believe
> > that tha above change-control-procedures are intended to specify
> > how we take away or steal or whatever-term-you-want-use work from
> > other organisations.
> > 
> > That is why I suggested the decent communication path in my earlier
> > posting.
> > 
> > Bert
> > > > -----Original Message-----
> > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > Sent: Tuesday, May 13, 2003 8:11 AM
> > > > To: John Drake
> > > > Cc: [email-masked]
> > > > Subject: RE: ASON reqts
> > > > 
> > > > 
> > > > > 
> > > > > Bert,
> > > > > 
> > > > > I thought that we had a process - the post RFC3474 process.  
> > > > 
> > > > I guess I must have missed that. 
> > > > Where is that or what are you referring to?
> > > > 
> > > > I also know that some of you do not believe we did send the ASON
> > > > people away... but for me that it what it boiled down to.
> > > > YMMV
> > > > 
> > > > Bert
> > > > 
> > > 
> > 
> 

Delivery-date: Tue, 13 May 2003 16:59:21 +0000
From: Ayan Banerjee <[email-masked]>
To: [email-masked]
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation
Date: Tue, 13 May 2003 09:58:17 -0700

Kireeti,

  Fine, send it as is.

-Ayan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kireeti Kompella
> Sent: Sunday, May 11, 2003 11:23 PM
> To: [email-masked]
> Cc: [email-masked]; Wijnen, Bert (Bert); Ron Bonica 
> (E-mail); [email-masked]
> Subject: RE: Proposed response to the Liaison Statement on 
> LMP Link Verifi cation
> 
> 
> Hi All,
> 
> On Tue, 29 Apr 2003, Kireeti Kompella wrote:
> 
> > I will formulate a liaison statement in reply to T1X1 regarding 
> > draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list.
> 
> Sorry for the tardy follow-up.  Here is the proposed response.
> 
> Please send your replies to the list (if you wish to reply 
> privately, include the Liaison Coordinator and the ADs in your reply).
> 
> Ideally, your reply should say one of:
>  - "Fine, send it as is"; OR
>  - "Please make the following changes", with _specific text_; OR
>  - "Do not send this response".
> 
> Please respond by COB Friday, May 16th.
> 
> Kireeti. 
> ==============================================================
> =========
> 
> Dear Mr. Biholar,
> 
> Regarding the following liaison:
> 
> TITLE: Liaison from T1X1 to IETF ccamp regarding
> 	draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt
> TO: IETF ccamp Working Group
> CC: ITU-T Q.14/15 (for information)
> SOURCE*: T1X1
> FOR: Action
> DEADLINE: 9 June 2003
> PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic 
> Interconnection
> 
> We thank the T1X1 and the ITU-T for their review and the 
> incorporation of the LMP Test procedure into G.7714.1.
> 
> Based on information contained in the ITU and T1X1 liaison, 
> as well as subsequent e-mail exchanges on the CCAMP mailing 
> list, and in order to ensure proper interoperability in 
> legacy SDH/SONET networks as well as networks in which 
> G.7714.1 is deployed, it will be recommended by the editors 
> to the CCAMP community to support only the Jx trace 
> correlation procedure and not the in-band Jx procedure.  
> Pending agreement, the draft will be updated.
> 
> See inline for more detailed responses to specific points.
> 
> > Context of Application Space
> 
> <snip>
> 
> > It is currently our understanding that the use case
> > scenario for which this procedure is applied encompasses
> > both transport plane connectivity verification as well as 
> correlation 
> > of these entities with the control plane. ITU-T G.7714.1 is 
> focused on 
> > discovering the transport plane link connection end point 
> > relationships and verifying their connectivity.
> > This Recommendation defines two procedures for performing
> > the connectivity verification function, one of which
> > utilizes either the Jx or the DCC bytes of the server
> > signal (termed "in-service"). The other approach in
> > G.7714.1, termed as "out of service", corresponds to
> > inserting a test signal in the payload of the server
> > signal. Based on an analysis of the data link state
> > definitions in draft-ietf-ccamp-lmp-08.txt, we understand
> > that the approach defined in the LMP test for physical
> > connectivity occurs in the context of the "out of service"
> > state (as described in G.7714.1).
> >
> > Please confirm this.
> 
> The subject document uses the Jx or DCC bytes to perform the 
> LMP Test procedure, but the The LMP Test procedure is done as 
> part of GMPLS link intialization, prior to the link being 
> available to carry user traffic.
> 
> > Usage of Jx Bytes
> >
> > In defining the Jx bytes within G.7714.1, the following
> > was taken into account:
> > 1. One consideration involved the case where the Discovery Agent is 
> > located in an external system, and an external interface is used by 
> > the Network Element to provision and receive the Trail 
> Trace message. 
> > As an existing text- oriented Man-Machine Language, such as 
> TL1, may 
> > be reused to provide this interface, it was decided that the
> > discovery message be limited to printable characters.
> > Specifically, the TTI characters should be limited to
> > printable characters as per T.50 with trailing NULLs or
> > SPACEs. Use of arbitrary bit patterns in the lower 7 bits
> > of each byte could prematurely terminate the pattern or
> > trigger fault notification for certain hardware or
> > software implementations. The strategy chosen in G.7714.1
> > avoids the danger by limiting the information content of
> > each byte to 6 bits (84 bits total) and uses a base 64
> > coding according to RFC2045 to place the information in
> > the available bits.
> 
> The LMP test procedure described in the subject document 
> defines two usages of the Jx bytes.  The first is termed the 
> 'trace correlation transport mechanism' and it treats the Jx 
> bytes as an opaque bit stream.
> 
> This usage is completely consistent with the above.  GMPLS 
> identifiers are typically 32 bit numbers and as such are not 
> printable characters.  In networks that do not require that 
> the Jx bytes be printable, it is also possible to carry the 
> GMPLS identifiers directly in the Jx bytes.  This is termed 
> the 'Jx transport mechanism'.
> 
> > 2. Another consideration involved providing a means for 
> distinguishing 
> > this use of the Jx bytes from the traditional use for Trail Trace 
> > identifiers in new equipments. As a result, G.7714.1 includes a
> > distinguishing character ("+") as the first non-CRC byte
> > that will never appear as the first character of a TTI.
> > This requires modification of the trail termination
> > functions to prevent the raising of TTI mismatch
> > alarms during the connectivity verification process.
> 
> The selection of which LMP transport mechanism use in the LMP 
> Test procedure for a given link as well as the time at which 
> the Jx bytes are to be used for the LMP Test procedure is 
> under control of the GMPLS nodes at either end of the link, 
> so it is well understood by those nodes.  It is our 
> understanding, per G.806 section 6.1, that the LMP Test 
> procedure would be performed when the link is in the NMON 
> (not monitored state), and therefore intermediate SDH/SONET 
> equipment would not be performing non-intrusive monitoring.
> 
> > While the context for testing the transport plane connectivity is 
> > different between the two documents, they both use the Jx 
> bytes of the 
> > server signal, and we invite the IETF to determine the 
> appropriateness 
> > of the above aspects in their test signal definitions.
> 
> The trace correlation transport mechanism is completely 
> consistent with this.  The JX transport mechanism requires 
> additional identifiers (i.e., the Verify ID).
> 
> > Even if these considerations are not relevant to this 
> context, it will 
> > be necessary to augment G.783 equipment functions to recognize this 
> > new usage of Jx messages.
> 
> We would be happy to provide assistance to T1X1/ITU-T in 
> augmenting G.783 equipment functions to recognize the 
> additional capability for supporting GMPLS networking elements.
> 
> > Required Updates to SDH Equipment Specifications
> >
> > SDH equipment specifications as they currently exist 
> reflect the usage 
> > of the Jx bytes prior to the development of G.7714.1. ITU-T Study 
> > Group 15 has as a work item to revise these equipment functions to 
> > include support for these new functions. Specifically, this will 
> > involve updates to trail termination functions to generate and
> > receive the new messages and to avoid unnecessary alarms in
> > the case where the new messages are received.  In addition,
> > non-intrusive monitoring functions will need to be revised
> > so that unnecessary alarms are not raised when the
> > messages are observed en-route.  Whether or not there is
> > further alignment between the message formats used in
> > G.7714.1 and the subject draft, the new functions to
> > support the subject draft will also need to be reflected
> > in the atomic functions in G.783.  The sending and
> > receiving of these messages can be reflected in the trail
> > termination functions in a similar way to what we plan to
> > do for support of G.7714.1 functions.
> 
> We would be happy to provide assistance to T1X1/ITU-T in 
> augmenting G.783 equipment functions to recognize the 
> additional capability for supporting GMPLS networking elements.
> 
> > Terminology Differences
> 
> <snip>
> 
> > Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1,
> > the "up/free (in-service)" data link state appears to 
> correspond with 
> > what G.7714.1 refers to as "out-of- service".  This difference in 
> > terminology has resulted in different interpretations of 
> the context.  
> > Explaining the scenarios further in the lmp test document would be
> > beneficial in establishing a translation between the
> > differing uses of the same terms.  Within ITU-T, work is
> > being initiated of draft Rec. G.fame, Framework for ASON
> > Management, where control plane/management plane
> > interactions will be addressed.
> 
> We agree that terminology differences between IETF and ITU-T 
> wrt GMPLS have been confusing.  There is an ongoing effort 
> within CCAMP to work together with T1X1/ITU-T on bridging the 
> terminology gaps.  For example, there is a new Internet draft
> (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered 
> in CCAMP to do this mapping for LMP.
> 
> > Further Study Items
> >
> > Following are some areas where further contributions are
> > requested:
> > 1.     For SDH equipment functions in G.783, it needs to
> > be understood whether the application of the lmp test
> > message requires revision of NIM (non-intrusive
> > monitoring) functions.  The reason for this is that the
> > test procedure is initiated between control entities at
> > the end-points of the trail, and intermediate points are
> > not necessarily aware that the test is taking place.  For 
> G.7714.1, it 
> > was felt important for any termination or NIM function to easily 
> > distinguish between the various uses of the Jx bytes.  It may be 
> > necessary for the subject draft to use a similarly easily 
> recognizable 
> > format.  If no revision to NIM functions is required for 
> the context 
> > of this draft, the architecture of the context for this
> > application (demonstrating why the NIM functions are not
> > required) should be reflected in G.803 and/or G.807/G.8080.
> 
> It is our understanding, per G.806 section 6.1, that
> the LMP Test procedure would be performed when the link is in 
> the NMON (not monitored state), and  therefore intermediate 
> SDH/SONET equipment would not be performing non-intrusive 
> monitoring. As described, the trace correlation procedure use 
> of Jx bytes is consistent with the current standards.
> 
> > 2.Determination of whether it would be possible to use the 
> identical 
> > message formats in the subject draft as in G.7714.1 for the 
> > connectivity verification function.
> 
> The trace correlation transport mechanism is completely 
> consistent with this.  The Jx transport mechanism requires 
> additional identifiers (i.e., the Verify ID).
> 
> > 3.Determination of whether it would be possible to use the same 
> > overall structure (distinguishing character, 4 bit message type, 80 
> > bit message body) if a different message format or 
> information content 
> > is required.
> 
> This is certainly possible (not applicable for the trace 
> correlation procedure).
> 
> > 4.Work is needed to clarify under what
> > configurations/states (for example: no VC-n signals
> > carrying client traffic) the lmp test message is
> > applicable over J0.  If the signal can be framed and J0
> > can be recovered, the Regenerator Section is considered
> > as "in service" from a transport plane perspective.  So unlike the 
> > J1/J2 case, the application of the lmp test message at the 
> Regenerator 
> > Section does not occur in an "out of service" state (from a 
> transport 
> > plane perspective).
> 
> Section 6.1 of G.806 refers to a "termination function part 
> of a trail, which is in the process of set-up" as in the NMON 
> state. LMP link verification is based on pre-service testing. 
>  Please let us know if we can be of any assistance in 
> updating the appropriate Recommendations to support the GMPLS 
> network element LMP capability. This is not applicable for 
> the trace correlation procedure.
> 
> > 5. Clarification of the usage of transport and control
> > names for transport resources in the subject draft, as described in 
> > G.8080 Amendment
> 
> The trace correlation transport mechanism supports a 
> separation of the transport and control plane identifiers.
> 
> > 6. Consideration of the ANSI 64-byte J1.
> 
> This was mistakenly deleted from the latest version of the 
> draft. This will be included in the next version.
> 
> Sincerely,
> Kireeti Kompella and Ron Bonica,
> Chairs of the CCAMP WG/IETF.
> 

Delivery-date: Tue, 13 May 2003 16:40:42 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 11:39:19 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Bert,

Can you provide clarification on your email?

- the January ASON email exchange and the previous ITU-T liaisons =
clearly identified RFC-3471 and RFC-3473 lacked ASON support. The two =
ason drafts submitted are to initiate this work.
- majority of the email supports the reqs draft becoming a WG document. =
And hopefully, those concerned will also support as WG document based on =
the understanding a WG doc is a work in progress as posted by one email:
> There are a few issues that I don't quite understand and/or need
> clarification on, but the current vote is WG acceptance, not =
last-call.
> I have no issues with it that would keep it out from the WG.

Most of the email is on clarifying G7713.2 and the rsvp-te-ason draft. =
This draft addresses a totally different application/solution than =
G7713.2. The rsvp-te-ason draft covers the necessary extensions to =
RFC-3473 to support ASON for a GMPLS network. The difference of this =
draft and G7713.2 is that this draft is backward and forward compatible =
for GMPLS networks; i.e. transit nodes (ITU term: Internal Protocol =
Controller (I-PC)) do not need to be updated.  G7713.2 is an E-NNI which =
is using GMPLS but it is not based on GMPLS e.g. G7713.2 does not =
provide call and connection functional separation because it was not =
based on use with an RFC-3473 network. Eve's mail clarifies this =
regarding the domain definitions. If the draft is confusing in this =
regard, we can work on the wording.

The draft is on extending RFC-3473 to support ASON. If IETF does not =
extend RFC-3473, then GMPLS will not support ASON. This work is totally =
independent of the existence of G7713.2. As we discuss the draft, we can =
clarify if this is confusing.

Deborah

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Tuesday, May 13, 2003 10:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: ASON reqts

AD-hat on.

Bart writes:
>=20
>=20
> Stephen,
>=20
> I think the point was rather to go back to
> just a single GMPLS spec instead of two (let alone three) variants...
>=20
If that is the case, and if we want to do that in IETF CCAMP=20
(not sure it is part of the current CCAMP charter),
then it seems to me that we (CCAMP) should excercise these steps:

- send some liason to ITU-T SG 15 to explain that we found that
  there seems to be a GMPLS (for IETF) and a GMPLS-ASON standard
- that we think that this is NOT goodness, and that we regret that
  we did send the ASON people away a few years back and did not
  closely follow their work in ITU
- that we now believe that we should have worked better together,
- that we would like to explore ways to try and mrege the two
  solution back into one common solution

And then await the response and hope ITU will agree and then see
how the work can be organized.

>=20
> Bart
>=20
Bert

Delivery-date: Tue, 13 May 2003 16:35:23 +0000
Date: Tue, 13 May 2003 18:34:23 +0200
From: Dieter Beller <[email-masked]>
Organization: Alcatel SEL AG, OND Stuttgart, Germany
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation

Kireeti and all,

Fine, send it as is

Dieter

Kireeti Kompella wrote:

> Hi All,
> 
> On Tue, 29 Apr 2003, Kireeti Kompella wrote:
> 
> 
>>I will formulate a liaison statement in reply to T1X1 regarding
>>draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list.
> 
> 
> Sorry for the tardy follow-up.  Here is the proposed response.
> 
> Please send your replies to the list (if you wish to reply privately,
> include the Liaison Coordinator and the ADs in your reply).
> 
> Ideally, your reply should say one of:
>  - "Fine, send it as is"; OR
>  - "Please make the following changes", with _specific text_; OR
>  - "Do not send this response".
> 
> Please respond by COB Friday, May 16th.
> 
> Kireeti.
> =======================================================================
> 
> Dear Mr. Biholar,
> 
> Regarding the following liaison:
> 
> TITLE: Liaison from T1X1 to IETF ccamp regarding
> 	draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt
> TO: IETF ccamp Working Group
> CC: ITU-T Q.14/15 (for information)
> SOURCE*: T1X1
> FOR: Action
> DEADLINE: 9 June 2003
> PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic Interconnection
> 
> We thank the T1X1 and the ITU-T for their review and the incorporation
> of the LMP Test procedure into G.7714.1.
> 
> Based on information contained in the ITU and T1X1 liaison, as well as
> subsequent e-mail exchanges on the CCAMP mailing list, and in order to
> ensure proper interoperability in legacy SDH/SONET networks as well as
> networks in which G.7714.1 is deployed, it will be recommended by the
> editors to the CCAMP community to support only the Jx trace correlation
> procedure and not the in-band Jx procedure.  Pending agreement, the
> draft will be updated.
> 
> See inline for more detailed responses to specific points.
> 
> 
>>Context of Application Space
> 
> 
> <snip>
> 
>>It is currently our understanding that the use case
>>scenario for which this procedure is applied encompasses
>>both transport plane connectivity verification as well as
>>correlation of these entities with the control plane.
>>ITU-T G.7714.1 is focused on discovering the transport
>>plane link connection end point relationships and
>>verifying their connectivity.
>>This Recommendation defines two procedures for performing
>>the connectivity verification function, one of which
>>utilizes either the Jx or the DCC bytes of the server
>>signal (termed "in-service"). The other approach in
>>G.7714.1, termed as "out of service", corresponds to
>>inserting a test signal in the payload of the server
>>signal. Based on an analysis of the data link state
>>definitions in draft-ietf-ccamp-lmp-08.txt, we understand
>>that the approach defined in the LMP test for physical
>>connectivity occurs in the context of the "out of service"
>>state (as described in G.7714.1).
>>
>>Please confirm this.
> 
> 
> The subject document uses the Jx or DCC bytes to perform the LMP
> Test procedure, but the The LMP Test procedure is done as part of
> GMPLS link intialization, prior to the link being available to
> carry user traffic.
> 
> 
>>Usage of Jx Bytes
>>
>>In defining the Jx bytes within G.7714.1, the following
>>was taken into account:
>>1. One consideration involved the case where the Discovery
>>Agent is located in an external system, and an external
>>interface is used by the Network Element to provision and
>>receive the Trail Trace message. As an existing text-
>>oriented Man-Machine Language, such as TL1, may be reused
>>to provide this interface, it was decided that the
>>discovery message be limited to printable characters.
>>Specifically, the TTI characters should be limited to
>>printable characters as per T.50 with trailing NULLs or
>>SPACEs. Use of arbitrary bit patterns in the lower 7 bits
>>of each byte could prematurely terminate the pattern or
>>trigger fault notification for certain hardware or
>>software implementations. The strategy chosen in G.7714.1
>>avoids the danger by limiting the information content of
>>each byte to 6 bits (84 bits total) and uses a base 64
>>coding according to RFC2045 to place the information in
>>the available bits.
> 
> 
> The LMP test procedure described in the subject document defines
> two usages of the Jx bytes.  The first is termed the 'trace
> correlation transport mechanism' and it treats the Jx bytes as
> an opaque bit stream.
> 
> This usage is completely consistent with the above.  GMPLS
> identifiers are typically 32 bit numbers and as such are not
> printable characters.  In networks that do not require that the
> Jx bytes be printable, it is also possible to carry the GMPLS
> identifiers directly in the Jx bytes.  This is termed the 'Jx
> transport mechanism'.
> 
> 
>>2. Another consideration involved providing a means for
>>distinguishing this use of the Jx bytes from the
>>traditional use for Trail Trace identifiers in new
>>equipments. As a result, G.7714.1 includes a
>>distinguishing character ("+") as the first non-CRC byte
>>that will never appear as the first character of a TTI.
>>This requires modification of the trail termination
>>functions to prevent the raising of TTI mismatch
>>alarms during the connectivity verification process.
> 
> 
> The selection of which LMP transport mechanism use in the LMP Test
> procedure for a given link as well as the time at which the Jx
> bytes are to be used for the LMP Test procedure is under control of
> the GMPLS nodes at either end of the link, so it is well understood
> by those nodes.  It is our understanding, per G.806 section 6.1,
> that the LMP Test procedure would be performed when the link is in
> the NMON (not monitored state), and therefore intermediate SDH/SONET
> equipment would not be performing non-intrusive monitoring.
> 
> 
>>While the context for testing the transport plane
>>connectivity is different between the two documents, they
>>both use the Jx bytes of the server signal, and we invite
>>the IETF to determine the appropriateness of the above
>>aspects in their test signal definitions.
> 
> 
> The trace correlation transport mechanism is completely consistent
> with this.  The JX transport mechanism requires additional
> identifiers (i.e., the Verify ID).
> 
> 
>>Even if these considerations are not relevant to this
>>context, it will be necessary to augment G.783 equipment
>>functions to recognize this new usage of Jx messages.
> 
> 
> We would be happy to provide assistance to T1X1/ITU-T in augmenting
> G.783 equipment functions to recognize the additional capability
> for supporting GMPLS networking elements.
> 
> 
>>Required Updates to SDH Equipment Specifications
>>
>>SDH equipment specifications as they currently exist reflect
>>the usage of the Jx bytes prior to the development of
>>G.7714.1. ITU-T Study Group 15 has as a work item to
>>revise these equipment functions to include support for
>>these new functions. Specifically, this will involve
>>updates to trail termination functions to generate and
>>receive the new messages and to avoid unnecessary alarms in
>>the case where the new messages are received.  In addition,
>>non-intrusive monitoring functions will need to be revised
>>so that unnecessary alarms are not raised when the
>>messages are observed en-route.  Whether or not there is
>>further alignment between the message formats used in
>>G.7714.1 and the subject draft, the new functions to
>>support the subject draft will also need to be reflected
>>in the atomic functions in G.783.  The sending and
>>receiving of these messages can be reflected in the trail
>>termination functions in a similar way to what we plan to
>>do for support of G.7714.1 functions.
> 
> 
> We would be happy to provide assistance to T1X1/ITU-T in augmenting
> G.783 equipment functions to recognize the additional capability
> for supporting GMPLS networking elements.
> 
> 
>>Terminology Differences
> 
> 
> <snip>
> 
>>Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1,
>>the "up/free (in-service)" data link state appears to
>>correspond with what G.7714.1 refers to as "out-of-
>>service".  This difference in terminology has resulted in
>>different interpretations of the context.  Explaining the
>>scenarios further in the lmp test document would be
>>beneficial in establishing a translation between the
>>differing uses of the same terms.  Within ITU-T, work is
>>being initiated of draft Rec. G.fame, Framework for ASON
>>Management, where control plane/management plane
>>interactions will be addressed.
> 
> 
> We agree that terminology differences between IETF and ITU-T wrt
> GMPLS have been confusing.  There is an ongoing effort within
> CCAMP to work together with T1X1/ITU-T on bridging the terminology
> gaps.  For example, there is a new Internet draft
> (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in
> CCAMP to do this mapping for LMP.
> 
> 
>>Further Study Items
>>
>>Following are some areas where further contributions are
>>requested:
>>1.     For SDH equipment functions in G.783, it needs to
>>be understood whether the application of the lmp test
>>message requires revision of NIM (non-intrusive
>>monitoring) functions.  The reason for this is that the
>>test procedure is initiated between control entities at
>>the end-points of the trail, and intermediate points are
>>not necessarily aware that the test is taking place.  For
>>G.7714.1, it was felt important for any termination or NIM
>>function to easily distinguish between the various uses of
>>the Jx bytes.  It may be necessary for the subject draft
>>to use a similarly easily recognizable format.  If no
>>revision to NIM functions is required for the context of
>>this draft, the architecture of the context for this
>>application (demonstrating why the NIM functions are not
>>required) should be reflected in G.803 and/or G.807/G.8080.
> 
> 
> It is our understanding, per G.806 section 6.1, that
> the LMP Test procedure would be performed when the link is in the
> NMON (not monitored state), and  therefore intermediate SDH/SONET
> equipment would not be performing non-intrusive monitoring.
> As described, the trace correlation procedure use of Jx bytes is
> consistent with the current standards.
> 
> 
>>2.Determination of whether it would be possible to use the
>>identical message formats in the subject draft as in
>>G.7714.1 for the connectivity verification function.
> 
> 
> The trace correlation transport mechanism is completely consistent
> with this.  The Jx transport mechanism requires additional
> identifiers (i.e., the Verify ID).
> 
> 
>>3.Determination of whether it would be possible to use the
>>same overall structure (distinguishing character, 4 bit
>>message type, 80 bit message body) if a different message
>>format or information content is required.
> 
> 
> This is certainly possible (not applicable for the trace correlation
> procedure).
> 
> 
>>4.Work is needed to clarify under what
>>configurations/states (for example: no VC-n signals
>>carrying client traffic) the lmp test message is
>>applicable over J0.  If the signal can be framed and J0
>>can be recovered, the Regenerator Section is considered
>>as "in service" from a transport plane perspective.  So
>>unlike the J1/J2 case, the application of the lmp test
>>message at the Regenerator Section does not occur in an
>>"out of service" state (from a transport plane
>>perspective).
> 
> 
> Section 6.1 of G.806 refers to a "termination function part of a
> trail, which is in the process of set-up" as in the NMON state.
> LMP link verification is based on pre-service testing.  Please let
> us know if we can be of any assistance in updating the appropriate
> Recommendations to support the GMPLS network element LMP capability.
> This is not applicable for the trace correlation procedure.
> 
> 
>>5. Clarification of the usage of transport and control
>>names for transport resources in the subject draft, as
>>described in G.8080 Amendment
> 
> 
> The trace correlation transport mechanism supports a separation of
> the transport and control plane identifiers.
> 
> 
>>6. Consideration of the ANSI 64-byte J1.
> 
> 
> This was mistakenly deleted from the latest version of the draft.
> This will be included in the next version.
> 
> Sincerely,
> Kireeti Kompella and Ron Bonica,
> Chairs of the CCAMP WG/IETF.
> 

Delivery-date: Tue, 13 May 2003 16:31:56 +0000
Date: Tue, 13 May 2003 18:30:53 +0200
From: Dieter Beller <[email-masked]>
Organization: Alcatel SEL AG, OND Stuttgart, Germany
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Proposed change to LMP Link Verification draft

Kireeti and all,

I agree with the proposed change.

Dieter

Kireeti Kompella wrote:

> Hi All,
> 
> | Based on information contained in the ITU and T1X1 liaison, as well as
> | subsequent e-mail exchanges on the CCAMP mailing list, and in order to
> | ensure proper interoperability in legacy SDH/SONET networks as well as
> | networks in which G.7714.1 is deployed, it will be recommended by the
> | editors to the CCAMP community to support only the Jx trace correlation
> | procedure and not the in-band Jx procedure.
> 
> Please respond with one of the following:
>  - Agree with above change; OR
>  - Don't agree with above change [i.e., keep in-band Jx procedure as is].
> 
> Kireeti.

Delivery-date: Tue, 13 May 2003 16:23:44 +0000
From: "zafar ali" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>
Subject: RE: Proposed change to LMP Link Verification draft
Date: Tue, 13 May 2003 12:23:02 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kireeti Kompella
> Sent: Monday, May 12, 2003 2:28 AM
> To: [email-masked]
> Subject: Proposed change to LMP Link Verification draft
> 
> 
> Hi All,
> 
> | Based on information contained in the ITU and T1X1 liaison, 
> as well as 
> | subsequent e-mail exchanges on the CCAMP mailing list, and 
> in order to 
> | ensure proper interoperability in legacy SDH/SONET networks 
> as well as 
> | networks in which G.7714.1 is deployed, it will be 
> recommended by the 
> | editors to the CCAMP community to support only the Jx trace 
> | correlation procedure and not the in-band Jx procedure.
> 
> Please respond with one of the following:
>  - Agree with above change; OR

I agree with the above change;

Thanks
 
Regards... Zafar

>  - Don't agree with above change [i.e., keep in-band Jx 
> procedure as is].
> 
> Kireeti.
> 
> 

Delivery-date: Tue, 13 May 2003 16:19:07 +0000
From: John Drake <[email-masked]>
To: John Drake <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 09:18:09 -0700

Bert,

Also, I don't know if you noticed but Deborah Brungard, who was a major
contributor to G.8080 (ASON), helped us out with the RSVP extensions I-D
(http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-ason-
00.txt).

So we really are trying to make the ITU/IETF working relationship better.

Thanks,

John 

> -----Original Message-----
> From: John Drake 
> Sent: Tuesday, May 13, 2003 9:09 AM
> To: 'Wijnen, Bert (Bert)'
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Bert,
> 
> We're discussing submitting the two drafts 
> (http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp
> -gmpls-ason-reqts-00.txt, 
> http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-
> rsvp-te-ason-00.txt) as contributions to the ITU meeting in 
> Chicago next month.
> 
> The intention is to work closely with T1X1 and ITU in order 
> to get them a satisfactory GMPLS solution, but we still need 
> to follow the IETF process for work done in the IETF.
> 
> Thanks,
> 
> John
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Tuesday, May 13, 2003 8:56 AM
> > To: John Drake
> > Cc: [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > > 
> > > 
> > http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chn
> > g-proc-00.txt.
> > > (It's the one you co-authored.)
> > > 
> > Aha... OK, that doc still needs approval.
> > We have sort of agreed that we would test-run a document from MPLS
> > WG through the process to see how/if it works.
> > 
> > But more to the point, that document is on how we control 
> work brought
> > to the IETF. It does not control how we interact as decent 
> > human beings
> > and decent organisations with our counterparts.
> > 
> > The ASON specs (including how to do GMPLS for ASON) were done 
> > by ITU-T.
> > So we cannot just assume that we need to take over. I do not believe
> > that tha above change-control-procedures are intended to specify
> > how we take away or steal or whatever-term-you-want-use work from
> > other organisations.
> > 
> > That is why I suggested the decent communication path in my earlier
> > posting.
> > 
> > Bert
> > > > -----Original Message-----
> > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > Sent: Tuesday, May 13, 2003 8:11 AM
> > > > To: John Drake
> > > > Cc: [email-masked]
> > > > Subject: RE: ASON reqts
> > > > 
> > > > 
> > > > > 
> > > > > Bert,
> > > > > 
> > > > > I thought that we had a process - the post RFC3474 process.  
> > > > 
> > > > I guess I must have missed that. 
> > > > Where is that or what are you referring to?
> > > > 
> > > > I also know that some of you do not believe we did send the ASON
> > > > people away... but for me that it what it boiled down to.
> > > > YMMV
> > > > 
> > > > Bert
> > > > 
> > > 
> > 
> 

Delivery-date: Tue, 13 May 2003 16:09:36 +0000
From: John Drake <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 09:09:02 -0700

Bert,

We're discussing submitting the two drafts
(http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ason-re
qts-00.txt,
http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-ason-0
0.txt) as contributions to the ITU meeting in Chicago next month.

The intention is to work closely with T1X1 and ITU in order to get them a
satisfactory GMPLS solution, but we still need to follow the IETF process
for work done in the IETF.

Thanks,

John

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 8:56 AM
> To: John Drake
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chn
> g-proc-00.txt.
> > (It's the one you co-authored.)
> > 
> Aha... OK, that doc still needs approval.
> We have sort of agreed that we would test-run a document from MPLS
> WG through the process to see how/if it works.
> 
> But more to the point, that document is on how we control work brought
> to the IETF. It does not control how we interact as decent 
> human beings
> and decent organisations with our counterparts.
> 
> The ASON specs (including how to do GMPLS for ASON) were done 
> by ITU-T.
> So we cannot just assume that we need to take over. I do not believe
> that tha above change-control-procedures are intended to specify
> how we take away or steal or whatever-term-you-want-use work from
> other organisations.
> 
> That is why I suggested the decent communication path in my earlier
> posting.
> 
> Bert
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > Sent: Tuesday, May 13, 2003 8:11 AM
> > > To: John Drake
> > > Cc: [email-masked]
> > > Subject: RE: ASON reqts
> > > 
> > > 
> > > > 
> > > > Bert,
> > > > 
> > > > I thought that we had a process - the post RFC3474 process.  
> > > 
> > > I guess I must have missed that. 
> > > Where is that or what are you referring to?
> > > 
> > > I also know that some of you do not believe we did send the ASON
> > > people away... but for me that it what it boiled down to.
> > > YMMV
> > > 
> > > Bert
> > > 
> > 
> 

Delivery-date: Tue, 13 May 2003 16:07:53 +0000
From: "Jonathan Lang" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>
Subject: RE: Proposed change to LMP Link Verification draft
Date: Tue, 13 May 2003 09:07:24 -0700

Kireeti,
  Agree with above change.

-Jonathan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kireeti Kompella
> Sent: Sunday, May 11, 2003 11:28 PM
> To: [email-masked]
> Subject: Proposed change to LMP Link Verification draft
> 
> 
> Hi All,
> 
> | Based on information contained in the ITU and T1X1 liaison, 
> as well as 
> | subsequent e-mail exchanges on the CCAMP mailing list, and 
> in order to 
> | ensure proper interoperability in legacy SDH/SONET networks 
> as well as 
> | networks in which G.7714.1 is deployed, it will be 
> recommended by the 
> | editors to the CCAMP community to support only the Jx trace 
> | correlation procedure and not the in-band Jx procedure.
> 
> Please respond with one of the following:
>  - Agree with above change; OR
>  - Don't agree with above change [i.e., keep in-band Jx 
> procedure as is].
> 
> Kireeti.
> 

Delivery-date: Tue, 13 May 2003 16:07:44 +0000
From: "Jonathan Lang" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "'Wijnen, Bert \(Bert\)'" <[email-masked]>, "'Ron Bonica \(E-mail\)'" <[email-masked]>, <[email-masked]>
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation
Date: Tue, 13 May 2003 09:06:54 -0700

Kireeti,

  Fine, send it as is.

-Jonathan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kireeti Kompella
> Sent: Sunday, May 11, 2003 11:23 PM
> To: [email-masked]
> Cc: [email-masked]; Wijnen, Bert (Bert); Ron Bonica 
> (E-mail); [email-masked]
> Subject: RE: Proposed response to the Liaison Statement on 
> LMP Link Verifi cation
> 
> 
> Hi All,
> 
> On Tue, 29 Apr 2003, Kireeti Kompella wrote:
> 
> > I will formulate a liaison statement in reply to T1X1 regarding 
> > draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list.
> 
> Sorry for the tardy follow-up.  Here is the proposed response.
> 
> Please send your replies to the list (if you wish to reply 
> privately, include the Liaison Coordinator and the ADs in your reply).
> 
> Ideally, your reply should say one of:
>  - "Fine, send it as is"; OR
>  - "Please make the following changes", with _specific text_; OR
>  - "Do not send this response".
> 
> Please respond by COB Friday, May 16th.
> 
> Kireeti. 
> ==============================================================
> =========
> 
> Dear Mr. Biholar,
> 
> Regarding the following liaison:
> 
> TITLE: Liaison from T1X1 to IETF ccamp regarding
> 	draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt
> TO: IETF ccamp Working Group
> CC: ITU-T Q.14/15 (for information)
> SOURCE*: T1X1
> FOR: Action
> DEADLINE: 9 June 2003
> PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic 
> Interconnection
> 
> We thank the T1X1 and the ITU-T for their review and the 
> incorporation of the LMP Test procedure into G.7714.1.
> 
> Based on information contained in the ITU and T1X1 liaison, 
> as well as subsequent e-mail exchanges on the CCAMP mailing 
> list, and in order to ensure proper interoperability in 
> legacy SDH/SONET networks as well as networks in which 
> G.7714.1 is deployed, it will be recommended by the editors 
> to the CCAMP community to support only the Jx trace 
> correlation procedure and not the in-band Jx procedure.  
> Pending agreement, the draft will be updated.
> 
> See inline for more detailed responses to specific points.
> 
> > Context of Application Space
> 
> <snip>
> 
> > It is currently our understanding that the use case
> > scenario for which this procedure is applied encompasses
> > both transport plane connectivity verification as well as 
> correlation 
> > of these entities with the control plane. ITU-T G.7714.1 is 
> focused on 
> > discovering the transport plane link connection end point 
> > relationships and verifying their connectivity.
> > This Recommendation defines two procedures for performing
> > the connectivity verification function, one of which
> > utilizes either the Jx or the DCC bytes of the server
> > signal (termed "in-service"). The other approach in
> > G.7714.1, termed as "out of service", corresponds to
> > inserting a test signal in the payload of the server
> > signal. Based on an analysis of the data link state
> > definitions in draft-ietf-ccamp-lmp-08.txt, we understand
> > that the approach defined in the LMP test for physical
> > connectivity occurs in the context of the "out of service"
> > state (as described in G.7714.1).
> >
> > Please confirm this.
> 
> The subject document uses the Jx or DCC bytes to perform the 
> LMP Test procedure, but the The LMP Test procedure is done as 
> part of GMPLS link intialization, prior to the link being 
> available to carry user traffic.
> 
> > Usage of Jx Bytes
> >
> > In defining the Jx bytes within G.7714.1, the following
> > was taken into account:
> > 1. One consideration involved the case where the Discovery Agent is 
> > located in an external system, and an external interface is used by 
> > the Network Element to provision and receive the Trail 
> Trace message. 
> > As an existing text- oriented Man-Machine Language, such as 
> TL1, may 
> > be reused to provide this interface, it was decided that the
> > discovery message be limited to printable characters.
> > Specifically, the TTI characters should be limited to
> > printable characters as per T.50 with trailing NULLs or
> > SPACEs. Use of arbitrary bit patterns in the lower 7 bits
> > of each byte could prematurely terminate the pattern or
> > trigger fault notification for certain hardware or
> > software implementations. The strategy chosen in G.7714.1
> > avoids the danger by limiting the information content of
> > each byte to 6 bits (84 bits total) and uses a base 64
> > coding according to RFC2045 to place the information in
> > the available bits.
> 
> The LMP test procedure described in the subject document 
> defines two usages of the Jx bytes.  The first is termed the 
> 'trace correlation transport mechanism' and it treats the Jx 
> bytes as an opaque bit stream.
> 
> This usage is completely consistent with the above.  GMPLS 
> identifiers are typically 32 bit numbers and as such are not 
> printable characters.  In networks that do not require that 
> the Jx bytes be printable, it is also possible to carry the 
> GMPLS identifiers directly in the Jx bytes.  This is termed 
> the 'Jx transport mechanism'.
> 
> > 2. Another consideration involved providing a means for 
> distinguishing 
> > this use of the Jx bytes from the traditional use for Trail Trace 
> > identifiers in new equipments. As a result, G.7714.1 includes a
> > distinguishing character ("+") as the first non-CRC byte
> > that will never appear as the first character of a TTI.
> > This requires modification of the trail termination
> > functions to prevent the raising of TTI mismatch
> > alarms during the connectivity verification process.
> 
> The selection of which LMP transport mechanism use in the LMP 
> Test procedure for a given link as well as the time at which 
> the Jx bytes are to be used for the LMP Test procedure is 
> under control of the GMPLS nodes at either end of the link, 
> so it is well understood by those nodes.  It is our 
> understanding, per G.806 section 6.1, that the LMP Test 
> procedure would be performed when the link is in the NMON 
> (not monitored state), and therefore intermediate SDH/SONET 
> equipment would not be performing non-intrusive monitoring.
> 
> > While the context for testing the transport plane connectivity is 
> > different between the two documents, they both use the Jx 
> bytes of the 
> > server signal, and we invite the IETF to determine the 
> appropriateness 
> > of the above aspects in their test signal definitions.
> 
> The trace correlation transport mechanism is completely 
> consistent with this.  The JX transport mechanism requires 
> additional identifiers (i.e., the Verify ID).
> 
> > Even if these considerations are not relevant to this 
> context, it will 
> > be necessary to augment G.783 equipment functions to recognize this 
> > new usage of Jx messages.
> 
> We would be happy to provide assistance to T1X1/ITU-T in 
> augmenting G.783 equipment functions to recognize the 
> additional capability for supporting GMPLS networking elements.
> 
> > Required Updates to SDH Equipment Specifications
> >
> > SDH equipment specifications as they currently exist 
> reflect the usage 
> > of the Jx bytes prior to the development of G.7714.1. ITU-T Study 
> > Group 15 has as a work item to revise these equipment functions to 
> > include support for these new functions. Specifically, this will 
> > involve updates to trail termination functions to generate and
> > receive the new messages and to avoid unnecessary alarms in
> > the case where the new messages are received.  In addition,
> > non-intrusive monitoring functions will need to be revised
> > so that unnecessary alarms are not raised when the
> > messages are observed en-route.  Whether or not there is
> > further alignment between the message formats used in
> > G.7714.1 and the subject draft, the new functions to
> > support the subject draft will also need to be reflected
> > in the atomic functions in G.783.  The sending and
> > receiving of these messages can be reflected in the trail
> > termination functions in a similar way to what we plan to
> > do for support of G.7714.1 functions.
> 
> We would be happy to provide assistance to T1X1/ITU-T in 
> augmenting G.783 equipment functions to recognize the 
> additional capability for supporting GMPLS networking elements.
> 
> > Terminology Differences
> 
> <snip>
> 
> > Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1,
> > the "up/free (in-service)" data link state appears to 
> correspond with 
> > what G.7714.1 refers to as "out-of- service".  This difference in 
> > terminology has resulted in different interpretations of 
> the context.  
> > Explaining the scenarios further in the lmp test document would be
> > beneficial in establishing a translation between the
> > differing uses of the same terms.  Within ITU-T, work is
> > being initiated of draft Rec. G.fame, Framework for ASON
> > Management, where control plane/management plane
> > interactions will be addressed.
> 
> We agree that terminology differences between IETF and ITU-T 
> wrt GMPLS have been confusing.  There is an ongoing effort 
> within CCAMP to work together with T1X1/ITU-T on bridging the 
> terminology gaps.  For example, there is a new Internet draft
> (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered 
> in CCAMP to do this mapping for LMP.
> 
> > Further Study Items
> >
> > Following are some areas where further contributions are
> > requested:
> > 1.     For SDH equipment functions in G.783, it needs to
> > be understood whether the application of the lmp test
> > message requires revision of NIM (non-intrusive
> > monitoring) functions.  The reason for this is that the
> > test procedure is initiated between control entities at
> > the end-points of the trail, and intermediate points are
> > not necessarily aware that the test is taking place.  For 
> G.7714.1, it 
> > was felt important for any termination or NIM function to easily 
> > distinguish between the various uses of the Jx bytes.  It may be 
> > necessary for the subject draft to use a similarly easily 
> recognizable 
> > format.  If no revision to NIM functions is required for 
> the context 
> > of this draft, the architecture of the context for this
> > application (demonstrating why the NIM functions are not
> > required) should be reflected in G.803 and/or G.807/G.8080.
> 
> It is our understanding, per G.806 section 6.1, that
> the LMP Test procedure would be performed when the link is in 
> the NMON (not monitored state), and  therefore intermediate 
> SDH/SONET equipment would not be performing non-intrusive 
> monitoring. As described, the trace correlation procedure use 
> of Jx bytes is consistent with the current standards.
> 
> > 2.Determination of whether it would be possible to use the 
> identical 
> > message formats in the subject draft as in G.7714.1 for the 
> > connectivity verification function.
> 
> The trace correlation transport mechanism is completely 
> consistent with this.  The Jx transport mechanism requires 
> additional identifiers (i.e., the Verify ID).
> 
> > 3.Determination of whether it would be possible to use the same 
> > overall structure (distinguishing character, 4 bit message type, 80 
> > bit message body) if a different message format or 
> information content 
> > is required.
> 
> This is certainly possible (not applicable for the trace 
> correlation procedure).
> 
> > 4.Work is needed to clarify under what
> > configurations/states (for example: no VC-n signals
> > carrying client traffic) the lmp test message is
> > applicable over J0.  If the signal can be framed and J0
> > can be recovered, the Regenerator Section is considered
> > as "in service" from a transport plane perspective.  So unlike the 
> > J1/J2 case, the application of the lmp test message at the 
> Regenerator 
> > Section does not occur in an "out of service" state (from a 
> transport 
> > plane perspective).
> 
> Section 6.1 of G.806 refers to a "termination function part 
> of a trail, which is in the process of set-up" as in the NMON 
> state. LMP link verification is based on pre-service testing. 
>  Please let us know if we can be of any assistance in 
> updating the appropriate Recommendations to support the GMPLS 
> network element LMP capability. This is not applicable for 
> the trace correlation procedure.
> 
> > 5. Clarification of the usage of transport and control
> > names for transport resources in the subject draft, as described in 
> > G.8080 Amendment
> 
> The trace correlation transport mechanism supports a 
> separation of the transport and control plane identifiers.
> 
> > 6. Consideration of the ANSI 64-byte J1.
> 
> This was mistakenly deleted from the latest version of the 
> draft. This will be included in the next version.
> 
> Sincerely,
> Kireeti Kompella and Ron Bonica,
> Chairs of the CCAMP WG/IETF.
> 

Delivery-date: Tue, 13 May 2003 15:57:59 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: John Drake <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 17:56:21 +0200

> 
> http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt.
> (It's the one you co-authored.)
> 
Aha... OK, that doc still needs approval.
We have sort of agreed that we would test-run a document from MPLS
WG through the process to see how/if it works.

But more to the point, that document is on how we control work brought
to the IETF. It does not control how we interact as decent human beings
and decent organisations with our counterparts.

The ASON specs (including how to do GMPLS for ASON) were done by ITU-T.
So we cannot just assume that we need to take over. I do not believe
that tha above change-control-procedures are intended to specify
how we take away or steal or whatever-term-you-want-use work from
other organisations.

That is why I suggested the decent communication path in my earlier
posting.

Bert
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Tuesday, May 13, 2003 8:11 AM
> > To: John Drake
> > Cc: [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > > 
> > > Bert,
> > > 
> > > I thought that we had a process - the post RFC3474 process.  
> > 
> > I guess I must have missed that. 
> > Where is that or what are you referring to?
> > 
> > I also know that some of you do not believe we did send the ASON
> > people away... but for me that it what it boiled down to.
> > YMMV
> > 
> > Bert
> > 
> 

Delivery-date: Tue, 13 May 2003 15:14:08 +0000
From: John Drake <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 08:13:28 -0700

http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt.
(It's the one you co-authored.)

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 8:11 AM
> To: John Drake
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> > 
> > Bert,
> > 
> > I thought that we had a process - the post RFC3474 process.  
> 
> I guess I must have missed that. 
> Where is that or what are you referring to?
> 
> I also know that some of you do not believe we did send the ASON
> people away... but for me that it what it boiled down to.
> YMMV
> 
> Bert
> 

Delivery-date: Tue, 13 May 2003 15:11:35 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: John Drake <[email-masked]>
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 17:10:37 +0200

> 
> Bert,
> 
> I thought that we had a process - the post RFC3474 process.  

I guess I must have missed that. 
Where is that or what are you referring to?

I also know that some of you do not believe we did send the ASON
people away... but for me that it what it boiled down to.
YMMV

Bert

Delivery-date: Tue, 13 May 2003 14:58:07 +0000
From: John Drake <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 07:57:10 -0700

Bert,

I thought that we had a process - the post RFC3474 process.  Why are you
inventing another process on the fly?  Comments inline.

Thanks,

John

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 7:38 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: ASON reqts
> 
> 
> AD-hat on.
> 
> Bart writes:
> > 
> > 
> > Stephen,
> > 
> > I think the point was rather to go back to
> > just a single GMPLS spec instead of two (let alone three) 
> variants...
> > 
> If that is the case, and if we want to do that in IETF CCAMP 
> (not sure it is part of the current CCAMP charter),
> then it seems to me that we (CCAMP) should excercise these steps:
> 
> - send some liason to ITU-T SG 15 to explain that we found that
>   there seems to be a GMPLS (for IETF) and a GMPLS-ASON standard

Based upon Stephen's e-mails, I think the ITU is well aware of this.

> - that we think that this is NOT goodness, and that we regret that
>   we did send the ASON people away a few years back and did not
>   closely follow their work in ITU

This isn't correct.  Please review the ccamp minutes from Yokohama.

> - that we now believe that we should have worked better together,
> - that we would like to explore ways to try and mrege the two
>   solution back into one common solution

See above.

> 
> And then await the response and hope ITU will agree and then see
> how the work can be organized.
> 
> > 
> > Bart
> > 
> Bert
> 

Delivery-date: Tue, 13 May 2003 14:39:38 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 16:38:27 +0200

AD-hat on.

Bart writes:
> 
> 
> Stephen,
> 
> I think the point was rather to go back to
> just a single GMPLS spec instead of two (let alone three) variants...
> 
If that is the case, and if we want to do that in IETF CCAMP 
(not sure it is part of the current CCAMP charter),
then it seems to me that we (CCAMP) should excercise these steps:

- send some liason to ITU-T SG 15 to explain that we found that
  there seems to be a GMPLS (for IETF) and a GMPLS-ASON standard
- that we think that this is NOT goodness, and that we regret that
  we did send the ASON people away a few years back and did not
  closely follow their work in ITU
- that we now believe that we should have worked better together,
- that we would like to explore ways to try and mrege the two
  solution back into one common solution

And then await the response and hope ITU will agree and then see
how the work can be organized.

> 
> Bart
> 
Bert

Delivery-date: Tue, 13 May 2003 14:20:01 +0000
From: [email-masked]
Sensitivity: 
Subject: Re: ASON reqts
To: Stephen Trowbridge <[email-masked]>
Cc: [email-masked], John Drake <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Date: Tue, 13 May 2003 16:19:14 +0200

Stephen,

I think the point was rather to go back to
just a single GMPLS spec instead of two (let alone three) variants...

Bart

Stephen Trowbridge <[email-masked]>@ops.ietf.org on 13/05/2003
15:51:54

Sent by:    [email-masked]

To:    Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc:    John Drake <[email-masked]>, "'Wijnen, Bert (Bert)'"
       <[email-masked]>, Kireeti Kompella <[email-masked]>,
       [email-masked]
Subject:    Re: ASON reqts

Dimitri,

[email-masked] wrote:
> as of today we have two flavors "ASON/GMPLS" and "GMPLS"

And these two flavors were developed to two sets of requirements.
Base GMPLS comes from the requirements of IP networks that happen
to use TDM, WDM technologies at the lower layers. The ASON
extensions come from the additional requirements of (not necessarily
IP) transport networks.

I do not believe we have a third set of requirements. Can we please
avoid creating a third variant of the protocol?
Steve

Delivery-date: Tue, 13 May 2003 14:18:27 +0000
Date: Tue, 13 May 2003 16:24:28 +0200
From: [email-masked]
To: "Varma, Eve L (Eve)" <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, John Drake <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

eve, first a clarification that should be made here,
a wg item = an item to be work out by the working group
(the ccamp wg, in this case) this does not mean that
the document ready to become an rfc (or to be reviewed
by the iesg or by ad's)

i want also to recap here that the scope of this i-d
is clearly about the *delta* requirements required from
the so-called "gmpls toolbox" in support of ason networks,
it does not intend to be a repetition of the architectural
document and its amendments as being worked out by
the itu-t (see also deborah comment on this) - it is
also the intent to generate the interest from the
reader in consulting the appropriate references -

these principles should be maintained if we want to
achieve the expected result a single set of gmpls
spec's covering the user community needs

thanks for your suggestion (also please take a look at
the terminology section)
- dimitri.

Varma, Eve L (Eve) wrote:
 > Hi,
 >
 > I'll give you one example - clarifications related to the discussion
 > of domains, interfaces, and reference points, which has been at the
 > heart of many a discussion.  This clarification comes from G.8080
 > Amendment 1, and is extremely helpful in understanding the concept
 > and its applicability.
 >
 > Specifically, some additional text is needed to expand upon the
 > discussion of reference points & domains in the second paragraph of
 > "Problem Statement", reproduced below: "The ASON control plane
 > specification is meant to be applicable to different transport
 > technologies (e.g., SDH/SONET, OTN) in various networking
 > environments (e.g., inter-carrier, intra-carrier). Also, ASON model
 > distinguishes reference points (representing points of protocol
 > information exchange) defined (1) between an administrative domain
 > and a user (2) between administrative domains and (3) between areas
 > of the same administrative domain and when needed between control
 > components (or simply controllers) within areas. A full description
 > of the ASON terms and relationship between ASON model and GMPLS
 > protocol suite may be found in [IPO-ASON]."
 >
 > The proposed expanded text is as follows:
 >
 > "The ASON control plane specification is meant to be applicable to
 > different transport technologies (e.g., SDH/SONET, OTN) in various
 > networking environments, and to support a range of business models.
 > As Automatically Switched Optical Networks (ASONs) are deployed into
 > new and existing networks, it cannot be assumed that such networks
 > will be homogeneous (e.g., with respect to transport technologies,
 > vendors, approach to management/control). This is true even within a
 > single carrier's network. In order to support deployment of an
 > optical control plane into a heterogeneous environment, the ASON
 > model introduces the concept of control domains and associated inter-
 > and intra-domain reference points.
 >
 > A control domain is an architectural construct that provides for
 > encapsulation and information hiding, with the characteristics of the
 > control domain identical to those of its constituent architectural
 > components. The UNI and E-NNI reference points are defined to exist
 > between control domains, while the I-NNI reference point is defined
 > as existing within a control domain. The nature of the information
 > exchanged between control domains across the E-NNI reference point
 > captures the common semantics of the information exchanged amongst
 > its constituent components, while allowing for different
 > representations inside each control domain. The reference points are
 > realized as interfaces when instantiated by signaling and routing
 > protocols as appropriate (i.e., no routing information is exchanged
 > over the UNI reference point).  Further description of the ASON model
 > and GMPLS protocol suite may be found in [IPO-ASON]".
 >
 > Eve
 >
 > -----Original Message----- From: Adrian Farrel
 > [mailto:[email-masked]] Sent: Monday, May 12, 2003 7:09 PM To:
 > Stephen Trowbridge; John Drake Cc: 'Wijnen, Bert (Bert)'; Kireeti
 > Kompella; [email-masked] Subject: Re: ASON reqts
 >
 >
 >
 >> Back to Bert's original questions:
 >>
 >>>>>> - is there or do we see any conflict?
 >>>>>
 >> - As Zhi said, this is not (yet) fully aligned with ITU-T
 >> requirements and should not be advanced to a WG document until it
 >> is. However, before we do, I think we need to understand why this
 >> is necessary - see below.
 >
 >
 > Notwithstanding the immediate future of this document (WG or not WG)
 > I would greatly appreciate a summary of the areas that are deficient.
 >
 >
 > Thanks, Adrian
 >
 >
 >

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

Delivery-date: Tue, 13 May 2003 14:12:00 +0000
Date: Tue, 13 May 2003 16:17:58 +0200
From: [email-masked]
To: Stephen Trowbridge <[email-masked]>
Cc: John Drake <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

stephen, john already responded to that question.
in brief, RFC3474 beside its technical issues,
does not entirely cover all the ason requirements

thanks,
- dimitri

Stephen Trowbridge wrote:
> Dimitri,
> 
> [email-masked] wrote:
> 
>>as of today we have two flavors "ASON/GMPLS" and "GMPLS"
> 
> 
> And these two flavors were developed to two sets of requirements.
> Base GMPLS comes from the requirements of IP networks that happen
> to use TDM, WDM technologies at the lower layers. The ASON
> extensions come from the additional requirements of (not necessarily
> IP) transport networks.
> 
> I do not believe we have a third set of requirements. Can we please
> avoid creating a third variant of the protocol?
 >
> Steve
> 

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

Delivery-date: Tue, 13 May 2003 14:06:43 +0000
Date: Tue, 13 May 2003 10:07:52 -0400
From: David Charlap <[email-masked]>
Organization: Marconi, Vienna VA
To: IETF CCAMP List <[email-masked]>
Subject: Re: ASON reqts

Oops.  Sent this to the wrong list...

----- Original Message -----
From: "David Charlap" <[email-masked]>
To: "IETF PPVPN List" <[email-masked]>
Sent: Monday, May 12, 2003 5:55 PM
Subject: Re: ASON reqts

> "I have read this document and it is ready to be a CCAMP WG doc"
>
> There are a few issues that I don't quite understand and/or need
> clarification on, but the current vote is WG acceptance, not last-call.
> I have no issues with it that would keep it out from the WG.
>
> -- David

Delivery-date: Tue, 13 May 2003 13:52:52 +0000
Date: Tue, 13 May 2003 07:51:54 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
CC: John Drake <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

Dimitri,

[email-masked] wrote:
> as of today we have two flavors "ASON/GMPLS" and "GMPLS"

And these two flavors were developed to two sets of requirements.
Base GMPLS comes from the requirements of IP networks that happen
to use TDM, WDM technologies at the lower layers. The ASON
extensions come from the additional requirements of (not necessarily
IP) transport networks.

I do not believe we have a third set of requirements. Can we please
avoid creating a third variant of the protocol?
Steve

Delivery-date: Tue, 13 May 2003 13:42:29 +0000
Date: Tue, 13 May 2003 15:41:37 +0200
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: Kireeti Kompella <[email-masked]>
CC: [email-masked], [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation

 - "Fine, send it as is"

Gert

On Tue, 29 Apr 2003, Kireeti Kompella wrote:

>
> > I will formulate a liaison statement in reply to T1X1 regarding
> > draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list.
>
> Sorry for the tardy follow-up.  Here is the proposed response.
>
> Please send your replies to the list (if you wish to reply privately,
> include the Liaison Coordinator and the ADs in your reply).
>
> Ideally, your reply should say one of:
>  - "Fine, send it as is"; OR
>  - "Please make the following changes", with _specific text_; OR
>  - "Do not send this response".
>
> Please respond by COB Friday, May 16th.
>
> Kireeti.
> =======================================================================
>
> Dear Mr. Biholar,
>
> Regarding the following liaison:
>
> TITLE: Liaison from T1X1 to IETF ccamp regarding
>         draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt
> TO: IETF ccamp Working Group
> CC: ITU-T Q.14/15 (for information)
> SOURCE*: T1X1
> FOR: Action
> DEADLINE: 9 June 2003
> PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic Interconnection
>
> We thank the T1X1 and the ITU-T for their review and the incorporation
> of the LMP Test procedure into G.7714.1.
>
> Based on information contained in the ITU and T1X1 liaison, as well as
> subsequent e-mail exchanges on the CCAMP mailing list, and in order to
> ensure proper interoperability in legacy SDH/SONET networks as well as
> networks in which G.7714.1 is deployed, it will be recommended by the
> editors to the CCAMP community to support only the Jx trace correlation
> procedure and not the in-band Jx procedure.  Pending agreement, the
> draft will be updated.
>
> See inline for more detailed responses to specific points.
>
> > Context of Application Space
>
> <snip>
>
> > It is currently our understanding that the use case
> > scenario for which this procedure is applied encompasses
> > both transport plane connectivity verification as well as
> > correlation of these entities with the control plane.
> > ITU-T G.7714.1 is focused on discovering the transport
> > plane link connection end point relationships and
> > verifying their connectivity.
> > This Recommendation defines two procedures for performing
> > the connectivity verification function, one of which
> > utilizes either the Jx or the DCC bytes of the server
> > signal (termed "in-service"). The other approach in
> > G.7714.1, termed as "out of service", corresponds to
> > inserting a test signal in the payload of the server
> > signal. Based on an analysis of the data link state
> > definitions in draft-ietf-ccamp-lmp-08.txt, we understand
> > that the approach defined in the LMP test for physical
> > connectivity occurs in the context of the "out of service"
> > state (as described in G.7714.1).
> >
> > Please confirm this.
>
> The subject document uses the Jx or DCC bytes to perform the LMP
> Test procedure, but the The LMP Test procedure is done as part of
> GMPLS link intialization, prior to the link being available to
> carry user traffic.
>
> > Usage of Jx Bytes
> >
> > In defining the Jx bytes within G.7714.1, the following
> > was taken into account:
> > 1. One consideration involved the case where the Discovery
> > Agent is located in an external system, and an external
> > interface is used by the Network Element to provision and
> > receive the Trail Trace message. As an existing text-
> > oriented Man-Machine Language, such as TL1, may be reused
> > to provide this interface, it was decided that the
> > discovery message be limited to printable characters.
> > Specifically, the TTI characters should be limited to
> > printable characters as per T.50 with trailing NULLs or
> > SPACEs. Use of arbitrary bit patterns in the lower 7 bits
> > of each byte could prematurely terminate the pattern or
> > trigger fault notification for certain hardware or
> > software implementations. The strategy chosen in G.7714.1
> > avoids the danger by limiting the information content of
> > each byte to 6 bits (84 bits total) and uses a base 64
> > coding according to RFC2045 to place the information in
> > the available bits.
>
> The LMP test procedure described in the subject document defines
> two usages of the Jx bytes.  The first is termed the 'trace
> correlation transport mechanism' and it treats the Jx bytes as
> an opaque bit stream.
>
> This usage is completely consistent with the above.  GMPLS
> identifiers are typically 32 bit numbers and as such are not
> printable characters.  In networks that do not require that the
> Jx bytes be printable, it is also possible to carry the GMPLS
> identifiers directly in the Jx bytes.  This is termed the 'Jx
> transport mechanism'.
>
> > 2. Another consideration involved providing a means for
> > distinguishing this use of the Jx bytes from the
> > traditional use for Trail Trace identifiers in new
> > equipments. As a result, G.7714.1 includes a
> > distinguishing character ("+") as the first non-CRC byte
> > that will never appear as the first character of a TTI.
> > This requires modification of the trail termination
> > functions to prevent the raising of TTI mismatch
> > alarms during the connectivity verification process.
>
> The selection of which LMP transport mechanism use in the LMP Test
> procedure for a given link as well as the time at which the Jx
> bytes are to be used for the LMP Test procedure is under control of
> the GMPLS nodes at either end of the link, so it is well understood
> by those nodes.  It is our understanding, per G.806 section 6.1,
> that the LMP Test procedure would be performed when the link is in
> the NMON (not monitored state), and therefore intermediate SDH/SONET
> equipment would not be performing non-intrusive monitoring.
>
> > While the context for testing the transport plane
> > connectivity is different between the two documents, they
> > both use the Jx bytes of the server signal, and we invite
> > the IETF to determine the appropriateness of the above
> > aspects in their test signal definitions.
>
> The trace correlation transport mechanism is completely consistent
> with this.  The JX transport mechanism requires additional
> identifiers (i.e., the Verify ID).
>
> > Even if these considerations are not relevant to this
> > context, it will be necessary to augment G.783 equipment
> > functions to recognize this new usage of Jx messages.
>
> We would be happy to provide assistance to T1X1/ITU-T in augmenting
> G.783 equipment functions to recognize the additional capability
> for supporting GMPLS networking elements.
>
> > Required Updates to SDH Equipment Specifications
> >
> > SDH equipment specifications as they currently exist reflect
> > the usage of the Jx bytes prior to the development of
> > G.7714.1. ITU-T Study Group 15 has as a work item to
> > revise these equipment functions to include support for
> > these new functions. Specifically, this will involve
> > updates to trail termination functions to generate and
> > receive the new messages and to avoid unnecessary alarms in
> > the case where the new messages are received.  In addition,
> > non-intrusive monitoring functions will need to be revised
> > so that unnecessary alarms are not raised when the
> > messages are observed en-route.  Whether or not there is
> > further alignment between the message formats used in
> > G.7714.1 and the subject draft, the new functions to
> > support the subject draft will also need to be reflected
> > in the atomic functions in G.783.  The sending and
> > receiving of these messages can be reflected in the trail
> > termination functions in a similar way to what we plan to
> > do for support of G.7714.1 functions.
>
> We would be happy to provide assistance to T1X1/ITU-T in augmenting
> G.783 equipment functions to recognize the additional capability
> for supporting GMPLS networking elements.
>
> > Terminology Differences
>
> <snip>
>
> > Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1,
> > the "up/free (in-service)" data link state appears to
> > correspond with what G.7714.1 refers to as "out-of-
> > service".  This difference in terminology has resulted in
> > different interpretations of the context.  Explaining the
> > scenarios further in the lmp test document would be
> > beneficial in establishing a translation between the
> > differing uses of the same terms.  Within ITU-T, work is
> > being initiated of draft Rec. G.fame, Framework for ASON
> > Management, where control plane/management plane
> > interactions will be addressed.
>
> We agree that terminology differences between IETF and ITU-T wrt
> GMPLS have been confusing.  There is an ongoing effort within
> CCAMP to work together with T1X1/ITU-T on bridging the terminology
> gaps.  For example, there is a new Internet draft
> (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in
> CCAMP to do this mapping for LMP.
>
> > Further Study Items
> >
> > Following are some areas where further contributions are
> > requested:
> > 1.     For SDH equipment functions in G.783, it needs to
> > be understood whether the application of the lmp test
> > message requires revision of NIM (non-intrusive
> > monitoring) functions.  The reason for this is that the
> > test procedure is initiated between control entities at
> > the end-points of the trail, and intermediate points are
> > not necessarily aware that the test is taking place.  For
> > G.7714.1, it was felt important for any termination or NIM
> > function to easily distinguish between the various uses of
> > the Jx bytes.  It may be necessary for the subject draft
> > to use a similarly easily recognizable format.  If no
> > revision to NIM functions is required for the context of
> > this draft, the architecture of the context for this
> > application (demonstrating why the NIM functions are not
> > required) should be reflected in G.803 and/or G.807/G.8080.
>
> It is our understanding, per G.806 section 6.1, that
> the LMP Test procedure would be performed when the link is in the
> NMON (not monitored state), and  therefore intermediate SDH/SONET
> equipment would not be performing non-intrusive monitoring.
> As described, the trace correlation procedure use of Jx bytes is
> consistent with the current standards.
>
> > 2.Determination of whether it would be possible to use the
> > identical message formats in the subject draft as in
> > G.7714.1 for the connectivity verification function.
>
> The trace correlation transport mechanism is completely consistent
> with this.  The Jx transport mechanism requires additional
> identifiers (i.e., the Verify ID).
>
> > 3.Determination of whether it would be possible to use the
> > same overall structure (distinguishing character, 4 bit
> > message type, 80 bit message body) if a different message
> > format or information content is required.
>
> This is certainly possible (not applicable for the trace correlation
> procedure).
>
> > 4.Work is needed to clarify under what
> > configurations/states (for example: no VC-n signals
> > carrying client traffic) the lmp test message is
> > applicable over J0.  If the signal can be framed and J0
> > can be recovered, the Regenerator Section is considered
> > as "in service" from a transport plane perspective.  So
> > unlike the J1/J2 case, the application of the lmp test
> > message at the Regenerator Section does not occur in an
> > "out of service" state (from a transport plane
> > perspective).
>
> Section 6.1 of G.806 refers to a "termination function part of a
> trail, which is in the process of set-up" as in the NMON state.
> LMP link verification is based on pre-service testing.  Please let
> us know if we can be of any assistance in updating the appropriate
> Recommendations to support the GMPLS network element LMP capability.
> This is not applicable for the trace correlation procedure.
>
> > 5. Clarification of the usage of transport and control
> > names for transport resources in the subject draft, as
> > described in G.8080 Amendment
>
> The trace correlation transport mechanism supports a separation of
> the transport and control plane identifiers.
>
> > 6. Consideration of the ANSI 64-byte J1.
>
> This was mistakenly deleted from the latest version of the draft.
> This will be included in the next version.
>
> Sincerely,
> Kireeti Kompella and Ron Bonica,
> Chairs of the CCAMP WG/IETF.

Delivery-date: Tue, 13 May 2003 13:38:11 +0000
Date: Tue, 13 May 2003 15:37:34 +0200
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Proposed change to LMP Link Verification draft

agree

Gert

Kireeti Kompella wrote:

> Hi All,
>
> | Based on information contained in the ITU and T1X1 liaison, as well as
> | subsequent e-mail exchanges on the CCAMP mailing list, and in order to
> | ensure proper interoperability in legacy SDH/SONET networks as well as
> | networks in which G.7714.1 is deployed, it will be recommended by the
> | editors to the CCAMP community to support only the Jx trace correlation
> | procedure and not the in-band Jx procedure.
>
> Please respond with one of the following:
>  - Agree with above change; OR
>  - Don't agree with above change [i.e., keep in-band Jx procedure as is].
>
> Kireeti.

Delivery-date: Tue, 13 May 2003 13:38:03 +0000
Date: Tue, 13 May 2003 15:36:40 +0200
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: Kireeti Kompella <[email-masked]>
CC: "Brungard, Deborah A, ALABS" <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

Kireeti,

I have read this document and it is ready to be a CCAMP WG doc

Moreover I appreciate the ongoing discussion about this document since it shows that we
need it as a starting point to come to a common understanding in order to help get the IETF
and the ITU working together.

Regards

Gert

Kireeti Kompella wrote:

> On Fri, 2 May 2003, Brungard, Deborah A, ALABS wrote:
>
> > http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt
>
> To take things one at a time, it would be very useful to read and comment
> on the ASON reqts draft, as this was deemed tremendously important, and
> a rich source of misunderstanding and cross-talk; and coming to a common
> understanding over this should help get the IETF and the ITU working
> together.
>
> I think it would be very useful to progress this document in a timely
> fashion, so I encourage folks to read and comment on it; and perhaps
> in a week or two, to check for consensus to progress it.
>
> > Good reading material for a weekend -
>
> Agreed, for both documents.
>
> Thanks, Deborah!
>
> Kireeti.

Delivery-date: Tue, 13 May 2003 12:42:30 +0000
Date: Tue, 13 May 2003 08:41:51 -0400
To: Kireeti Kompella <[email-masked]>
From: "Bradford, Richard" <[email-masked]>
Subject: Re: Proposed change to LMP Link Verification draft
Cc: [email-masked]

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

Agree with change.
At 11:27 PM 5/11/2003 -0700, Kireeti Kompella wrote:
>Hi All,
>
>| Based on information contained in the ITU and T1X1 liaison, as well as
>| subsequent e-mail exchanges on the CCAMP mailing list, and in order to
>| ensure proper interoperability in legacy SDH/SONET networks as well as
>| networks in which G.7714.1 is deployed, it will be recommended by the
>| editors to the CCAMP community to support only the Jx trace correlation
>| procedure and not the in-band Jx procedure.
>
>Please respond with one of the following:
>  - Agree with above change; OR
>  - Don't agree with above change [i.e., keep in-band Jx procedure as is].
>
>Kireeti.

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

<html>
<font size=3>Agree with change.<br>
At 11:27 PM 5/11/2003 -0700, Kireeti Kompella wrote:<br>
<blockquote type=cite cite>Hi All,<br>
<br>
| Based on information contained in the ITU and T1X1 liaison, as well
as<br>
| subsequent e-mail exchanges on the CCAMP mailing list, and in order
to<br>
| ensure proper interoperability in legacy SDH/SONET networks as well
as<br>
| networks in which G.7714.1 is deployed, it will be recommended by
the<br>
| editors to the CCAMP community to support only the Jx trace
correlation<br>
| procedure and not the in-band Jx procedure.<br>
<br>
Please respond with one of the following:<br>
&nbsp;- Agree with above change; OR<br>
&nbsp;- Don't agree with above change [i.e., keep in-band Jx procedure as
is].<br>
<br>
Kireeti.</font></blockquote><br>

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

--=====================_435032223==_.ALT--

Delivery-date: Tue, 13 May 2003 12:29:14 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 07:28:50 -0500
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: "Varma, Eve L (Eve)" <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>

> I concur with Zhi that the document is not yet ready to be a=20
> WG document.

Not what Zhi said.  He said "I'd like a third option: "I have read this =
document, and it's almost ready to be a CCAMP doc""=20

> Regarding the explanation of requirements, I am still extremely =
puzzled as
> to why the IPO requirements document is not being cited as a source of
> explanation for a number of ASON-related items.  It's almost=20
> as though it never existed.

Actually 2 references are given, although the first seems to have =
expired:

[IPO-ASON]     Aboul-Magd (Editor) et al., "Automatic Switched
                  Optical Network (ASON) Architecture and Its Related
                  Protocols," Work in progress, draft-ietf-ipo-ason-
                  02.txt, March 2002.

[IPO-REQS]     Y.Xue (Editor) et al., "Optical Network Service
                  Requirements," Work in progress, draft-ietf-ipo-
                  carrier-requirements-05.txt.

Jerry

Delivery-date: Tue, 13 May 2003 12:26:41 +0000
Date: Tue, 13 May 2003 14:32:54 +0200
From: [email-masked]
To: "Ong, Lyndon" <[email-masked]>
Cc: "'Stephen Trowbridge'" <[email-masked]>, John Drake <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

lyndon,

also some comments in-line...

Ong, Lyndon wrote:
> Hi Folks,
> 
> I'm hoping that the requirements draft does not imply that 
> we will now define an alternative to 3474, that was not my
> intention when participating in the draft.  
> I see no reason to rethink what was done in 3474, 

well i think there where listed in the signalling proposal
(take a close look at section 3.1):
http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt

i am not sure that trying to "impose" a solution that breaks
the gmpls common developments is a *good* solution

> which has now been 
> implemented and tested by a number of participants
> It would be good to understand if people in the group are
> interested in supporting ASON, 

i think one of the good things that this document delivers
is that it clearly states what "ason support means" from the
signalling perspective, the abstract of this i-d seems (since
so far) to be very clear for the informed reader:

"This document concentrates on the signaling aspects of the GMPLS
  suite of protocols. It identifies the features to be covered by the
  signalling protocol to support the capabilities of an Automatically
  Switched Optical Network (ASON). This document provides a problem
  statement and additional requirements on the GMPLS signaling
  protocol to support the ASON functionality."

> however, which seemed to be
> a controversial issue on the mailing list a while back.
> Also, as Stephen points out, it would be good to get
> feedback from ITU SG 15 on the draft, as it does represent
> only the authors' interpretation of ASON requirements and
> may not be complete.

see the response from an itu participant:
"The document is very aligned with the ITU work. From an ITU 
perspective, the document is easy to read. And considering the author 
list, it's a balanced list of ITU and IETF participants. Following up on 
Adrian's request, I would be interested to hear from IETF participants. 
As Kireeti stated, this document is an attempt to bridge the gaps 
between the IETF and ITU work. Most important for progressing this work 
is the understanding level/interest by the IETF community involved in 
GMPLS."

but since you're looking for more formal ITU review, you know
very well that such things happen much more easily when the i-d
as a WG status.

thanks,
- dimitri.

> 
> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Monday, May 12, 2003 3:23 PM
> To: John Drake
> Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> Subject: Re: ASON reqts
> 
> 
> John,
> Ahhhh....
> This sounds like a whole new can of worms. The goal therefore does
> seem to be to develop yet another protocol solution, and I think
> we need to be VERY careful before taking this kind of step.
> 
> Your assertion now seems to be that RFC 3473+3474 does NOT meet the
> ASON requirements. If this is the case:
> - Does G.7713.2 meet the requirements, and we missed something in
>   the translation to RFC 3474? If so, then we need to supercede
>   RFC 3474 with a better translation, not start over.
> 
> - Do you think that even G.7713.2 does not meet the requirements?
>   If you believe this to be the case, it seems like the obvious
>   first step would be to inform ITU-T - after all, this is where
>   the ASON requirements came from and it makes no sense to start
>   a new protocol without fixing (and aligning) G.7713.2.
> 
> If we made a mistake, lets fix it, but lets NOT start proliferating
> ASON extensions take 2; ASON extensions take 3; ...
> 
> Regards,
> Steve
> 
> John Drake wrote:
> 
>>I think that the problem is that RFC 3474, in addition to its technical
>>issues, doesn't address all of the ASON requirements.  For example, it does
>>not address full call/connection separation.  So we're following the post
>>3474 procees of documenting the ASON requirements relevant to GMPLS
>>signalling in order to have a common understanding of what problem is to be
>>solved.
>>
>>
>>>-----Original Message-----
>>>From: Stephen Trowbridge [mailto:[email-masked]]
>>>Sent: Monday, May 12, 2003 2:27 PM
>>>To: John Drake
>>>Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
>>>Subject: Re: ASON reqts
>>>
>>>
>>>Bert & John,
>>>I think this document has nothing to do with the issue Bert
>>>mentioned. This was a protocol issue, not a requirements issue.
>>>A decision was made to leave the message out of 3474 with the
>>>belief that:
>>>- The protocol works without it; and
>>>- The presence of the message violates the protocol.
>>>The appropriate next step here would be a liaison back to ITU-T
>>>explaining what was done and why, and if the ITU-T agrees with
>>>the reasoning, they can align their protocol document (in this
>>>case, G.7713.2).
>>>
>>>Back to Bert's original questions:
>>>
>>>>>>>- is there or do we see any conflict?
>>>>>>
>>>- As Zhi said, this is not (yet) fully aligned with ITU-T requirements
>>>  and should not be advanced to a WG document until it is.
>>>However, before
>>>  we do, I think we need to understand why this is necessary
>>>- see below.
>>>
>>>
>>>>>>>- are we duplicating some work?
>>>>>>
>>>- Almost certainly. If we take the kind of alignment with ITU-T
>>>  requirements that Zhi mentions as a "gate" for progressing
>>>this, then
>>>  what is in this document that is different from G.8080 and
>>>G.7713 and
>>>  why do we need this in place of a normative reference?
>>>
>>>
>>>>>>>- what is the purpose of this draft?
>>>>>>
>>>Excellent question.
>>>
>>>>>>>  - is it after the fact documenting of requirements?
>>>>>>
>>>If it is, why bother? Also, we already have the requirements
>>>(developed
>>>before the protocol) in G.8080 and G.7713.
>>>
>>>
>>>>>>>  - is it getting ITU-T documented requirements in RFC form?
>>>>>>
>>>This could be a reasonable goal, if this document is to be an info
>>>track requirements document characterizing G.8080 and G.7713 for
>>>IETF folks in the same way that RFC 3474 does for G.7713.2 and
>>>RFC 3475 does for G.7713.3. But it is hard to understand why producing
>>>an IETF translation of the ITU-T question would be very high priority
>>>when we already have an IETF translation of the answer, but
>>>fundamentally
>>>there would be no problem if this were the objective.
>>>
>>>
>>>>>>>  - is it extending ITU-T documented requirements?
>>>>>>
>>>I don't think so. If it is, I hope we start with a liaison rather
>>>than trying to extend ITU-T requirements without talking to
>>>ITU-T first.
>>>
>>>
>>>>>>>  - is it contrdicting them?
>>>>>>
>>>This is my biggest worry. I don't think we should start the process
>>>over again and open the door that we come up with yet another
>>>protocol solution to address the same requirements. Vendors are
>>>already building to G.7713.2, G.7713.3 (and by extension, to
>>>RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT
>>>start a new work item with an objective to develop a new protocol
>>>solution to the same problem.
>>>
>>>
>>>>>>>  - is it meant to be used as communication to ITU?
>>>>>>
>>>I haven't seen this proposed, but I think that if the goal is
>>>to capture ITU-T requirements in RFC form, it would be a good
>>>idea to ask ITU-T whether the proposed document accurately
>>>captures their requirements.
>>>
>>>/Steve
>>>
>>>
>>>John Drake wrote:
>>>
>>>>Bert,
>>>>
>>>>I think so.
>>>>
>>>>Thanks,
>>>>
>>>>John
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Wijnen, Bert (Bert) [mailto:[email-masked]]
>>>>>Sent: Monday, May 12, 2003 1:27 PM
>>>>>To: John Drake; Kireeti Kompella; [email-masked]
>>>>>Subject: RE: ASON reqts
>>>>>
>>>>>
>>>>>I know that some people had issues with the way that ITU-T
>>>>>had defined the RSVP-TE extensions for ASON. In fact there
>>>>>was/is a claim that it is broken. So we removed the offending
>>>>>text from the RFC3474.
>>>>>
>>>>>The next thing we were going to do (as far as I understood it)
>>>>>is to document why we (or some of us in IETF) think that the
>>>>>ITU-T solution is broken, potentially with suggested fixes.
>>>>>That we would send to ITU-T SG15.
>>>>>
>>>>>Is this the first step of that process?
>>>>>
>>>>>Thanks,
>>>>>Bert
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: John Drake [mailto:[email-masked]]
>>>>>>Sent: maandag 12 mei 2003 22:24
>>>>>>To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
>>>>>>Subject: RE: ASON reqts
>>>>>>
>>>>>>
>>>>>>Bert,
>>>>>>
>>>>>>I thought that the post 3474/3475 process started with a
>>>>>
>>>>>requirements
>>>>>
>>>>>>document.
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>John
>>>>>>
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Wijnen, Bert (Bert) [mailto:[email-masked]]
>>>>>>>Sent: Monday, May 12, 2003 1:14 PM
>>>>>>>To: Kireeti Kompella; [email-masked]
>>>>>>>Subject: RE: ASON reqts
>>>>>>>
>>>>>>>
>>>>>>>So if we look at RFCs 3474/3475 and the ITU-T documents
>>>>>>>that those 2 RFCs point to, then I wonder:
>>>>>>>- is there or do we see any conflict?
>>>>>>>- are we duplicating some work?
>>>>>>>- what is the purpose of this draft?
>>>>>>>  - is it after the fact documenting of requirements?
>>>>>>>  - is it getting ITU-T documented requirements in RFC form?
>>>>>>>  - is it extending ITU-T documented requirements?
>>>>>>>  - is it contrdicting them?
>>>>>>>  - is it meant to be used as communication to ITU?
>>>>>>>
>>>>>>>Just wondering what is happening here.
>>>>>>>
>>>>>>>Thanks,
>>>>>>>Bert
>>>>>>>
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Kireeti Kompella [mailto:[email-masked]]
>>>>>>>>Sent: maandag 12 mei 2003 17:25
>>>>>>>>To: [email-masked]
>>>>>>>>Subject: Re: ASON reqts
>>>>>>>>
>>>>>>>>
>>>>>>>>Hi All,
>>>>>>>>
>>>>>>>>On Fri, 2 May 2003, Kireeti Kompella wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>To take things one at a time, it would be very useful to
>>>>>>>>
>>>>>>>>read and comment
>>>>>>>>
>>>>>>>>>on the ASON reqts draft, as this was deemed tremendously
>>>>>>>>
>>>>>>>>important, and
>>>>>>>>
>>>>>>>>>a rich source of misunderstanding and cross-talk; and
>>>>>>>>
>>>>>>>>coming to a common
>>>>>>>>
>>>>>>>>>understanding over this should help get the IETF and the
>>>>>>>>
>>>>>>>ITU working
>>>>>>>
>>>>>>>>>together.
>>>>>>>>
>>>>>>>>I haven't seen many comments, so the assumption is
>>>>>>>
>>>>>either that no
>>>>>
>>>>>>>>one cares, or that folks have read it and have no issues.
>>>>>>>>
>>>>>>>>I'd like to get a reading on whether this doc is
>>>>>>>
>>>ready to be a
>>>
>>>>>>>>CCAMP WG document.  Please respond (preferably publicly)
>>>>>>>
>>>>>>>with one of:
>>>>>>>
>>>>>>>> - "I have read this document and it is ready to be a CCAMP
>>>>>>>
>>>>>>>WG doc" OR
>>>>>>>
>>>>>>>> - "I have read this document, and it isn't ready to be a
>>>>>>>
>>>>>>>CCAMP doc".
>>>>>>>
>>>>>>>>Note that if there aren't enough responses, the default
>>>>>>>
>>>>>>>assumption is
>>>>>>>
>>>>>>>>that the document is either not of interest or not
>>>>>>>
>>>ready, and in
>>>
>>>>>>>>either case will not become a CCAMP WG doc.  Note too
>>>>>>>
>>>>>>that this doc
>>>>>>
>>>>>>>>is an attempt to bridge some gaps between the IETF and
>>>>>>>
>>>>>the ITU-T,
>>>>>
>>>>>>>>and as such is fairly important.  It would be
>>>>>>>
>>>useful to give an
>>>
>>>>>>>>update on its status at the interim T1X1 meeting in June.
>>>>>>>>
>>>>>>>>Please get your responses in by COB Friday May 16th.
>>>>>>>>
>>>>>>>>Thanks,
>>>>>>>>Kireeti.
>>>>>>>>
>>>>>>>
> 
> 

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

Delivery-date: Tue, 13 May 2003 12:23:12 +0000
Date: Tue, 13 May 2003 14:28:44 +0200
From: [email-masked]
To: John Drake <[email-masked]>
Cc: "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

bert, definitely this is the reason, as stated by the
user community ietf'ers (and more generally "operators"
and "carriers") they do not want to see many different
gmpls implementations with interoperability problems -

as of today we have two flavors "ASON/GMPLS" and "GMPLS"
(i refer you to some e-mail exchanges end-of-january'03)
having such kind of naming differentiation is already a
problem for the whole industry (these have been discussed
in the ason-req and signalling i-d's under discussions),
and thus i think the whole issue boils down now to:

"why keeping this distinction is beneficial for the user
and developer community ?"  ... i don't see since so far
any technical argument at all in favor of this approach

thanks,
- dimitri.

John Drake wrote:
> Bert,
> 
> I think so.
> 
> Thanks,
> 
> John
> 
> 
>>-----Original Message-----
>>From: Wijnen, Bert (Bert) [mailto:[email-masked]]
>>Sent: Monday, May 12, 2003 1:27 PM
>>To: John Drake; Kireeti Kompella; [email-masked]
>>Subject: RE: ASON reqts
>>
>>
>>I know that some people had issues with the way that ITU-T
>>had defined the RSVP-TE extensions for ASON. In fact there
>>was/is a claim that it is broken. So we removed the offending
>>text from the RFC3474. 
>>
>>The next thing we were going to do (as far as I understood it)
>>is to document why we (or some of us in IETF) think that the
>>ITU-T solution is broken, potentially with suggested fixes.
>>That we would send to ITU-T SG15.
>>
>>Is this the first step of that process?
>>
>>Thanks,
>>Bert 
>>
>>
>>>-----Original Message-----
>>>From: John Drake [mailto:[email-masked]]
>>>Sent: maandag 12 mei 2003 22:24
>>>To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
>>>Subject: RE: ASON reqts
>>>
>>>
>>>Bert,
>>>
>>>I thought that the post 3474/3475 process started with a 
>>
>>requirements
>>
>>>document.
>>>
>>>Thanks,
>>>
>>>John
>>>
>>>
>>>>-----Original Message-----
>>>>From: Wijnen, Bert (Bert) [mailto:[email-masked]]
>>>>Sent: Monday, May 12, 2003 1:14 PM
>>>>To: Kireeti Kompella; [email-masked]
>>>>Subject: RE: ASON reqts
>>>>
>>>>
>>>>So if we look at RFCs 3474/3475 and the ITU-T documents 
>>>>that those 2 RFCs point to, then I wonder:
>>>>- is there or do we see any conflict?
>>>>- are we duplicating some work?
>>>>- what is the purpose of this draft?
>>>>  - is it after the fact documenting of requirements?
>>>>  - is it getting ITU-T documented requirements in RFC form?
>>>>  - is it extending ITU-T documented requirements?
>>>>  - is it contrdicting them?
>>>>  - is it meant to be used as communication to ITU?
>>>>
>>>>Just wondering what is happening here.
>>>>
>>>>Thanks,
>>>>Bert 
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Kireeti Kompella [mailto:[email-masked]]
>>>>>Sent: maandag 12 mei 2003 17:25
>>>>>To: [email-masked]
>>>>>Subject: Re: ASON reqts
>>>>>
>>>>>
>>>>>Hi All,
>>>>>
>>>>>On Fri, 2 May 2003, Kireeti Kompella wrote:
>>>>>
>>>>>
>>>>>>To take things one at a time, it would be very useful to 
>>>>>
>>>>>read and comment
>>>>>
>>>>>>on the ASON reqts draft, as this was deemed tremendously 
>>>>>
>>>>>important, and
>>>>>
>>>>>>a rich source of misunderstanding and cross-talk; and 
>>>>>
>>>>>coming to a common
>>>>>
>>>>>>understanding over this should help get the IETF and the 
>>>>>
>>>>ITU working
>>>>
>>>>>>together.
>>>>>
>>>>>I haven't seen many comments, so the assumption is 
>>>>
>>either that no
>>
>>>>>one cares, or that folks have read it and have no issues.
>>>>>
>>>>>I'd like to get a reading on whether this doc is ready to be a
>>>>>CCAMP WG document.  Please respond (preferably publicly) 
>>>>
>>>>with one of:
>>>>
>>>>> - "I have read this document and it is ready to be a CCAMP 
>>>>
>>>>WG doc" OR
>>>>
>>>>> - "I have read this document, and it isn't ready to be a 
>>>>
>>>>CCAMP doc".
>>>>
>>>>>Note that if there aren't enough responses, the default 
>>>>
>>>>assumption is
>>>>
>>>>>that the document is either not of interest or not ready, and in
>>>>>either case will not become a CCAMP WG doc.  Note too 
>>>>
>>>that this doc
>>>
>>>>>is an attempt to bridge some gaps between the IETF and 
>>>>
>>the ITU-T,
>>
>>>>>and as such is fairly important.  It would be useful to give an
>>>>>update on its status at the interim T1X1 meeting in June.
>>>>>
>>>>>Please get your responses in by COB Friday May 16th.
>>>>>
>>>>>Thanks,
>>>>>Kireeti.
>>>>>
>>>>
> 

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

Delivery-date: Tue, 13 May 2003 12:23:02 +0000
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Varma, Eve L (Eve)" <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 08:21:59 -0400

Hi,

Yes, I saw the reference.  But that seems to be the extent of
it in actual discussions. 

Best regards,
Eve

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, May 13, 2003 8:27 AM
To: Varma, Eve L (Eve)
Cc: 'Adrian Farrel'; Stephen Trowbridge; [email-masked]
Subject: Re: ASON reqts

eve, please take a closer look at the references:

"4. Requirements for Extending Applicability of GMPLS to ASON

    The applicability statements regarding how the GMPLS suite of
    protocols may be applied to the ASON architecture can be found in
    [IPO-ASON] and [IPO-REQS].

[...]

    [IPO-REQS]     Y.Xue (Editor) et al., "Optical Network Service
                   Requirements," Work in progress, draft-ietf-ipo-
                   carrier-requirements-05.txt."

thanks,
- dimitri.

Varma, Eve L (Eve) wrote:
> Hi all,
> 
> I concur with Zhi that the document is not yet ready to be a WG document.
> 
> Regarding the explanation of requirements, I am still extremely puzzled as
> to why the IPO requirements document is not being cited as a source of
> explanation for a number of ASON-related items.  It's almost as though it never existed.
> 
> Best regards,
> Eve
> 
> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, May 12, 2003 6:53 PM
> To: Stephen Trowbridge; [email-masked]
> Subject: Re: ASON reqts
> 
> 
> 
>>John,
>>Ahhhh....
>>This sounds like a whole new can of worms. The goal therefore does
>>seem to be to develop yet another protocol solution, and I think
>>we need to be VERY careful before taking this kind of step.
> 
> 
> Steve,
> As one of the authors this is not my goal.
> It may transpire that this is a necessity, but it is not a goal.
> I apologise if anything I said gave rise to the false impression you have
> garnered.
> 
> One of the problems from an IETF-participant viewpoint is/was that the
> requirements were not clear to me. If they weren't clear to me this may because
> - they were not readily accessible to me within the IETF
> - they were not couched in terms and formats with which I am familiar
> - I am a dunderhead.
> 
> Only with the requirements clearly stated (in a form I can grok) is it possible
> for me to decide whether existing solutions are adequate.
> 
> So the requirements draft is written and ITU-aware people are asked to comment
> on whether this seems to them a fair representation of the requirements coming
> out of the ITU.
> 
> OK up to this point?
> 
> The next step, is the analysis of whether the requirements have already been
> met.
> A subsequent draft has been written to identify how the signaling requirements
> are or are not met by existing protocols :
> draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
> Where they are already met, the draft simply points out to another draft.
> Where they are not met, the draft explains the short-comings and offers
> solutions.
> 
> This *second* draft I would expect to be the one that causes heart-burn. It is
> with the second draft that we can take issue - does it solve the problems? is it
> correct when it says other solutions are broken? etc.  But the second draft is
> still in an early stage and is not being proposed for WG adoption (although we
> would still welcome comments on it).
> 
> 
>>Your assertion now seems to be that RFC 3473+3474 does NOT meet the
>>ASON requirements. If this is the case:
>>- Does G.7713.2 meet the requirements, and we missed something in
>>  the translation to RFC 3474? If so, then we need to supercede
>>  RFC 3474 with a better translation, not start over.
> 
> 
> Cannot answer this without an agreement on the requirements.
> 
> 
>>- Do you think that even G.7713.2 does not meet the requirements?
> 
> 
> Ditto.
> 
> 
>>  If you believe this to be the case, it seems like the obvious
>>  first step would be to inform ITU-T - after all, this is where
>>  the ASON requirements came from and it makes no sense to start
>>  a new protocol without fixing (and aligning) G.7713.2.
> 
> 
> It would certainly make sense to take the ASON reqts draft to ITU-T to formally
> request that they confirm that it is a full documentation of the requirements. I
> don't suppose Kireeti can do this unless the draft is a WG draft.
> 
> 
>>If we made a mistake, lets fix it, but lets NOT start proliferating
>>ASON extensions take 2; ASON extensions take 3; ...
> 
> 
> Depends on the scale of the mistake?
> Can we do the analysis step by step and discover what (if anything) needs to be
> done?
> First step - check we're all in synch on the requirements.
> 
> Cheers,
> Adrian
> 
> 
> 

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

Delivery-date: Tue, 13 May 2003 12:22:13 +0000
From: [email-masked]
Sensitivity: 
Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked], [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
Date: Tue, 13 May 2003 14:21:02 +0200

Fine, send it as is.

Bart.

Delivery-date: Tue, 13 May 2003 12:21:46 +0000
Date: Tue, 13 May 2003 14:27:09 +0200
From: [email-masked]
To: "Varma, Eve L (Eve)" <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

eve, please take a closer look at the references:

"4. Requirements for Extending Applicability of GMPLS to ASON

    The applicability statements regarding how the GMPLS suite of
    protocols may be applied to the ASON architecture can be found in
    [IPO-ASON] and [IPO-REQS].

[...]

    [IPO-REQS]     Y.Xue (Editor) et al., "Optical Network Service
                   Requirements," Work in progress, draft-ietf-ipo-
                   carrier-requirements-05.txt."

thanks,
- dimitri.

Varma, Eve L (Eve) wrote:
> Hi all,
> 
> I concur with Zhi that the document is not yet ready to be a WG document.
> 
> Regarding the explanation of requirements, I am still extremely puzzled as
> to why the IPO requirements document is not being cited as a source of
> explanation for a number of ASON-related items.  It's almost as though it never existed.
> 
> Best regards,
> Eve
> 
> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, May 12, 2003 6:53 PM
> To: Stephen Trowbridge; [email-masked]
> Subject: Re: ASON reqts
> 
> 
> 
>>John,
>>Ahhhh....
>>This sounds like a whole new can of worms. The goal therefore does
>>seem to be to develop yet another protocol solution, and I think
>>we need to be VERY careful before taking this kind of step.
> 
> 
> Steve,
> As one of the authors this is not my goal.
> It may transpire that this is a necessity, but it is not a goal.
> I apologise if anything I said gave rise to the false impression you have
> garnered.
> 
> One of the problems from an IETF-participant viewpoint is/was that the
> requirements were not clear to me. If they weren't clear to me this may because
> - they were not readily accessible to me within the IETF
> - they were not couched in terms and formats with which I am familiar
> - I am a dunderhead.
> 
> Only with the requirements clearly stated (in a form I can grok) is it possible
> for me to decide whether existing solutions are adequate.
> 
> So the requirements draft is written and ITU-aware people are asked to comment
> on whether this seems to them a fair representation of the requirements coming
> out of the ITU.
> 
> OK up to this point?
> 
> The next step, is the analysis of whether the requirements have already been
> met.
> A subsequent draft has been written to identify how the signaling requirements
> are or are not met by existing protocols :
> draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
> Where they are already met, the draft simply points out to another draft.
> Where they are not met, the draft explains the short-comings and offers
> solutions.
> 
> This *second* draft I would expect to be the one that causes heart-burn. It is
> with the second draft that we can take issue - does it solve the problems? is it
> correct when it says other solutions are broken? etc.  But the second draft is
> still in an early stage and is not being proposed for WG adoption (although we
> would still welcome comments on it).
> 
> 
>>Your assertion now seems to be that RFC 3473+3474 does NOT meet the
>>ASON requirements. If this is the case:
>>- Does G.7713.2 meet the requirements, and we missed something in
>>  the translation to RFC 3474? If so, then we need to supercede
>>  RFC 3474 with a better translation, not start over.
> 
> 
> Cannot answer this without an agreement on the requirements.
> 
> 
>>- Do you think that even G.7713.2 does not meet the requirements?
> 
> 
> Ditto.
> 
> 
>>  If you believe this to be the case, it seems like the obvious
>>  first step would be to inform ITU-T - after all, this is where
>>  the ASON requirements came from and it makes no sense to start
>>  a new protocol without fixing (and aligning) G.7713.2.
> 
> 
> It would certainly make sense to take the ASON reqts draft to ITU-T to formally
> request that they confirm that it is a full documentation of the requirements. I
> don't suppose Kireeti can do this unless the draft is a WG draft.
> 
> 
>>If we made a mistake, lets fix it, but lets NOT start proliferating
>>ASON extensions take 2; ASON extensions take 3; ...
> 
> 
> Depends on the scale of the mistake?
> Can we do the analysis step by step and discover what (if anything) needs to be
> done?
> First step - check we're all in synch on the requirements.
> 
> Cheers,
> Adrian
> 
> 
> 

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

Delivery-date: Tue, 13 May 2003 12:08:20 +0000
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, John Drake <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 08:07:24 -0400

Hi,

I'll give you one example - clarifications related to the discussion of domains, interfaces, and reference points, which has been at the heart of many a discussion.  This clarification comes from G.8080 Amendment 1, and is extremely helpful in understanding the concept and its applicability.

Specifically, some additional text is needed to expand upon the
discussion of reference points & domains in the second paragraph of "Problem Statement", reproduced below:
"The ASON control plane specification is meant to be applicable to different transport technologies (e.g., SDH/SONET, OTN) in various
networking environments (e.g., inter-carrier, intra-carrier). Also, ASON model distinguishes reference points (representing points of protocol information exchange) defined (1) between an administrative domain and a user (2) between administrative domains and (3) between areas of the same administrative domain and when needed between control components (or simply controllers) within areas. A full description of the ASON terms and relationship between ASON model and GMPLS protocol suite may be found in [IPO-ASON]."

The proposed expanded text is as follows:

"The ASON control plane specification is meant to be applicable to different transport technologies (e.g., SDH/SONET, OTN) in various networking environments, and to support a range of business models. As Automatically Switched Optical Networks (ASONs) are deployed into new and existing networks, it cannot be assumed that such networks will be homogeneous (e.g., with respect to transport technologies, vendors, approach to management/control). This is true even within a single carrier's network. In order to support deployment of an optical control plane into a heterogeneous environment, the ASON model introduces the concept of control domains and associated inter- and intra-domain reference points.

A control domain is an architectural construct that provides for encapsulation and information hiding, with the characteristics of the control domain identical to those of its constituent architectural components. The UNI and E-NNI reference points are defined to exist between control domains, while the I-NNI reference point is defined as existing within a control domain. The nature of the information exchanged between control domains across the E-NNI reference point captures the common semantics of the information exchanged amongst its constituent components, while allowing for different representations inside each control domain. The reference points are realized as interfaces when instantiated by signaling and routing protocols as appropriate (i.e., no routing information is exchanged over the UNI reference point).  Further description of the ASON model and GMPLS protocol suite may be found in [IPO-ASON]".

Eve

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Monday, May 12, 2003 7:09 PM
To: Stephen Trowbridge; John Drake
Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
Subject: Re: ASON reqts

> Back to Bert's original questions:
> > > > > - is there or do we see any conflict?
> - As Zhi said, this is not (yet) fully aligned with ITU-T requirements
>   and should not be advanced to a WG document until it is. However, before
>   we do, I think we need to understand why this is necessary - see below.

Notwithstanding the immediate future of this document (WG or not WG) I would
greatly appreciate a summary of the areas that are deficient.

Thanks,
Adrian

Delivery-date: Tue, 13 May 2003 11:51:27 +0000
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Tue, 13 May 2003 07:50:40 -0400

Hi all,

I concur with Zhi that the document is not yet ready to be a WG document.

Regarding the explanation of requirements, I am still extremely puzzled as
to why the IPO requirements document is not being cited as a source of
explanation for a number of ASON-related items.  It's almost as though it never existed.

Best regards,
Eve

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Monday, May 12, 2003 6:53 PM
To: Stephen Trowbridge; [email-masked]
Subject: Re: ASON reqts

> John,
> Ahhhh....
> This sounds like a whole new can of worms. The goal therefore does
> seem to be to develop yet another protocol solution, and I think
> we need to be VERY careful before taking this kind of step.

Steve,
As one of the authors this is not my goal.
It may transpire that this is a necessity, but it is not a goal.
I apologise if anything I said gave rise to the false impression you have
garnered.

One of the problems from an IETF-participant viewpoint is/was that the
requirements were not clear to me. If they weren't clear to me this may because
- they were not readily accessible to me within the IETF
- they were not couched in terms and formats with which I am familiar
- I am a dunderhead.

Only with the requirements clearly stated (in a form I can grok) is it possible
for me to decide whether existing solutions are adequate.

So the requirements draft is written and ITU-aware people are asked to comment
on whether this seems to them a fair representation of the requirements coming
out of the ITU.

OK up to this point?

The next step, is the analysis of whether the requirements have already been
met.
A subsequent draft has been written to identify how the signaling requirements
are or are not met by existing protocols :
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
Where they are already met, the draft simply points out to another draft.
Where they are not met, the draft explains the short-comings and offers
solutions.

This *second* draft I would expect to be the one that causes heart-burn. It is
with the second draft that we can take issue - does it solve the problems? is it
correct when it says other solutions are broken? etc.  But the second draft is
still in an early stage and is not being proposed for WG adoption (although we
would still welcome comments on it).

> Your assertion now seems to be that RFC 3473+3474 does NOT meet the
> ASON requirements. If this is the case:
> - Does G.7713.2 meet the requirements, and we missed something in
>   the translation to RFC 3474? If so, then we need to supercede
>   RFC 3474 with a better translation, not start over.

Cannot answer this without an agreement on the requirements.

> - Do you think that even G.7713.2 does not meet the requirements?

Ditto.

>   If you believe this to be the case, it seems like the obvious
>   first step would be to inform ITU-T - after all, this is where
>   the ASON requirements came from and it makes no sense to start
>   a new protocol without fixing (and aligning) G.7713.2.

It would certainly make sense to take the ASON reqts draft to ITU-T to formally
request that they confirm that it is a full documentation of the requirements. I
don't suppose Kireeti can do this unless the draft is a WG draft.

> If we made a mistake, lets fix it, but lets NOT start proliferating
> ASON extensions take 2; ASON extensions take 3; ...

Depends on the scale of the mistake?
Can we do the analysis step by step and discover what (if anything) needs to be
done?
First step - check we're all in synch on the requirements.

Cheers,
Adrian

Delivery-date: Tue, 13 May 2003 10:56:52 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Ron Bonica <[email-masked]>, [email-masked]
Subject: RE: draft-ietf-ccamp-tracereq-01.txt
Date: Tue, 13 May 2003 12:55:51 +0200

Looks good to me. Pls submit to internet-drafts.
And I will pick it up for IESG agenda again.

Did the WG members check it too?

Thanks,
Bert 

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]]
> Sent: dinsdag 13 mei 2003 4:20
> To: Wijnen, Bert (Bert); [email-masked]
> Subject: RE: draft-ietf-ccamp-tracereq-01.txt
> 
> 
> Bert,
> 
>   Here is the ping that you requested.
> 
>          Ron
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Wijnen, Bert (Bert)
> > Sent: Monday, April 28, 2003 11:54 PM
> > To: Ron Bonica; [email-masked]; [email-masked]
> > Subject: RE: draft-ietf-ccamp-tracereq-01.txt
> > 
> > 
> > Thanks... busy with other things now. Will check early next week.
> > Pls ping me if I do not answer by say Wed next week.
> > 
> > Thanks,
> > Bert 
> > 
> > > -----Original Message-----
> > > From: Ron Bonica [mailto:[email-masked]]
> > > Sent: maandag 28 april 2003 18:58
> > > To: [email-masked]; [email-masked]
> > > Subject: RE: draft-ietf-ccamp-tracereq-01.txt
> > > 
> > > 
> > > Bert,
> > > 
> > > I have spun a new version of draft-ietf-ccamp-tracereq. It is 
> > > available at
> > > http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-02.txt. 
> > > Please take a
> > > look.
> > > 
> > > If you think that this version addresses the IESG concerns, I 
> > > will post send
> > > it to the draft editor.
> > > 
> > >                                                     Ron
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] 
> [mailto:[email-masked]]On
> > > > Behalf Of Ron Bonica
> > > > Sent: Monday, April 21, 2003 5:51 PM
> > > > To: [email-masked]; [email-masked]
> > > > Subject: RE: draft-ietf-ccamp-tracereq-01.txt
> > > >
> > > >
> > > > Bert,
> > > >
> > > > Sorry to have taken so long to respond. I have been away on 
> > > vacation.
> > > >
> > > > Comments inline.....
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked] 
> [mailto:[email-masked]]On
> > > > > Behalf Of Wijnen, Bert (Bert)
> > > > > Sent: Wednesday, April 16, 2003 9:30 AM
> > > > > To: Ccamp-wg (E-mail)
> > > > > Subject: FW: draft-ietf-ccamp-tracereq-01.txt
> > > > >
> > > > >
> > > > > Please consider these comments and let me know if they
> > > > > wrrant some additional text in the ID.
> > > > >
> > > > > Thanks,
> > > > > Bert
> > > > >
> > > > > >*****  o Tracing Requirements for Generic Tunnels (None)
> > > > > >            <draft-ietf-ccamp-tracereq-01.txt>
> > > > > >         Token: Wijnen, Bert
> > > > > >         Note: New revision Addresses comments.
> > > > > >         Now on IESG agenda for April 17th
> > > > > >         Responsible: Bert
> > > > >
> > > > > 1. this document looks like it might be the union of all the
> > > > >    "i want it to do <foo>" requests. an important part of
> > > > >    requirements documents is knowing what to not require.
> > > > >    do they have any?
> > > >
> > > > This document specifies requirements for a new protocol. It 
> > > specifies
> > > > requirements, primarily, by detailing the required 
> capabilities of
> > > > applications that will use this protocol. The application 
> > > may implement
> > > > some subset of those capabilities. It may also implement a 
> > > superset of
> > > > the required capabilities. However, protocol designers are 
> > > not required
> > > > to consider the additional capabilities when designing 
> the protocol.
> > > >
> > > > I can add some text to this effect.
> > > >
> > > > > 2. i am concerned about the security stuff that 
> they've buried in
> > > > >    their requirements. nothing definite. it seems 
> unwieldy. but
> > > > >    then, so many security things do...
> > > >
> > > > Can you be more specific? Is there any particular 
> requirement that
> > > > you feel cannot be implemented?
> > > >
> > > > > 3. section 4.1 and 4.2 seem to be worded with a particular
> > > > >    implementation in mind. requirements documents ought not
> > > > >    specify solutions (eg, 4.2 talks about udp, why can't i use
> > > > >    icmp?)
> > > >
> > > > Section 4 provides a few protocol requirements, stated 
> as such. In
> > > > particular, Section 4.1 states that the new protocol 
> will consist of
> > > > probes and responses, and that each probe/response pair 
> will reveal
> > > > information regarding a network hop. (In this respect, the 
> > > new protocol
> > > > will resemble TRACEROUTE).
> > > >
> > > > Had I remembered to include an application requirement to 
> > > support partial
> > > > traces through broken paths, this requirement would have 
> > > made much more
> > > > sense!
> > > > I will fix this.
> > > >
> > > > Section 4.2 requires that the protocol be implemented over 
> > > UDP. I included
> > > > this
> > > > section primarily to rule out implmentations that were _not_
> > > > acceptable. For
> > > > example,
> > > > ICMP should not be used, because carrying MPLS information 
> > > over ICMP would
> > > > constitute
> > > > a layer violation. TCP should not be used, because this would
> > > > conflict with
> > > > the protocol's
> > > > requirement for statelessness. Tunnel specific mechanisms 
> > > should not be
> > > > used, because
> > > > this would conflict with the requirement for generality.
> > > >
> > > > This leaves UDP and IP as the two most resonable candidates.
> > > >
> > > > I can add some words indicating how we arrived at this decision.
> > > >
> > > > > 4. justification of requirements might be nice.
> > > > >
> > > >
> > > > I can add a sentence or two after each requirement.
> > > >
> > > >
> > > >
> > > 
> > 
> 

Delivery-date: Tue, 13 May 2003 09:23:28 +0000
From: "Jonathan Lang" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 13:17:33 -0700

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Kireeti,
  I have read this document and it is ready to be a CCAMP WG doc.

Thanks,
Jonathan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kireeti Kompella
> Sent: Monday, May 12, 2003 8:25 AM
> To: [email-masked]
> Subject: Re: ASON reqts
> 
> 
> Hi All,
> 
> On Fri, 2 May 2003, Kireeti Kompella wrote:
> 
> > To take things one at a time, it would be very useful to read and 
> > comment on the ASON reqts draft, as this was deemed tremendously 
> > important, and a rich source of misunderstanding and 
> cross-talk; and 
> > coming to a common understanding over this should help get the IETF 
> > and the ITU working together.
> 
> I haven't seen many comments, so the assumption is either 
> that no one cares, or that folks have read it and have no issues.
> 
> I'd like to get a reading on whether this doc is ready to be 
> a CCAMP WG document.  Please respond (preferably publicly) 
> with one of:
>  - "I have read this document and it is ready to be a CCAMP WG doc" OR
>  - "I have read this document, and it isn't ready to be a CCAMP doc".
> 
> Note that if there aren't enough responses, the default 
> assumption is that the document is either not of interest or 
> not ready, and in either case will not become a CCAMP WG doc. 
>  Note too that this doc is an attempt to bridge some gaps 
> between the IETF and the ITU-T, and as such is fairly 
> important.  It would be useful to give an update on its 
> status at the interim T1X1 meeting in June.
> 
> Please get your responses in by COB Friday May 16th.
> 
> Thanks,
> Kireeti.
> 
> 

Delivery-date: Tue, 13 May 2003 06:40:20 +0000
Date: Tue, 13 May 2003 08:45:52 +0200
From: [email-masked]
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked], [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation

Fine, send it as is.

Kireeti Kompella wrote:
 > Hi All,
 >
 > On Tue, 29 Apr 2003, Kireeti Kompella wrote:
 >
 >
 >>I will formulate a liaison statement in reply to T1X1 regarding
 >>draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list.
 >
 >
 > Sorry for the tardy follow-up.  Here is the proposed response.
 >
 > Please send your replies to the list (if you wish to reply privately,
 > include the Liaison Coordinator and the ADs in your reply).
 >
 > Ideally, your reply should say one of:
 >  - "Fine, send it as is"; OR
 >  - "Please make the following changes", with _specific text_; OR
 >  - "Do not send this response".
 >
 > Please respond by COB Friday, May 16th.
 >
 > Kireeti.
 > =======================================================================
 >
 > Dear Mr. Biholar,
 >
 > Regarding the following liaison:
 >
 > TITLE: Liaison from T1X1 to IETF ccamp regarding
 > 	draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt
 > TO: IETF ccamp Working Group
 > CC: ITU-T Q.14/15 (for information)
 > SOURCE*: T1X1
 > FOR: Action
 > DEADLINE: 9 June 2003
 > PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic 
Interconnection
 >
 > We thank the T1X1 and the ITU-T for their review and the incorporation
 > of the LMP Test procedure into G.7714.1.
 >
 > Based on information contained in the ITU and T1X1 liaison, as well as
 > subsequent e-mail exchanges on the CCAMP mailing list, and in order to
 > ensure proper interoperability in legacy SDH/SONET networks as well as
 > networks in which G.7714.1 is deployed, it will be recommended by the
 > editors to the CCAMP community to support only the Jx trace correlation
 > procedure and not the in-band Jx procedure.  Pending agreement, the
 > draft will be updated.
 >
 > See inline for more detailed responses to specific points.
 >
 >
 >>Context of Application Space
 >
 >
 > <snip>
 >
 >>It is currently our understanding that the use case
 >>scenario for which this procedure is applied encompasses
 >>both transport plane connectivity verification as well as
 >>correlation of these entities with the control plane.
 >>ITU-T G.7714.1 is focused on discovering the transport
 >>plane link connection end point relationships and
 >>verifying their connectivity.
 >>This Recommendation defines two procedures for performing
 >>the connectivity verification function, one of which
 >>utilizes either the Jx or the DCC bytes of the server
 >>signal (termed "in-service"). The other approach in
 >>G.7714.1, termed as "out of service", corresponds to
 >>inserting a test signal in the payload of the server
 >>signal. Based on an analysis of the data link state
 >>definitions in draft-ietf-ccamp-lmp-08.txt, we understand
 >>that the approach defined in the LMP test for physical
 >>connectivity occurs in the context of the "out of service"
 >>state (as described in G.7714.1).
 >>
 >>Please confirm this.
 >
 >
 > The subject document uses the Jx or DCC bytes to perform the LMP
 > Test procedure, but the The LMP Test procedure is done as part of
 > GMPLS link intialization, prior to the link being available to
 > carry user traffic.
 >
 >
 >>Usage of Jx Bytes
 >>
 >>In defining the Jx bytes within G.7714.1, the following
 >>was taken into account:
 >>1. One consideration involved the case where the Discovery
 >>Agent is located in an external system, and an external
 >>interface is used by the Network Element to provision and
 >>receive the Trail Trace message. As an existing text-
 >>oriented Man-Machine Language, such as TL1, may be reused
 >>to provide this interface, it was decided that the
 >>discovery message be limited to printable characters.
 >>Specifically, the TTI characters should be limited to
 >>printable characters as per T.50 with trailing NULLs or
 >>SPACEs. Use of arbitrary bit patterns in the lower 7 bits
 >>of each byte could prematurely terminate the pattern or
 >>trigger fault notification for certain hardware or
 >>software implementations. The strategy chosen in G.7714.1
 >>avoids the danger by limiting the information content of
 >>each byte to 6 bits (84 bits total) and uses a base 64
 >>coding according to RFC2045 to place the information in
 >>the available bits.
 >
 >
 > The LMP test procedure described in the subject document defines
 > two usages of the Jx bytes.  The first is termed the 'trace
 > correlation transport mechanism' and it treats the Jx bytes as
 > an opaque bit stream.
 >
 > This usage is completely consistent with the above.  GMPLS
 > identifiers are typically 32 bit numbers and as such are not
 > printable characters.  In networks that do not require that the
 > Jx bytes be printable, it is also possible to carry the GMPLS
 > identifiers directly in the Jx bytes.  This is termed the 'Jx
 > transport mechanism'.
 >
 >
 >>2. Another consideration involved providing a means for
 >>distinguishing this use of the Jx bytes from the
 >>traditional use for Trail Trace identifiers in new
 >>equipments. As a result, G.7714.1 includes a
 >>distinguishing character ("+") as the first non-CRC byte
 >>that will never appear as the first character of a TTI.
 >>This requires modification of the trail termination
 >>functions to prevent the raising of TTI mismatch
 >>alarms during the connectivity verification process.
 >
 >
 > The selection of which LMP transport mechanism use in the LMP Test
 > procedure for a given link as well as the time at which the Jx
 > bytes are to be used for the LMP Test procedure is under control of
 > the GMPLS nodes at either end of the link, so it is well understood
 > by those nodes.  It is our understanding, per G.806 section 6.1,
 > that the LMP Test procedure would be performed when the link is in
 > the NMON (not monitored state), and therefore intermediate SDH/SONET
 > equipment would not be performing non-intrusive monitoring.
 >
 >
 >>While the context for testing the transport plane
 >>connectivity is different between the two documents, they
 >>both use the Jx bytes of the server signal, and we invite
 >>the IETF to determine the appropriateness of the above
 >>aspects in their test signal definitions.
 >
 >
 > The trace correlation transport mechanism is completely consistent
 > with this.  The JX transport mechanism requires additional
 > identifiers (i.e., the Verify ID).
 >
 >
 >>Even if these considerations are not relevant to this
 >>context, it will be necessary to augment G.783 equipment
 >>functions to recognize this new usage of Jx messages.
 >
 >
 > We would be happy to provide assistance to T1X1/ITU-T in augmenting
 > G.783 equipment functions to recognize the additional capability
 > for supporting GMPLS networking elements.
 >
 >
 >>Required Updates to SDH Equipment Specifications
 >>
 >>SDH equipment specifications as they currently exist reflect
 >>the usage of the Jx bytes prior to the development of
 >>G.7714.1. ITU-T Study Group 15 has as a work item to
 >>revise these equipment functions to include support for
 >>these new functions. Specifically, this will involve
 >>updates to trail termination functions to generate and
 >>receive the new messages and to avoid unnecessary alarms in
 >>the case where the new messages are received.  In addition,
 >>non-intrusive monitoring functions will need to be revised
 >>so that unnecessary alarms are not raised when the
 >>messages are observed en-route.  Whether or not there is
 >>further alignment between the message formats used in
 >>G.7714.1 and the subject draft, the new functions to
 >>support the subject draft will also need to be reflected
 >>in the atomic functions in G.783.  The sending and
 >>receiving of these messages can be reflected in the trail
 >>termination functions in a similar way to what we plan to
 >>do for support of G.7714.1 functions.
 >
 >
 > We would be happy to provide assistance to T1X1/ITU-T in augmenting
 > G.783 equipment functions to recognize the additional capability
 > for supporting GMPLS networking elements.
 >
 >
 >>Terminology Differences
 >
 >
 > <snip>
 >
 >>Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1,
 >>the "up/free (in-service)" data link state appears to
 >>correspond with what G.7714.1 refers to as "out-of-
 >>service".  This difference in terminology has resulted in
 >>different interpretations of the context.  Explaining the
 >>scenarios further in the lmp test document would be
 >>beneficial in establishing a translation between the
 >>differing uses of the same terms.  Within ITU-T, work is
 >>being initiated of draft Rec. G.fame, Framework for ASON
 >>Management, where control plane/management plane
 >>interactions will be addressed.
 >
 >
 > We agree that terminology differences between IETF and ITU-T wrt
 > GMPLS have been confusing.  There is an ongoing effort within
 > CCAMP to work together with T1X1/ITU-T on bridging the terminology
 > gaps.  For example, there is a new Internet draft
 > (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in
 > CCAMP to do this mapping for LMP.
 >
 >
 >>Further Study Items
 >>
 >>Following are some areas where further contributions are
 >>requested:
 >>1.     For SDH equipment functions in G.783, it needs to
 >>be understood whether the application of the lmp test
 >>message requires revision of NIM (non-intrusive
 >>monitoring) functions.  The reason for this is that the
 >>test procedure is initiated between control entities at
 >>the end-points of the trail, and intermediate points are
 >>not necessarily aware that the test is taking place.  For
 >>G.7714.1, it was felt important for any termination or NIM
 >>function to easily distinguish between the various uses of
 >>the Jx bytes.  It may be necessary for the subject draft
 >>to use a similarly easily recognizable format.  If no
 >>revision to NIM functions is required for the context of
 >>this draft, the architecture of the context for this
 >>application (demonstrating why the NIM functions are not
 >>required) should be reflected in G.803 and/or G.807/G.8080.
 >
 >
 > It is our understanding, per G.806 section 6.1, that
 > the LMP Test procedure would be performed when the link is in the
 > NMON (not monitored state), and  therefore intermediate SDH/SONET
 > equipment would not be performing non-intrusive monitoring.
 > As described, the trace correlation procedure use of Jx bytes is
 > consistent with the current standards.
 >
 >
 >>2.Determination of whether it would be possible to use the
 >>identical message formats in the subject draft as in
 >>G.7714.1 for the connectivity verification function.
 >
 >
 > The trace correlation transport mechanism is completely consistent
 > with this.  The Jx transport mechanism requires additional
 > identifiers (i.e., the Verify ID).
 >
 >
 >>3.Determination of whether it would be possible to use the
 >>same overall structure (distinguishing character, 4 bit
 >>message type, 80 bit message body) if a different message
 >>format or information content is required.
 >
 >
 > This is certainly possible (not applicable for the trace correlation
 > procedure).
 >
 >
 >>4.Work is needed to clarify under what
 >>configurations/states (for example: no VC-n signals
 >>carrying client traffic) the lmp test message is
 >>applicable over J0.  If the signal can be framed and J0
 >>can be recovered, the Regenerator Section is considered
 >>as "in service" from a transport plane perspective.  So
 >>unlike the J1/J2 case, the application of the lmp test
 >>message at the Regenerator Section does not occur in an
 >>"out of service" state (from a transport plane
 >>perspective).
 >
 >
 > Section 6.1 of G.806 refers to a "termination function part of a
 > trail, which is in the process of set-up" as in the NMON state.
 > LMP link verification is based on pre-service testing.  Please let
 > us know if we can be of any assistance in updating the appropriate
 > Recommendations to support the GMPLS network element LMP capability.
 > This is not applicable for the trace correlation procedure.
 >
 >
 >>5. Clarification of the usage of transport and control
 >>names for transport resources in the subject draft, as
 >>described in G.8080 Amendment
 >
 >
 > The trace correlation transport mechanism supports a separation of
 > the transport and control plane identifiers.
 >
 >
 >>6. Consideration of the ANSI 64-byte J1.
 >
 >
 > This was mistakenly deleted from the latest version of the draft.
 > This will be included in the next version.
 >
 > Sincerely,
 > Kireeti Kompella and Ron Bonica,
 > Chairs of the CCAMP WG/IETF.
 >

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

Delivery-date: Tue, 13 May 2003 06:39:48 +0000
From: [email-masked]
Sensitivity: 
Subject: Re: ASON reqts
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Date: Tue, 13 May 2003 08:37:33 +0200

I have read this document and it is ready to be a CCAMP WG doc

Bart.

Delivery-date: Tue, 13 May 2003 06:39:37 +0000
Date: Tue, 13 May 2003 08:46:04 +0200
From: [email-masked]
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Proposed change to LMP Link Verification draft

Agree with the above change.

Kireeti Kompella wrote:
 > Hi All,
 >
 > | Based on information contained in the ITU and T1X1 liaison, as well as
 > | subsequent e-mail exchanges on the CCAMP mailing list, and in order to
 > | ensure proper interoperability in legacy SDH/SONET networks as well as
 > | networks in which G.7714.1 is deployed, it will be recommended by the
 > | editors to the CCAMP community to support only the Jx trace correlation
 > | procedure and not the in-band Jx procedure.
 >
 > Please respond with one of the following:
 >  - Agree with above change; OR
 >  - Don't agree with above change [i.e., keep in-band Jx procedure as is].
 >
 > Kireeti.
 >

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

Delivery-date: Tue, 13 May 2003 05:44:56 +0000
From: Manoj Agiwal <[email-masked]>
To: "'Ccamp (E-mail)" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: FW: LMP Message ID
Date: Tue, 13 May 2003 00:37:18 -0500

Hi ,
      Lmp drafts tells that Message ID should be monotonically increasing .
    
      Section 7 also tells that "Unacknowledge messages sent with Message_id
object should be retransmitted until the message is 
      acknowledged or until retry limit is reached."

      Do we have to sent all retransmitted messages with the same Message Id
as sent previously or it should be in monotonically
      increasing order.

Regards ,
Manoj

Delivery-date: Tue, 13 May 2003 02:23:07 +0000
Date: Mon, 12 May 2003 22:19:43 -0400
From: Ron Bonica <[email-masked]>
Subject: RE: draft-ietf-ccamp-tracereq-01.txt
To: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]

Bert,

  Here is the ping that you requested.

         Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Wijnen, Bert (Bert)
> Sent: Monday, April 28, 2003 11:54 PM
> To: Ron Bonica; [email-masked]; [email-masked]
> Subject: RE: draft-ietf-ccamp-tracereq-01.txt
> 
> 
> Thanks... busy with other things now. Will check early next week.
> Pls ping me if I do not answer by say Wed next week.
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Ron Bonica [mailto:[email-masked]]
> > Sent: maandag 28 april 2003 18:58
> > To: [email-masked]; [email-masked]
> > Subject: RE: draft-ietf-ccamp-tracereq-01.txt
> > 
> > 
> > Bert,
> > 
> > I have spun a new version of draft-ietf-ccamp-tracereq. It is 
> > available at
> > http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-02.txt. 
> > Please take a
> > look.
> > 
> > If you think that this version addresses the IESG concerns, I 
> > will post send
> > it to the draft editor.
> > 
> >                                                     Ron
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Ron Bonica
> > > Sent: Monday, April 21, 2003 5:51 PM
> > > To: [email-masked]; [email-masked]
> > > Subject: RE: draft-ietf-ccamp-tracereq-01.txt
> > >
> > >
> > > Bert,
> > >
> > > Sorry to have taken so long to respond. I have been away on 
> > vacation.
> > >
> > > Comments inline.....
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On
> > > > Behalf Of Wijnen, Bert (Bert)
> > > > Sent: Wednesday, April 16, 2003 9:30 AM
> > > > To: Ccamp-wg (E-mail)
> > > > Subject: FW: draft-ietf-ccamp-tracereq-01.txt
> > > >
> > > >
> > > > Please consider these comments and let me know if they
> > > > wrrant some additional text in the ID.
> > > >
> > > > Thanks,
> > > > Bert
> > > >
> > > > >*****  o Tracing Requirements for Generic Tunnels (None)
> > > > >            <draft-ietf-ccamp-tracereq-01.txt>
> > > > >         Token: Wijnen, Bert
> > > > >         Note: New revision Addresses comments.
> > > > >         Now on IESG agenda for April 17th
> > > > >         Responsible: Bert
> > > >
> > > > 1. this document looks like it might be the union of all the
> > > >    "i want it to do <foo>" requests. an important part of
> > > >    requirements documents is knowing what to not require.
> > > >    do they have any?
> > >
> > > This document specifies requirements for a new protocol. It 
> > specifies
> > > requirements, primarily, by detailing the required capabilities of
> > > applications that will use this protocol. The application 
> > may implement
> > > some subset of those capabilities. It may also implement a 
> > superset of
> > > the required capabilities. However, protocol designers are 
> > not required
> > > to consider the additional capabilities when designing the protocol.
> > >
> > > I can add some text to this effect.
> > >
> > > > 2. i am concerned about the security stuff that they've buried in
> > > >    their requirements. nothing definite. it seems unwieldy. but
> > > >    then, so many security things do...
> > >
> > > Can you be more specific? Is there any particular requirement that
> > > you feel cannot be implemented?
> > >
> > > > 3. section 4.1 and 4.2 seem to be worded with a particular
> > > >    implementation in mind. requirements documents ought not
> > > >    specify solutions (eg, 4.2 talks about udp, why can't i use
> > > >    icmp?)
> > >
> > > Section 4 provides a few protocol requirements, stated as such. In
> > > particular, Section 4.1 states that the new protocol will consist of
> > > probes and responses, and that each probe/response pair will reveal
> > > information regarding a network hop. (In this respect, the 
> > new protocol
> > > will resemble TRACEROUTE).
> > >
> > > Had I remembered to include an application requirement to 
> > support partial
> > > traces through broken paths, this requirement would have 
> > made much more
> > > sense!
> > > I will fix this.
> > >
> > > Section 4.2 requires that the protocol be implemented over 
> > UDP. I included
> > > this
> > > section primarily to rule out implmentations that were _not_
> > > acceptable. For
> > > example,
> > > ICMP should not be used, because carrying MPLS information 
> > over ICMP would
> > > constitute
> > > a layer violation. TCP should not be used, because this would
> > > conflict with
> > > the protocol's
> > > requirement for statelessness. Tunnel specific mechanisms 
> > should not be
> > > used, because
> > > this would conflict with the requirement for generality.
> > >
> > > This leaves UDP and IP as the two most resonable candidates.
> > >
> > > I can add some words indicating how we arrived at this decision.
> > >
> > > > 4. justification of requirements might be nice.
> > > >
> > >
> > > I can add a sentence or two after each requirement.
> > >
> > >
> > >
> > 
> 

Delivery-date: Tue, 13 May 2003 00:56:11 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>, John Drake <[email-masked]>
Cc: "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 17:58:05 -0700

Hi Folks,

I'm hoping that the requirements draft does not imply that 
we will now define an alternative to 3474, that was not my
intention when participating in the draft.  I see no reason
to rethink what was done in 3474, which has now been 
implemented and tested by a number of participants.

It would be good to understand if people in the group are
interested in supporting ASON, however, which seemed to be
a controversial issue on the mailing list a while back.
Also, as Stephen points out, it would be good to get
feedback from ITU SG 15 on the draft, as it does represent
only the authors' interpretation of ASON requirements and
may not be complete.

Cheers,

Lyndon

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Monday, May 12, 2003 3:23 PM
To: John Drake
Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
Subject: Re: ASON reqts

John,
Ahhhh....
This sounds like a whole new can of worms. The goal therefore does
seem to be to develop yet another protocol solution, and I think
we need to be VERY careful before taking this kind of step.

Your assertion now seems to be that RFC 3473+3474 does NOT meet the
ASON requirements. If this is the case:
- Does G.7713.2 meet the requirements, and we missed something in
  the translation to RFC 3474? If so, then we need to supercede
  RFC 3474 with a better translation, not start over.

- Do you think that even G.7713.2 does not meet the requirements?
  If you believe this to be the case, it seems like the obvious
  first step would be to inform ITU-T - after all, this is where
  the ASON requirements came from and it makes no sense to start
  a new protocol without fixing (and aligning) G.7713.2.

If we made a mistake, lets fix it, but lets NOT start proliferating
ASON extensions take 2; ASON extensions take 3; ...

Regards,
Steve

John Drake wrote:
> 
> I think that the problem is that RFC 3474, in addition to its technical
> issues, doesn't address all of the ASON requirements.  For example, it does
> not address full call/connection separation.  So we're following the post
> 3474 procees of documenting the ASON requirements relevant to GMPLS
> signalling in order to have a common understanding of what problem is to be
> solved.
> 
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Monday, May 12, 2003 2:27 PM
> > To: John Drake
> > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> > Subject: Re: ASON reqts
> >
> >
> > Bert & John,
> > I think this document has nothing to do with the issue Bert
> > mentioned. This was a protocol issue, not a requirements issue.
> > A decision was made to leave the message out of 3474 with the
> > belief that:
> > - The protocol works without it; and
> > - The presence of the message violates the protocol.
> > The appropriate next step here would be a liaison back to ITU-T
> > explaining what was done and why, and if the ITU-T agrees with
> > the reasoning, they can align their protocol document (in this
> > case, G.7713.2).
> >
> > Back to Bert's original questions:
> > > > > > - is there or do we see any conflict?
> > - As Zhi said, this is not (yet) fully aligned with ITU-T requirements
> >   and should not be advanced to a WG document until it is.
> > However, before
> >   we do, I think we need to understand why this is necessary
> > - see below.
> >
> > > > > > - are we duplicating some work?
> > - Almost certainly. If we take the kind of alignment with ITU-T
> >   requirements that Zhi mentions as a "gate" for progressing
> > this, then
> >   what is in this document that is different from G.8080 and
> > G.7713 and
> >   why do we need this in place of a normative reference?
> >
> > > > > > - what is the purpose of this draft?
> > Excellent question.
> > > > > >   - is it after the fact documenting of requirements?
> > If it is, why bother? Also, we already have the requirements
> > (developed
> > before the protocol) in G.8080 and G.7713.
> >
> > > > > >   - is it getting ITU-T documented requirements in RFC form?
> > This could be a reasonable goal, if this document is to be an info
> > track requirements document characterizing G.8080 and G.7713 for
> > IETF folks in the same way that RFC 3474 does for G.7713.2 and
> > RFC 3475 does for G.7713.3. But it is hard to understand why producing
> > an IETF translation of the ITU-T question would be very high priority
> > when we already have an IETF translation of the answer, but
> > fundamentally
> > there would be no problem if this were the objective.
> >
> > > > > >   - is it extending ITU-T documented requirements?
> > I don't think so. If it is, I hope we start with a liaison rather
> > than trying to extend ITU-T requirements without talking to
> > ITU-T first.
> >
> > > > > >   - is it contrdicting them?
> > This is my biggest worry. I don't think we should start the process
> > over again and open the door that we come up with yet another
> > protocol solution to address the same requirements. Vendors are
> > already building to G.7713.2, G.7713.3 (and by extension, to
> > RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT
> > start a new work item with an objective to develop a new protocol
> > solution to the same problem.
> >
> > > > > >   - is it meant to be used as communication to ITU?
> > I haven't seen this proposed, but I think that if the goal is
> > to capture ITU-T requirements in RFC form, it would be a good
> > idea to ask ITU-T whether the proposed document accurately
> > captures their requirements.
> >
> > /Steve
> >
> >
> > John Drake wrote:
> > >
> > > Bert,
> > >
> > > I think so.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > Sent: Monday, May 12, 2003 1:27 PM
> > > > To: John Drake; Kireeti Kompella; [email-masked]
> > > > Subject: RE: ASON reqts
> > > >
> > > >
> > > > I know that some people had issues with the way that ITU-T
> > > > had defined the RSVP-TE extensions for ASON. In fact there
> > > > was/is a claim that it is broken. So we removed the offending
> > > > text from the RFC3474.
> > > >
> > > > The next thing we were going to do (as far as I understood it)
> > > > is to document why we (or some of us in IETF) think that the
> > > > ITU-T solution is broken, potentially with suggested fixes.
> > > > That we would send to ITU-T SG15.
> > > >
> > > > Is this the first step of that process?
> > > >
> > > > Thanks,
> > > > Bert
> > > >
> > > > > -----Original Message-----
> > > > > From: John Drake [mailto:[email-masked]]
> > > > > Sent: maandag 12 mei 2003 22:24
> > > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> > > > > Subject: RE: ASON reqts
> > > > >
> > > > >
> > > > > Bert,
> > > > >
> > > > > I thought that the post 3474/3475 process started with a
> > > > requirements
> > > > > document.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > John
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > > > Sent: Monday, May 12, 2003 1:14 PM
> > > > > > To: Kireeti Kompella; [email-masked]
> > > > > > Subject: RE: ASON reqts
> > > > > >
> > > > > >
> > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents
> > > > > > that those 2 RFCs point to, then I wonder:
> > > > > > - is there or do we see any conflict?
> > > > > > - are we duplicating some work?
> > > > > > - what is the purpose of this draft?
> > > > > >   - is it after the fact documenting of requirements?
> > > > > >   - is it getting ITU-T documented requirements in RFC form?
> > > > > >   - is it extending ITU-T documented requirements?
> > > > > >   - is it contrdicting them?
> > > > > >   - is it meant to be used as communication to ITU?
> > > > > >
> > > > > > Just wondering what is happening here.
> > > > > >
> > > > > > Thanks,
> > > > > > Bert
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Kireeti Kompella [mailto:[email-masked]]
> > > > > > > Sent: maandag 12 mei 2003 17:25
> > > > > > > To: [email-masked]
> > > > > > > Subject: Re: ASON reqts
> > > > > > >
> > > > > > >
> > > > > > > Hi All,
> > > > > > >
> > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > > > > > >
> > > > > > > > To take things one at a time, it would be very useful to
> > > > > > > read and comment
> > > > > > > > on the ASON reqts draft, as this was deemed tremendously
> > > > > > > important, and
> > > > > > > > a rich source of misunderstanding and cross-talk; and
> > > > > > > coming to a common
> > > > > > > > understanding over this should help get the IETF and the
> > > > > > ITU working
> > > > > > > > together.
> > > > > > >
> > > > > > > I haven't seen many comments, so the assumption is
> > > > either that no
> > > > > > > one cares, or that folks have read it and have no issues.
> > > > > > >
> > > > > > > I'd like to get a reading on whether this doc is
> > ready to be a
> > > > > > > CCAMP WG document.  Please respond (preferably publicly)
> > > > > > with one of:
> > > > > > >  - "I have read this document and it is ready to be a CCAMP
> > > > > > WG doc" OR
> > > > > > >  - "I have read this document, and it isn't ready to be a
> > > > > > CCAMP doc".
> > > > > > >
> > > > > > > Note that if there aren't enough responses, the default
> > > > > > assumption is
> > > > > > > that the document is either not of interest or not
> > ready, and in
> > > > > > > either case will not become a CCAMP WG doc.  Note too
> > > > > that this doc
> > > > > > > is an attempt to bridge some gaps between the IETF and
> > > > the ITU-T,
> > > > > > > and as such is fairly important.  It would be
> > useful to give an
> > > > > > > update on its status at the interim T1X1 meeting in June.
> > > > > > >
> > > > > > > Please get your responses in by COB Friday May 16th.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Kireeti.
> > > > > > >
> > > > > >
> > > > >
> > > >
> >

Envelope-to: [email-masked]
Delivery-date: Mon, 12 May 2003 23:10:20 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Stephen Trowbridge" <[email-masked]>, "John Drake" <[email-masked]>
Cc: "'Wijnen, Bert (Bert)'" <[email-masked]>, "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Subject: Re: ASON reqts
Date: Mon, 12 May 2003 19:09:25 -0400

> Back to Bert's original questions:
> > > > > - is there or do we see any conflict?
> - As Zhi said, this is not (yet) fully aligned with ITU-T requirements
>   and should not be advanced to a WG document until it is. However, before
>   we do, I think we need to understand why this is necessary - see below.

Notwithstanding the immediate future of this document (WG or not WG) I would
greatly appreciate a summary of the areas that are deficient.

Thanks,
Adrian

Envelope-to: [email-masked]
Delivery-date: Mon, 12 May 2003 22:53:39 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Stephen Trowbridge" <[email-masked]>, <[email-masked]>
Subject: Re: ASON reqts
Date: Mon, 12 May 2003 18:52:52 -0400

> John,
> Ahhhh....
> This sounds like a whole new can of worms. The goal therefore does
> seem to be to develop yet another protocol solution, and I think
> we need to be VERY careful before taking this kind of step.

Steve,
As one of the authors this is not my goal.
It may transpire that this is a necessity, but it is not a goal.
I apologise if anything I said gave rise to the false impression you have
garnered.

One of the problems from an IETF-participant viewpoint is/was that the
requirements were not clear to me. If they weren't clear to me this may because
- they were not readily accessible to me within the IETF
- they were not couched in terms and formats with which I am familiar
- I am a dunderhead.

Only with the requirements clearly stated (in a form I can grok) is it possible
for me to decide whether existing solutions are adequate.

So the requirements draft is written and ITU-aware people are asked to comment
on whether this seems to them a fair representation of the requirements coming
out of the ITU.

OK up to this point?

The next step, is the analysis of whether the requirements have already been
met.
A subsequent draft has been written to identify how the signaling requirements
are or are not met by existing protocols :
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
Where they are already met, the draft simply points out to another draft.
Where they are not met, the draft explains the short-comings and offers
solutions.

This *second* draft I would expect to be the one that causes heart-burn. It is
with the second draft that we can take issue - does it solve the problems? is it
correct when it says other solutions are broken? etc.  But the second draft is
still in an early stage and is not being proposed for WG adoption (although we
would still welcome comments on it).

> Your assertion now seems to be that RFC 3473+3474 does NOT meet the
> ASON requirements. If this is the case:
> - Does G.7713.2 meet the requirements, and we missed something in
>   the translation to RFC 3474? If so, then we need to supercede
>   RFC 3474 with a better translation, not start over.

Cannot answer this without an agreement on the requirements.

> - Do you think that even G.7713.2 does not meet the requirements?

Ditto.

>   If you believe this to be the case, it seems like the obvious
>   first step would be to inform ITU-T - after all, this is where
>   the ASON requirements came from and it makes no sense to start
>   a new protocol without fixing (and aligning) G.7713.2.

It would certainly make sense to take the ASON reqts draft to ITU-T to formally
request that they confirm that it is a full documentation of the requirements. I
don't suppose Kireeti can do this unless the draft is a WG draft.

> If we made a mistake, lets fix it, but lets NOT start proliferating
> ASON extensions take 2; ASON extensions take 3; ...

Depends on the scale of the mistake?
Can we do the analysis step by step and discover what (if anything) needs to be
done?
First step - check we're all in synch on the requirements.

Cheers,
Adrian

Delivery-date: Mon, 12 May 2003 22:31:27 +0000
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 15:30:52 -0700

> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Monday, May 12, 2003 3:23 PM
> To: John Drake
> Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> Subject: Re: ASON reqts
> 
> 
> John,
> Ahhhh....
> This sounds like a whole new can of worms. The goal therefore does
> seem to be to develop yet another protocol solution, and I think
> we need to be VERY careful before taking this kind of step.
> 
> Your assertion now seems to be that RFC 3473+3474 does NOT meet the
> ASON requirements.

JD:  Actually that was my position all along.

> If this is the case:
> - Does G.7713.2 meet the requirements, and we missed something in
>   the translation to RFC 3474? If so, then we need to supercede
>   RFC 3474 with a better translation, not start over.

JD:  Excellent, glad you're on board

> 
> - Do you think that even G.7713.2 does not meet the requirements?
>   If you believe this to be the case, it seems like the obvious
>   first step would be to inform ITU-T - after all, this is where
>   the ASON requirements came from and it makes no sense to start
>   a new protocol without fixing (and aligning) G.7713.2.
> 
> If we made a mistake, lets fix it, but lets NOT start proliferating
> ASON extensions take 2; ASON extensions take 3; ...
> 
> Regards,
> Steve
> 
> John Drake wrote:
> > 
> > I think that the problem is that RFC 3474, in addition to 
> its technical
> > issues, doesn't address all of the ASON requirements.  For 
> example, it does
> > not address full call/connection separation.  So we're 
> following the post
> > 3474 procees of documenting the ASON requirements relevant to GMPLS
> > signalling in order to have a common understanding of what 
> problem is to be
> > solved.
> > 
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > Sent: Monday, May 12, 2003 2:27 PM
> > > To: John Drake
> > > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> > > Subject: Re: ASON reqts
> > >
> > >
> > > Bert & John,
> > > I think this document has nothing to do with the issue Bert
> > > mentioned. This was a protocol issue, not a requirements issue.
> > > A decision was made to leave the message out of 3474 with the
> > > belief that:
> > > - The protocol works without it; and
> > > - The presence of the message violates the protocol.
> > > The appropriate next step here would be a liaison back to ITU-T
> > > explaining what was done and why, and if the ITU-T agrees with
> > > the reasoning, they can align their protocol document (in this
> > > case, G.7713.2).
> > >
> > > Back to Bert's original questions:
> > > > > > > - is there or do we see any conflict?
> > > - As Zhi said, this is not (yet) fully aligned with ITU-T 
> requirements
> > >   and should not be advanced to a WG document until it is.
> > > However, before
> > >   we do, I think we need to understand why this is necessary
> > > - see below.
> > >
> > > > > > > - are we duplicating some work?
> > > - Almost certainly. If we take the kind of alignment with ITU-T
> > >   requirements that Zhi mentions as a "gate" for progressing
> > > this, then
> > >   what is in this document that is different from G.8080 and
> > > G.7713 and
> > >   why do we need this in place of a normative reference?
> > >
> > > > > > > - what is the purpose of this draft?
> > > Excellent question.
> > > > > > >   - is it after the fact documenting of requirements?
> > > If it is, why bother? Also, we already have the requirements
> > > (developed
> > > before the protocol) in G.8080 and G.7713.
> > >
> > > > > > >   - is it getting ITU-T documented requirements 
> in RFC form?
> > > This could be a reasonable goal, if this document is to be an info
> > > track requirements document characterizing G.8080 and G.7713 for
> > > IETF folks in the same way that RFC 3474 does for G.7713.2 and
> > > RFC 3475 does for G.7713.3. But it is hard to understand 
> why producing
> > > an IETF translation of the ITU-T question would be very 
> high priority
> > > when we already have an IETF translation of the answer, but
> > > fundamentally
> > > there would be no problem if this were the objective.
> > >
> > > > > > >   - is it extending ITU-T documented requirements?
> > > I don't think so. If it is, I hope we start with a liaison rather
> > > than trying to extend ITU-T requirements without talking to
> > > ITU-T first.
> > >
> > > > > > >   - is it contrdicting them?
> > > This is my biggest worry. I don't think we should start 
> the process
> > > over again and open the door that we come up with yet another
> > > protocol solution to address the same requirements. Vendors are
> > > already building to G.7713.2, G.7713.3 (and by extension, to
> > > RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT
> > > start a new work item with an objective to develop a new protocol
> > > solution to the same problem.
> > >
> > > > > > >   - is it meant to be used as communication to ITU?
> > > I haven't seen this proposed, but I think that if the goal is
> > > to capture ITU-T requirements in RFC form, it would be a good
> > > idea to ask ITU-T whether the proposed document accurately
> > > captures their requirements.
> > >
> > > /Steve
> > >
> > >
> > > John Drake wrote:
> > > >
> > > > Bert,
> > > >
> > > > I think so.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > > -----Original Message-----
> > > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > > Sent: Monday, May 12, 2003 1:27 PM
> > > > > To: John Drake; Kireeti Kompella; [email-masked]
> > > > > Subject: RE: ASON reqts
> > > > >
> > > > >
> > > > > I know that some people had issues with the way that ITU-T
> > > > > had defined the RSVP-TE extensions for ASON. In fact there
> > > > > was/is a claim that it is broken. So we removed the offending
> > > > > text from the RFC3474.
> > > > >
> > > > > The next thing we were going to do (as far as I understood it)
> > > > > is to document why we (or some of us in IETF) think that the
> > > > > ITU-T solution is broken, potentially with suggested fixes.
> > > > > That we would send to ITU-T SG15.
> > > > >
> > > > > Is this the first step of that process?
> > > > >
> > > > > Thanks,
> > > > > Bert
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: John Drake [mailto:[email-masked]]
> > > > > > Sent: maandag 12 mei 2003 22:24
> > > > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; 
> [email-masked]
> > > > > > Subject: RE: ASON reqts
> > > > > >
> > > > > >
> > > > > > Bert,
> > > > > >
> > > > > > I thought that the post 3474/3475 process started with a
> > > > > requirements
> > > > > > document.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > John
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > > > > Sent: Monday, May 12, 2003 1:14 PM
> > > > > > > To: Kireeti Kompella; [email-masked]
> > > > > > > Subject: RE: ASON reqts
> > > > > > >
> > > > > > >
> > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents
> > > > > > > that those 2 RFCs point to, then I wonder:
> > > > > > > - is there or do we see any conflict?
> > > > > > > - are we duplicating some work?
> > > > > > > - what is the purpose of this draft?
> > > > > > >   - is it after the fact documenting of requirements?
> > > > > > >   - is it getting ITU-T documented requirements 
> in RFC form?
> > > > > > >   - is it extending ITU-T documented requirements?
> > > > > > >   - is it contrdicting them?
> > > > > > >   - is it meant to be used as communication to ITU?
> > > > > > >
> > > > > > > Just wondering what is happening here.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Bert
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Kireeti Kompella [mailto:[email-masked]]
> > > > > > > > Sent: maandag 12 mei 2003 17:25
> > > > > > > > To: [email-masked]
> > > > > > > > Subject: Re: ASON reqts
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi All,
> > > > > > > >
> > > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > > > > > > >
> > > > > > > > > To take things one at a time, it would be 
> very useful to
> > > > > > > > read and comment
> > > > > > > > > on the ASON reqts draft, as this was deemed 
> tremendously
> > > > > > > > important, and
> > > > > > > > > a rich source of misunderstanding and cross-talk; and
> > > > > > > > coming to a common
> > > > > > > > > understanding over this should help get the 
> IETF and the
> > > > > > > ITU working
> > > > > > > > > together.
> > > > > > > >
> > > > > > > > I haven't seen many comments, so the assumption is
> > > > > either that no
> > > > > > > > one cares, or that folks have read it and have 
> no issues.
> > > > > > > >
> > > > > > > > I'd like to get a reading on whether this doc is
> > > ready to be a
> > > > > > > > CCAMP WG document.  Please respond (preferably publicly)
> > > > > > > with one of:
> > > > > > > >  - "I have read this document and it is ready 
> to be a CCAMP
> > > > > > > WG doc" OR
> > > > > > > >  - "I have read this document, and it isn't 
> ready to be a
> > > > > > > CCAMP doc".
> > > > > > > >
> > > > > > > > Note that if there aren't enough responses, the default
> > > > > > > assumption is
> > > > > > > > that the document is either not of interest or not
> > > ready, and in
> > > > > > > > either case will not become a CCAMP WG doc.  Note too
> > > > > > that this doc
> > > > > > > > is an attempt to bridge some gaps between the IETF and
> > > > > the ITU-T,
> > > > > > > > and as such is fairly important.  It would be
> > > useful to give an
> > > > > > > > update on its status at the interim T1X1 
> meeting in June.
> > > > > > > >
> > > > > > > > Please get your responses in by COB Friday May 16th.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Kireeti.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> 

Delivery-date: Mon, 12 May 2003 22:24:26 +0000
Date: Mon, 12 May 2003 16:23:16 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

John,
Ahhhh....
This sounds like a whole new can of worms. The goal therefore does
seem to be to develop yet another protocol solution, and I think
we need to be VERY careful before taking this kind of step.

Your assertion now seems to be that RFC 3473+3474 does NOT meet the
ASON requirements. If this is the case:
- Does G.7713.2 meet the requirements, and we missed something in
  the translation to RFC 3474? If so, then we need to supercede
  RFC 3474 with a better translation, not start over.

- Do you think that even G.7713.2 does not meet the requirements?
  If you believe this to be the case, it seems like the obvious
  first step would be to inform ITU-T - after all, this is where
  the ASON requirements came from and it makes no sense to start
  a new protocol without fixing (and aligning) G.7713.2.

If we made a mistake, lets fix it, but lets NOT start proliferating
ASON extensions take 2; ASON extensions take 3; ...

Regards,
Steve

John Drake wrote:
> 
> I think that the problem is that RFC 3474, in addition to its technical
> issues, doesn't address all of the ASON requirements.  For example, it does
> not address full call/connection separation.  So we're following the post
> 3474 procees of documenting the ASON requirements relevant to GMPLS
> signalling in order to have a common understanding of what problem is to be
> solved.
> 
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Monday, May 12, 2003 2:27 PM
> > To: John Drake
> > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> > Subject: Re: ASON reqts
> >
> >
> > Bert & John,
> > I think this document has nothing to do with the issue Bert
> > mentioned. This was a protocol issue, not a requirements issue.
> > A decision was made to leave the message out of 3474 with the
> > belief that:
> > - The protocol works without it; and
> > - The presence of the message violates the protocol.
> > The appropriate next step here would be a liaison back to ITU-T
> > explaining what was done and why, and if the ITU-T agrees with
> > the reasoning, they can align their protocol document (in this
> > case, G.7713.2).
> >
> > Back to Bert's original questions:
> > > > > > - is there or do we see any conflict?
> > - As Zhi said, this is not (yet) fully aligned with ITU-T requirements
> >   and should not be advanced to a WG document until it is.
> > However, before
> >   we do, I think we need to understand why this is necessary
> > - see below.
> >
> > > > > > - are we duplicating some work?
> > - Almost certainly. If we take the kind of alignment with ITU-T
> >   requirements that Zhi mentions as a "gate" for progressing
> > this, then
> >   what is in this document that is different from G.8080 and
> > G.7713 and
> >   why do we need this in place of a normative reference?
> >
> > > > > > - what is the purpose of this draft?
> > Excellent question.
> > > > > >   - is it after the fact documenting of requirements?
> > If it is, why bother? Also, we already have the requirements
> > (developed
> > before the protocol) in G.8080 and G.7713.
> >
> > > > > >   - is it getting ITU-T documented requirements in RFC form?
> > This could be a reasonable goal, if this document is to be an info
> > track requirements document characterizing G.8080 and G.7713 for
> > IETF folks in the same way that RFC 3474 does for G.7713.2 and
> > RFC 3475 does for G.7713.3. But it is hard to understand why producing
> > an IETF translation of the ITU-T question would be very high priority
> > when we already have an IETF translation of the answer, but
> > fundamentally
> > there would be no problem if this were the objective.
> >
> > > > > >   - is it extending ITU-T documented requirements?
> > I don't think so. If it is, I hope we start with a liaison rather
> > than trying to extend ITU-T requirements without talking to
> > ITU-T first.
> >
> > > > > >   - is it contrdicting them?
> > This is my biggest worry. I don't think we should start the process
> > over again and open the door that we come up with yet another
> > protocol solution to address the same requirements. Vendors are
> > already building to G.7713.2, G.7713.3 (and by extension, to
> > RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT
> > start a new work item with an objective to develop a new protocol
> > solution to the same problem.
> >
> > > > > >   - is it meant to be used as communication to ITU?
> > I haven't seen this proposed, but I think that if the goal is
> > to capture ITU-T requirements in RFC form, it would be a good
> > idea to ask ITU-T whether the proposed document accurately
> > captures their requirements.
> >
> > /Steve
> >
> >
> > John Drake wrote:
> > >
> > > Bert,
> > >
> > > I think so.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > Sent: Monday, May 12, 2003 1:27 PM
> > > > To: John Drake; Kireeti Kompella; [email-masked]
> > > > Subject: RE: ASON reqts
> > > >
> > > >
> > > > I know that some people had issues with the way that ITU-T
> > > > had defined the RSVP-TE extensions for ASON. In fact there
> > > > was/is a claim that it is broken. So we removed the offending
> > > > text from the RFC3474.
> > > >
> > > > The next thing we were going to do (as far as I understood it)
> > > > is to document why we (or some of us in IETF) think that the
> > > > ITU-T solution is broken, potentially with suggested fixes.
> > > > That we would send to ITU-T SG15.
> > > >
> > > > Is this the first step of that process?
> > > >
> > > > Thanks,
> > > > Bert
> > > >
> > > > > -----Original Message-----
> > > > > From: John Drake [mailto:[email-masked]]
> > > > > Sent: maandag 12 mei 2003 22:24
> > > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> > > > > Subject: RE: ASON reqts
> > > > >
> > > > >
> > > > > Bert,
> > > > >
> > > > > I thought that the post 3474/3475 process started with a
> > > > requirements
> > > > > document.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > John
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > > > Sent: Monday, May 12, 2003 1:14 PM
> > > > > > To: Kireeti Kompella; [email-masked]
> > > > > > Subject: RE: ASON reqts
> > > > > >
> > > > > >
> > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents
> > > > > > that those 2 RFCs point to, then I wonder:
> > > > > > - is there or do we see any conflict?
> > > > > > - are we duplicating some work?
> > > > > > - what is the purpose of this draft?
> > > > > >   - is it after the fact documenting of requirements?
> > > > > >   - is it getting ITU-T documented requirements in RFC form?
> > > > > >   - is it extending ITU-T documented requirements?
> > > > > >   - is it contrdicting them?
> > > > > >   - is it meant to be used as communication to ITU?
> > > > > >
> > > > > > Just wondering what is happening here.
> > > > > >
> > > > > > Thanks,
> > > > > > Bert
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Kireeti Kompella [mailto:[email-masked]]
> > > > > > > Sent: maandag 12 mei 2003 17:25
> > > > > > > To: [email-masked]
> > > > > > > Subject: Re: ASON reqts
> > > > > > >
> > > > > > >
> > > > > > > Hi All,
> > > > > > >
> > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > > > > > >
> > > > > > > > To take things one at a time, it would be very useful to
> > > > > > > read and comment
> > > > > > > > on the ASON reqts draft, as this was deemed tremendously
> > > > > > > important, and
> > > > > > > > a rich source of misunderstanding and cross-talk; and
> > > > > > > coming to a common
> > > > > > > > understanding over this should help get the IETF and the
> > > > > > ITU working
> > > > > > > > together.
> > > > > > >
> > > > > > > I haven't seen many comments, so the assumption is
> > > > either that no
> > > > > > > one cares, or that folks have read it and have no issues.
> > > > > > >
> > > > > > > I'd like to get a reading on whether this doc is
> > ready to be a
> > > > > > > CCAMP WG document.  Please respond (preferably publicly)
> > > > > > with one of:
> > > > > > >  - "I have read this document and it is ready to be a CCAMP
> > > > > > WG doc" OR
> > > > > > >  - "I have read this document, and it isn't ready to be a
> > > > > > CCAMP doc".
> > > > > > >
> > > > > > > Note that if there aren't enough responses, the default
> > > > > > assumption is
> > > > > > > that the document is either not of interest or not
> > ready, and in
> > > > > > > either case will not become a CCAMP WG doc.  Note too
> > > > > that this doc
> > > > > > > is an attempt to bridge some gaps between the IETF and
> > > > the ITU-T,
> > > > > > > and as such is fairly important.  It would be
> > useful to give an
> > > > > > > update on its status at the interim T1X1 meeting in June.
> > > > > > >
> > > > > > > Please get your responses in by COB Friday May 16th.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Kireeti.
> > > > > > >
> > > > > >
> > > > >
> > > >
> >

Delivery-date: Mon, 12 May 2003 22:18:15 +0000
To: [email-masked]
cc: [email-masked]
Subject: Re: ASON reqts 
Date: Mon, 12 May 2003 15:17:07 -0700
From: Yakov Rekhter <[email-masked]>

> I haven't seen many comments, so the assumption is either that no
> one cares, or that folks have read it and have no issues.
> 
> I'd like to get a reading on whether this doc is ready to be a
> CCAMP WG document.  Please respond (preferably publicly) with one of:
>  - "I have read this document and it is ready to be a CCAMP WG doc" OR
>  - "I have read this document, and it isn't ready to be a CCAMP doc".
> 
> Note that if there aren't enough responses, the default assumption is
> that the document is either not of interest or not ready, and in
> either case will not become a CCAMP WG doc.  Note too that this doc
> is an attempt to bridge some gaps between the IETF and the ITU-T,
> and as such is fairly important.  It would be useful to give an
> update on its status at the interim T1X1 meeting in June.
> 
> Please get your responses in by COB Friday May 16th.

I have read this document and it is ready to be a CCAMP WG doc.

Yakov.

Delivery-date: Mon, 12 May 2003 21:54:22 +0000
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 14:53:29 -0700

I think that the problem is that RFC 3474, in addition to its technical
issues, doesn't address all of the ASON requirements.  For example, it does
not address full call/connection separation.  So we're following the post
3474 procees of documenting the ASON requirements relevant to GMPLS
signalling in order to have a common understanding of what problem is to be
solved. 

> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Monday, May 12, 2003 2:27 PM
> To: John Drake
> Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> Subject: Re: ASON reqts
> 
> 
> Bert & John,
> I think this document has nothing to do with the issue Bert
> mentioned. This was a protocol issue, not a requirements issue.
> A decision was made to leave the message out of 3474 with the
> belief that:
> - The protocol works without it; and
> - The presence of the message violates the protocol.
> The appropriate next step here would be a liaison back to ITU-T
> explaining what was done and why, and if the ITU-T agrees with
> the reasoning, they can align their protocol document (in this
> case, G.7713.2).
> 
> Back to Bert's original questions:
> > > > > - is there or do we see any conflict?
> - As Zhi said, this is not (yet) fully aligned with ITU-T requirements
>   and should not be advanced to a WG document until it is. 
> However, before
>   we do, I think we need to understand why this is necessary 
> - see below.
> 
> > > > > - are we duplicating some work?
> - Almost certainly. If we take the kind of alignment with ITU-T
>   requirements that Zhi mentions as a "gate" for progressing 
> this, then
>   what is in this document that is different from G.8080 and 
> G.7713 and
>   why do we need this in place of a normative reference?
> 
> > > > > - what is the purpose of this draft?
> Excellent question.
> > > > >   - is it after the fact documenting of requirements?
> If it is, why bother? Also, we already have the requirements 
> (developed
> before the protocol) in G.8080 and G.7713.
> 
> > > > >   - is it getting ITU-T documented requirements in RFC form?
> This could be a reasonable goal, if this document is to be an info
> track requirements document characterizing G.8080 and G.7713 for
> IETF folks in the same way that RFC 3474 does for G.7713.2 and
> RFC 3475 does for G.7713.3. But it is hard to understand why producing
> an IETF translation of the ITU-T question would be very high priority
> when we already have an IETF translation of the answer, but 
> fundamentally
> there would be no problem if this were the objective.
> 
> > > > >   - is it extending ITU-T documented requirements?
> I don't think so. If it is, I hope we start with a liaison rather
> than trying to extend ITU-T requirements without talking to 
> ITU-T first.
> 
> > > > >   - is it contrdicting them?
> This is my biggest worry. I don't think we should start the process
> over again and open the door that we come up with yet another
> protocol solution to address the same requirements. Vendors are
> already building to G.7713.2, G.7713.3 (and by extension, to
> RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT
> start a new work item with an objective to develop a new protocol
> solution to the same problem.
> 
> > > > >   - is it meant to be used as communication to ITU?
> I haven't seen this proposed, but I think that if the goal is
> to capture ITU-T requirements in RFC form, it would be a good
> idea to ask ITU-T whether the proposed document accurately
> captures their requirements.
> 
> /Steve
> 
> 
> John Drake wrote:
> > 
> > Bert,
> > 
> > I think so.
> > 
> > Thanks,
> > 
> > John
> > 
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > Sent: Monday, May 12, 2003 1:27 PM
> > > To: John Drake; Kireeti Kompella; [email-masked]
> > > Subject: RE: ASON reqts
> > >
> > >
> > > I know that some people had issues with the way that ITU-T
> > > had defined the RSVP-TE extensions for ASON. In fact there
> > > was/is a claim that it is broken. So we removed the offending
> > > text from the RFC3474.
> > >
> > > The next thing we were going to do (as far as I understood it)
> > > is to document why we (or some of us in IETF) think that the
> > > ITU-T solution is broken, potentially with suggested fixes.
> > > That we would send to ITU-T SG15.
> > >
> > > Is this the first step of that process?
> > >
> > > Thanks,
> > > Bert
> > >
> > > > -----Original Message-----
> > > > From: John Drake [mailto:[email-masked]]
> > > > Sent: maandag 12 mei 2003 22:24
> > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> > > > Subject: RE: ASON reqts
> > > >
> > > >
> > > > Bert,
> > > >
> > > > I thought that the post 3474/3475 process started with a
> > > requirements
> > > > document.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > > -----Original Message-----
> > > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > > Sent: Monday, May 12, 2003 1:14 PM
> > > > > To: Kireeti Kompella; [email-masked]
> > > > > Subject: RE: ASON reqts
> > > > >
> > > > >
> > > > > So if we look at RFCs 3474/3475 and the ITU-T documents
> > > > > that those 2 RFCs point to, then I wonder:
> > > > > - is there or do we see any conflict?
> > > > > - are we duplicating some work?
> > > > > - what is the purpose of this draft?
> > > > >   - is it after the fact documenting of requirements?
> > > > >   - is it getting ITU-T documented requirements in RFC form?
> > > > >   - is it extending ITU-T documented requirements?
> > > > >   - is it contrdicting them?
> > > > >   - is it meant to be used as communication to ITU?
> > > > >
> > > > > Just wondering what is happening here.
> > > > >
> > > > > Thanks,
> > > > > Bert
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Kireeti Kompella [mailto:[email-masked]]
> > > > > > Sent: maandag 12 mei 2003 17:25
> > > > > > To: [email-masked]
> > > > > > Subject: Re: ASON reqts
> > > > > >
> > > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > > > > >
> > > > > > > To take things one at a time, it would be very useful to
> > > > > > read and comment
> > > > > > > on the ASON reqts draft, as this was deemed tremendously
> > > > > > important, and
> > > > > > > a rich source of misunderstanding and cross-talk; and
> > > > > > coming to a common
> > > > > > > understanding over this should help get the IETF and the
> > > > > ITU working
> > > > > > > together.
> > > > > >
> > > > > > I haven't seen many comments, so the assumption is
> > > either that no
> > > > > > one cares, or that folks have read it and have no issues.
> > > > > >
> > > > > > I'd like to get a reading on whether this doc is 
> ready to be a
> > > > > > CCAMP WG document.  Please respond (preferably publicly)
> > > > > with one of:
> > > > > >  - "I have read this document and it is ready to be a CCAMP
> > > > > WG doc" OR
> > > > > >  - "I have read this document, and it isn't ready to be a
> > > > > CCAMP doc".
> > > > > >
> > > > > > Note that if there aren't enough responses, the default
> > > > > assumption is
> > > > > > that the document is either not of interest or not 
> ready, and in
> > > > > > either case will not become a CCAMP WG doc.  Note too
> > > > that this doc
> > > > > > is an attempt to bridge some gaps between the IETF and
> > > the ITU-T,
> > > > > > and as such is fairly important.  It would be 
> useful to give an
> > > > > > update on its status at the interim T1X1 meeting in June.
> > > > > >
> > > > > > Please get your responses in by COB Friday May 16th.
> > > > > >
> > > > > > Thanks,
> > > > > > Kireeti.
> > > > > >
> > > > >
> > > >
> > >
> 

Delivery-date: Mon, 12 May 2003 21:33:11 +0000
From: John Drake <[email-masked]>
To: 'George Swallow' <[email-masked]>, Zhi-Wei Lin <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: ASON reqts 
Date: Mon, 12 May 2003 14:32:40 -0700

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Monday, May 12, 2003 2:28 PM
> To: Zhi-Wei Lin
> Cc: Wijnen, Bert (Bert); Kireeti Kompella; [email-masked];
> [email-masked]
> Subject: Re: ASON reqts 
> 
> 
> > As to what I think is the status, while I agree with many of the 
> > requirements in the document I believe there's still some 
> work to be 
> > done before this becomes a WG document. We've had some fair 
> amount of 
> > hashing through of the requirements, and I think many (but 
> not all) of 
> > the ASON needs have been reflected. We probably need 
> another sit-down 
> > with more ITU folks to make sure that all the critical ASON 
> > requirements are captured...
> 
> A document does not need to be complete, nor should it be complete to
> become a WG document.  The purpose of a WG doc is just a baseline of
> where the WG is on a topic.  Further I think you are in a much better
> position to sit down with the ITU if the document has some "official"
> standing.  So I think it *SHOULD* be a WG document.

JD:  Exactly right

> 
> ...George
> 
> ps.  In case Kireeti has troble reading between the lines:
> 
> "I have read this document and it is ready to be a CCAMP WG doc"
> 
> ==============================================================
> ==========
> George Swallow             Cisco Systems                  
> (978) 936-1398
>                            1414 Massachusetts Avenue
>                            Boxborough, MA 01719
> 
> 

Envelope-to: [email-masked]
Delivery-date: Mon, 12 May 2003 21:28:10 +0000
Message-Id: <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>
cc: "Wijnen, Bert (Bert)" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: Re: ASON reqts 
Date: Mon, 12 May 2003 17:27:30 -0400
From: George Swallow <[email-masked]>

> As to what I think is the status, while I agree with many of the 
> requirements in the document I believe there's still some work to be 
> done before this becomes a WG document. We've had some fair amount of 
> hashing through of the requirements, and I think many (but not all) of 
> the ASON needs have been reflected. We probably need another sit-down 
> with more ITU folks to make sure that all the critical ASON 
> requirements are captured...

A document does not need to be complete, nor should it be complete to
become a WG document.  The purpose of a WG doc is just a baseline of
where the WG is on a topic.  Further I think you are in a much better
position to sit down with the ITU if the document has some "official"
standing.  So I think it *SHOULD* be a WG document.

...George

ps.  In case Kireeti has troble reading between the lines:

"I have read this document and it is ready to be a CCAMP WG doc"

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

Delivery-date: Mon, 12 May 2003 21:28:04 +0000
Date: Mon, 12 May 2003 15:27:05 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

Bert & John,
I think this document has nothing to do with the issue Bert
mentioned. This was a protocol issue, not a requirements issue.
A decision was made to leave the message out of 3474 with the
belief that:
- The protocol works without it; and
- The presence of the message violates the protocol.
The appropriate next step here would be a liaison back to ITU-T
explaining what was done and why, and if the ITU-T agrees with
the reasoning, they can align their protocol document (in this
case, G.7713.2).

Back to Bert's original questions:
> > > > - is there or do we see any conflict?
- As Zhi said, this is not (yet) fully aligned with ITU-T requirements
  and should not be advanced to a WG document until it is. However, before
  we do, I think we need to understand why this is necessary - see below.

> > > > - are we duplicating some work?
- Almost certainly. If we take the kind of alignment with ITU-T
  requirements that Zhi mentions as a "gate" for progressing this, then
  what is in this document that is different from G.8080 and G.7713 and
  why do we need this in place of a normative reference?

> > > > - what is the purpose of this draft?
Excellent question.
> > > >   - is it after the fact documenting of requirements?
If it is, why bother? Also, we already have the requirements (developed
before the protocol) in G.8080 and G.7713.

> > > >   - is it getting ITU-T documented requirements in RFC form?
This could be a reasonable goal, if this document is to be an info
track requirements document characterizing G.8080 and G.7713 for
IETF folks in the same way that RFC 3474 does for G.7713.2 and
RFC 3475 does for G.7713.3. But it is hard to understand why producing
an IETF translation of the ITU-T question would be very high priority
when we already have an IETF translation of the answer, but fundamentally
there would be no problem if this were the objective.

> > > >   - is it extending ITU-T documented requirements?
I don't think so. If it is, I hope we start with a liaison rather
than trying to extend ITU-T requirements without talking to ITU-T first.

> > > >   - is it contrdicting them?
This is my biggest worry. I don't think we should start the process
over again and open the door that we come up with yet another
protocol solution to address the same requirements. Vendors are
already building to G.7713.2, G.7713.3 (and by extension, to
RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT
start a new work item with an objective to develop a new protocol
solution to the same problem.

> > > >   - is it meant to be used as communication to ITU?
I haven't seen this proposed, but I think that if the goal is
to capture ITU-T requirements in RFC form, it would be a good
idea to ask ITU-T whether the proposed document accurately
captures their requirements.

/Steve

John Drake wrote:
> 
> Bert,
> 
> I think so.
> 
> Thanks,
> 
> John
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Monday, May 12, 2003 1:27 PM
> > To: John Drake; Kireeti Kompella; [email-masked]
> > Subject: RE: ASON reqts
> >
> >
> > I know that some people had issues with the way that ITU-T
> > had defined the RSVP-TE extensions for ASON. In fact there
> > was/is a claim that it is broken. So we removed the offending
> > text from the RFC3474.
> >
> > The next thing we were going to do (as far as I understood it)
> > is to document why we (or some of us in IETF) think that the
> > ITU-T solution is broken, potentially with suggested fixes.
> > That we would send to ITU-T SG15.
> >
> > Is this the first step of that process?
> >
> > Thanks,
> > Bert
> >
> > > -----Original Message-----
> > > From: John Drake [mailto:[email-masked]]
> > > Sent: maandag 12 mei 2003 22:24
> > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> > > Subject: RE: ASON reqts
> > >
> > >
> > > Bert,
> > >
> > > I thought that the post 3474/3475 process started with a
> > requirements
> > > document.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > > Sent: Monday, May 12, 2003 1:14 PM
> > > > To: Kireeti Kompella; [email-masked]
> > > > Subject: RE: ASON reqts
> > > >
> > > >
> > > > So if we look at RFCs 3474/3475 and the ITU-T documents
> > > > that those 2 RFCs point to, then I wonder:
> > > > - is there or do we see any conflict?
> > > > - are we duplicating some work?
> > > > - what is the purpose of this draft?
> > > >   - is it after the fact documenting of requirements?
> > > >   - is it getting ITU-T documented requirements in RFC form?
> > > >   - is it extending ITU-T documented requirements?
> > > >   - is it contrdicting them?
> > > >   - is it meant to be used as communication to ITU?
> > > >
> > > > Just wondering what is happening here.
> > > >
> > > > Thanks,
> > > > Bert
> > > >
> > > > > -----Original Message-----
> > > > > From: Kireeti Kompella [mailto:[email-masked]]
> > > > > Sent: maandag 12 mei 2003 17:25
> > > > > To: [email-masked]
> > > > > Subject: Re: ASON reqts
> > > > >
> > > > >
> > > > > Hi All,
> > > > >
> > > > > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > > > >
> > > > > > To take things one at a time, it would be very useful to
> > > > > read and comment
> > > > > > on the ASON reqts draft, as this was deemed tremendously
> > > > > important, and
> > > > > > a rich source of misunderstanding and cross-talk; and
> > > > > coming to a common
> > > > > > understanding over this should help get the IETF and the
> > > > ITU working
> > > > > > together.
> > > > >
> > > > > I haven't seen many comments, so the assumption is
> > either that no
> > > > > one cares, or that folks have read it and have no issues.
> > > > >
> > > > > I'd like to get a reading on whether this doc is ready to be a
> > > > > CCAMP WG document.  Please respond (preferably publicly)
> > > > with one of:
> > > > >  - "I have read this document and it is ready to be a CCAMP
> > > > WG doc" OR
> > > > >  - "I have read this document, and it isn't ready to be a
> > > > CCAMP doc".
> > > > >
> > > > > Note that if there aren't enough responses, the default
> > > > assumption is
> > > > > that the document is either not of interest or not ready, and in
> > > > > either case will not become a CCAMP WG doc.  Note too
> > > that this doc
> > > > > is an attempt to bridge some gaps between the IETF and
> > the ITU-T,
> > > > > and as such is fairly important.  It would be useful to give an
> > > > > update on its status at the interim T1X1 meeting in June.
> > > > >
> > > > > Please get your responses in by COB Friday May 16th.
> > > > >
> > > > > Thanks,
> > > > > Kireeti.
> > > > >
> > > >
> > >
> >

Delivery-date: Mon, 12 May 2003 21:07:49 +0000
From: "Ong, Lyndon" <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, John Drake <[email-masked]>, Kireeti Kompella <[email-masked]>,  [email-masked]
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 14:09:49 -0700

Hi Bert,

IMHO, the requirements draft identifies a number of
requirements for ASON that went into the definition of
RFC3474 (with the exception of crankback, which has
been worked separately), so it is not in conflict with
the work in 3474.  I don't see this as being tied to
"fixing" the extensions in 3474, which in my view is
not necessary. 

Some of the mailing list discussion revolved around
requirements such as call and connection separation, 
and it would be helpful to see if there is actually 
agreement to support this. 

Other complaints were about the process that went into
creating 3474, and hopefully the requirements document
will help address those concerns as well.

Lastly, the requirements draft has obviously been
condensed down to some specific requirements with
impact on signaling.  There may be changes or
additions as we go along (the ability to identify
separately a transport node, connection controller and routing
controller might be one to consider).

Cheers,

Lyndon

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Monday, May 12, 2003 1:27 PM
To: John Drake; Kireeti Kompella; [email-masked]
Subject: RE: ASON reqts

I know that some people had issues with the way that ITU-T
had defined the RSVP-TE extensions for ASON. In fact there
was/is a claim that it is broken. So we removed the offending
text from the RFC3474. 

The next thing we were going to do (as far as I understood it)
is to document why we (or some of us in IETF) think that the
ITU-T solution is broken, potentially with suggested fixes.
That we would send to ITU-T SG15.

Is this the first step of that process?

Thanks,
Bert 

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: maandag 12 mei 2003 22:24
> To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Bert,
> 
> I thought that the post 3474/3475 process started with a requirements
> document.
> 
> Thanks,
> 
> John
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Monday, May 12, 2003 1:14 PM
> > To: Kireeti Kompella; [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > So if we look at RFCs 3474/3475 and the ITU-T documents 
> > that those 2 RFCs point to, then I wonder:
> > - is there or do we see any conflict?
> > - are we duplicating some work?
> > - what is the purpose of this draft?
> >   - is it after the fact documenting of requirements?
> >   - is it getting ITU-T documented requirements in RFC form?
> >   - is it extending ITU-T documented requirements?
> >   - is it contrdicting them?
> >   - is it meant to be used as communication to ITU?
> > 
> > Just wondering what is happening here.
> > 
> > Thanks,
> > Bert 
> > 
> > > -----Original Message-----
> > > From: Kireeti Kompella [mailto:[email-masked]]
> > > Sent: maandag 12 mei 2003 17:25
> > > To: [email-masked]
> > > Subject: Re: ASON reqts
> > > 
> > > 
> > > Hi All,
> > > 
> > > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > > 
> > > > To take things one at a time, it would be very useful to 
> > > read and comment
> > > > on the ASON reqts draft, as this was deemed tremendously 
> > > important, and
> > > > a rich source of misunderstanding and cross-talk; and 
> > > coming to a common
> > > > understanding over this should help get the IETF and the 
> > ITU working
> > > > together.
> > > 
> > > I haven't seen many comments, so the assumption is either that no
> > > one cares, or that folks have read it and have no issues.
> > > 
> > > I'd like to get a reading on whether this doc is ready to be a
> > > CCAMP WG document.  Please respond (preferably publicly) 
> > with one of:
> > >  - "I have read this document and it is ready to be a CCAMP 
> > WG doc" OR
> > >  - "I have read this document, and it isn't ready to be a 
> > CCAMP doc".
> > > 
> > > Note that if there aren't enough responses, the default 
> > assumption is
> > > that the document is either not of interest or not ready, and in
> > > either case will not become a CCAMP WG doc.  Note too 
> that this doc
> > > is an attempt to bridge some gaps between the IETF and the ITU-T,
> > > and as such is fairly important.  It would be useful to give an
> > > update on its status at the interim T1X1 meeting in June.
> > > 
> > > Please get your responses in by COB Friday May 16th.
> > > 
> > > Thanks,
> > > Kireeti.
> > > 
> > 
> 

Delivery-date: Mon, 12 May 2003 21:07:31 +0000
From: John Drake <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 14:06:25 -0700

Bert,

In case you missed it:
http://ops.ietf.org/lists/ccamp/ccamp.2003/msg00451.html

John

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Monday, May 12, 2003 1:27 PM
> To: John Drake; Kireeti Kompella; [email-masked]
> Subject: RE: ASON reqts
> 
> 
> I know that some people had issues with the way that ITU-T
> had defined the RSVP-TE extensions for ASON. In fact there
> was/is a claim that it is broken. So we removed the offending
> text from the RFC3474. 
> 
> The next thing we were going to do (as far as I understood it)
> is to document why we (or some of us in IETF) think that the
> ITU-T solution is broken, potentially with suggested fixes.
> That we would send to ITU-T SG15.
> 
> Is this the first step of that process?
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: maandag 12 mei 2003 22:24
> > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > Bert,
> > 
> > I thought that the post 3474/3475 process started with a 
> requirements
> > document.
> > 
> > Thanks,
> > 
> > John
> > 
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > Sent: Monday, May 12, 2003 1:14 PM
> > > To: Kireeti Kompella; [email-masked]
> > > Subject: RE: ASON reqts
> > > 
> > > 
> > > So if we look at RFCs 3474/3475 and the ITU-T documents 
> > > that those 2 RFCs point to, then I wonder:
> > > - is there or do we see any conflict?
> > > - are we duplicating some work?
> > > - what is the purpose of this draft?
> > >   - is it after the fact documenting of requirements?
> > >   - is it getting ITU-T documented requirements in RFC form?
> > >   - is it extending ITU-T documented requirements?
> > >   - is it contrdicting them?
> > >   - is it meant to be used as communication to ITU?
> > > 
> > > Just wondering what is happening here.
> > > 
> > > Thanks,
> > > Bert 
> > > 
> > > > -----Original Message-----
> > > > From: Kireeti Kompella [mailto:[email-masked]]
> > > > Sent: maandag 12 mei 2003 17:25
> > > > To: [email-masked]
> > > > Subject: Re: ASON reqts
> > > > 
> > > > 
> > > > Hi All,
> > > > 
> > > > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > > > 
> > > > > To take things one at a time, it would be very useful to 
> > > > read and comment
> > > > > on the ASON reqts draft, as this was deemed tremendously 
> > > > important, and
> > > > > a rich source of misunderstanding and cross-talk; and 
> > > > coming to a common
> > > > > understanding over this should help get the IETF and the 
> > > ITU working
> > > > > together.
> > > > 
> > > > I haven't seen many comments, so the assumption is 
> either that no
> > > > one cares, or that folks have read it and have no issues.
> > > > 
> > > > I'd like to get a reading on whether this doc is ready to be a
> > > > CCAMP WG document.  Please respond (preferably publicly) 
> > > with one of:
> > > >  - "I have read this document and it is ready to be a CCAMP 
> > > WG doc" OR
> > > >  - "I have read this document, and it isn't ready to be a 
> > > CCAMP doc".
> > > > 
> > > > Note that if there aren't enough responses, the default 
> > > assumption is
> > > > that the document is either not of interest or not ready, and in
> > > > either case will not become a CCAMP WG doc.  Note too 
> > that this doc
> > > > is an attempt to bridge some gaps between the IETF and 
> the ITU-T,
> > > > and as such is fairly important.  It would be useful to give an
> > > > update on its status at the interim T1X1 meeting in June.
> > > > 
> > > > Please get your responses in by COB Friday May 16th.
> > > > 
> > > > Thanks,
> > > > Kireeti.
> > > > 
> > > 
> > 
> 

Delivery-date: Mon, 12 May 2003 20:47:20 +0000
From: Ayan Banerjee <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: 'Kireeti Kompella' <[email-masked]>
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 13:46:37 -0700

Mine should read: 

"I have read this document and it is ready to be a CCAMP WG doc"

Cut-and-paste from below did not work correctly. 

Thanks,
Ayan

-----Original Message-----
From: Ayan Banerjee 
Sent: Monday, May 12, 2003 1:31 PM
To: [email-masked]
Cc: Kireeti Kompella
Subject: RE: ASON reqts

"I have read this document, and it isn't ready to be a CCAMP doc"

Thanks,
Ayan

> I'd like to get a reading on whether this doc is ready to be a
> CCAMP WG document.  Please respond (preferably publicly) with one of:
>  - "I have read this document and it is ready to be a CCAMP WG doc" OR
>  - "I have read this document, and it isn't ready to be a CCAMP doc".

Delivery-date: Mon, 12 May 2003 20:42:35 +0000
Date: Mon, 12 May 2003 16:41:02 -0400
From: Zhi-Wei Lin <[email-masked]>
Subject: Re: RE: ASON reqts
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, [email-masked]

Hi Bert,

I believe the purpose of the document is to try and capture the ITU-T 
requirements and present in a IETF "friendly" way. So I support trying 
to get the requirements consistent between the two.

As to what I think is the status, while I agree with many of the 
requirements in the document I believe there's still some work to be 
done before this becomes a WG document. We've had some fair amount of 
hashing through of the requirements, and I think many (but not all) of 
the ASON needs have been reflected. We probably need another sit-down 
with more ITU folks to make sure that all the critical ASON 
requirements are captured...

So to answer Kireeti's comments, I'd like a third option: "I have read 
this document, and it's almost ready to be a CCAMP doc"

Zhi

----- Original Message -----
From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Monday, May 12, 2003 4:14 pm
Subject: RE: ASON reqts

> So if we look at RFCs 3474/3475 and the ITU-T documents 
> that those 2 RFCs point to, then I wonder:
> - is there or do we see any conflict?
> - are we duplicating some work?
> - what is the purpose of this draft?
>  - is it after the fact documenting of requirements?
>  - is it getting ITU-T documented requirements in RFC form?
>  - is it extending ITU-T documented requirements?
>  - is it contrdicting them?
>  - is it meant to be used as communication to ITU?
> 
> Just wondering what is happening here.
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Kireeti Kompella [[email-masked]]
> > Sent: maandag 12 mei 2003 17:25
> > To: [email-masked]
> > Subject: Re: ASON reqts
> > 
> > 
> > Hi All,
> > 
> > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > 
> > > To take things one at a time, it would be very useful to 
> > read and comment
> > > on the ASON reqts draft, as this was deemed tremendously 
> > important, and
> > > a rich source of misunderstanding and cross-talk; and 
> > coming to a common
> > > understanding over this should help get the IETF and the ITU 
> working> > together.
> > 
> > I haven't seen many comments, so the assumption is either that no
> > one cares, or that folks have read it and have no issues.
> > 
> > I'd like to get a reading on whether this doc is ready to be a
> > CCAMP WG document.  Please respond (preferably publicly) with 
> one of:
> >  - "I have read this document and it is ready to be a CCAMP WG 
> doc" OR
> >  - "I have read this document, and it isn't ready to be a CCAMP 
> doc".> 
> > Note that if there aren't enough responses, the default 
> assumption is
> > that the document is either not of interest or not ready, and in
> > either case will not become a CCAMP WG doc.  Note too that this doc
> > is an attempt to bridge some gaps between the IETF and the ITU-T,
> > and as such is fairly important.  It would be useful to give an
> > update on its status at the interim T1X1 meeting in June.
> > 
> > Please get your responses in by COB Friday May 16th.
> > 
> > Thanks,
> > Kireeti.
> > 
> 
> 

Delivery-date: Mon, 12 May 2003 20:31:33 +0000
From: Ayan Banerjee <[email-masked]>
To: [email-masked]
Cc: Kireeti Kompella <[email-masked]>
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 13:30:47 -0700

"I have read this document, and it isn't ready to be a CCAMP doc"

Thanks,
Ayan

> I'd like to get a reading on whether this doc is ready to be a
> CCAMP WG document.  Please respond (preferably publicly) with one of:
>  - "I have read this document and it is ready to be a CCAMP WG doc" OR
>  - "I have read this document, and it isn't ready to be a CCAMP doc".

Delivery-date: Mon, 12 May 2003 20:31:00 +0000
From: John Drake <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 13:30:32 -0700

Bert,

I think so.

Thanks,

John

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Monday, May 12, 2003 1:27 PM
> To: John Drake; Kireeti Kompella; [email-masked]
> Subject: RE: ASON reqts
> 
> 
> I know that some people had issues with the way that ITU-T
> had defined the RSVP-TE extensions for ASON. In fact there
> was/is a claim that it is broken. So we removed the offending
> text from the RFC3474. 
> 
> The next thing we were going to do (as far as I understood it)
> is to document why we (or some of us in IETF) think that the
> ITU-T solution is broken, potentially with suggested fixes.
> That we would send to ITU-T SG15.
> 
> Is this the first step of that process?
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: maandag 12 mei 2003 22:24
> > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > Bert,
> > 
> > I thought that the post 3474/3475 process started with a 
> requirements
> > document.
> > 
> > Thanks,
> > 
> > John
> > 
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > Sent: Monday, May 12, 2003 1:14 PM
> > > To: Kireeti Kompella; [email-masked]
> > > Subject: RE: ASON reqts
> > > 
> > > 
> > > So if we look at RFCs 3474/3475 and the ITU-T documents 
> > > that those 2 RFCs point to, then I wonder:
> > > - is there or do we see any conflict?
> > > - are we duplicating some work?
> > > - what is the purpose of this draft?
> > >   - is it after the fact documenting of requirements?
> > >   - is it getting ITU-T documented requirements in RFC form?
> > >   - is it extending ITU-T documented requirements?
> > >   - is it contrdicting them?
> > >   - is it meant to be used as communication to ITU?
> > > 
> > > Just wondering what is happening here.
> > > 
> > > Thanks,
> > > Bert 
> > > 
> > > > -----Original Message-----
> > > > From: Kireeti Kompella [mailto:[email-masked]]
> > > > Sent: maandag 12 mei 2003 17:25
> > > > To: [email-masked]
> > > > Subject: Re: ASON reqts
> > > > 
> > > > 
> > > > Hi All,
> > > > 
> > > > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > > > 
> > > > > To take things one at a time, it would be very useful to 
> > > > read and comment
> > > > > on the ASON reqts draft, as this was deemed tremendously 
> > > > important, and
> > > > > a rich source of misunderstanding and cross-talk; and 
> > > > coming to a common
> > > > > understanding over this should help get the IETF and the 
> > > ITU working
> > > > > together.
> > > > 
> > > > I haven't seen many comments, so the assumption is 
> either that no
> > > > one cares, or that folks have read it and have no issues.
> > > > 
> > > > I'd like to get a reading on whether this doc is ready to be a
> > > > CCAMP WG document.  Please respond (preferably publicly) 
> > > with one of:
> > > >  - "I have read this document and it is ready to be a CCAMP 
> > > WG doc" OR
> > > >  - "I have read this document, and it isn't ready to be a 
> > > CCAMP doc".
> > > > 
> > > > Note that if there aren't enough responses, the default 
> > > assumption is
> > > > that the document is either not of interest or not ready, and in
> > > > either case will not become a CCAMP WG doc.  Note too 
> > that this doc
> > > > is an attempt to bridge some gaps between the IETF and 
> the ITU-T,
> > > > and as such is fairly important.  It would be useful to give an
> > > > update on its status at the interim T1X1 meeting in June.
> > > > 
> > > > Please get your responses in by COB Friday May 16th.
> > > > 
> > > > Thanks,
> > > > Kireeti.
> > > > 
> > > 
> > 
> 

Delivery-date: Mon, 12 May 2003 20:28:01 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: John Drake <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 22:27:11 +0200

I know that some people had issues with the way that ITU-T
had defined the RSVP-TE extensions for ASON. In fact there
was/is a claim that it is broken. So we removed the offending
text from the RFC3474. 

The next thing we were going to do (as far as I understood it)
is to document why we (or some of us in IETF) think that the
ITU-T solution is broken, potentially with suggested fixes.
That we would send to ITU-T SG15.

Is this the first step of that process?

Thanks,
Bert 

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: maandag 12 mei 2003 22:24
> To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; [email-masked]
> Subject: RE: ASON reqts
> 
> 
> Bert,
> 
> I thought that the post 3474/3475 process started with a requirements
> document.
> 
> Thanks,
> 
> John
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Monday, May 12, 2003 1:14 PM
> > To: Kireeti Kompella; [email-masked]
> > Subject: RE: ASON reqts
> > 
> > 
> > So if we look at RFCs 3474/3475 and the ITU-T documents 
> > that those 2 RFCs point to, then I wonder:
> > - is there or do we see any conflict?
> > - are we duplicating some work?
> > - what is the purpose of this draft?
> >   - is it after the fact documenting of requirements?
> >   - is it getting ITU-T documented requirements in RFC form?
> >   - is it extending ITU-T documented requirements?
> >   - is it contrdicting them?
> >   - is it meant to be used as communication to ITU?
> > 
> > Just wondering what is happening here.
> > 
> > Thanks,
> > Bert 
> > 
> > > -----Original Message-----
> > > From: Kireeti Kompella [mailto:[email-masked]]
> > > Sent: maandag 12 mei 2003 17:25
> > > To: [email-masked]
> > > Subject: Re: ASON reqts
> > > 
> > > 
> > > Hi All,
> > > 
> > > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > > 
> > > > To take things one at a time, it would be very useful to 
> > > read and comment
> > > > on the ASON reqts draft, as this was deemed tremendously 
> > > important, and
> > > > a rich source of misunderstanding and cross-talk; and 
> > > coming to a common
> > > > understanding over this should help get the IETF and the 
> > ITU working
> > > > together.
> > > 
> > > I haven't seen many comments, so the assumption is either that no
> > > one cares, or that folks have read it and have no issues.
> > > 
> > > I'd like to get a reading on whether this doc is ready to be a
> > > CCAMP WG document.  Please respond (preferably publicly) 
> > with one of:
> > >  - "I have read this document and it is ready to be a CCAMP 
> > WG doc" OR
> > >  - "I have read this document, and it isn't ready to be a 
> > CCAMP doc".
> > > 
> > > Note that if there aren't enough responses, the default 
> > assumption is
> > > that the document is either not of interest or not ready, and in
> > > either case will not become a CCAMP WG doc.  Note too 
> that this doc
> > > is an attempt to bridge some gaps between the IETF and the ITU-T,
> > > and as such is fairly important.  It would be useful to give an
> > > update on its status at the interim T1X1 meeting in June.
> > > 
> > > Please get your responses in by COB Friday May 16th.
> > > 
> > > Thanks,
> > > Kireeti.
> > > 
> > 
> 

Delivery-date: Mon, 12 May 2003 20:23:57 +0000
From: John Drake <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 13:23:33 -0700

Bert,

I thought that the post 3474/3475 process started with a requirements
document.

Thanks,

John

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Monday, May 12, 2003 1:14 PM
> To: Kireeti Kompella; [email-masked]
> Subject: RE: ASON reqts
> 
> 
> So if we look at RFCs 3474/3475 and the ITU-T documents 
> that those 2 RFCs point to, then I wonder:
> - is there or do we see any conflict?
> - are we duplicating some work?
> - what is the purpose of this draft?
>   - is it after the fact documenting of requirements?
>   - is it getting ITU-T documented requirements in RFC form?
>   - is it extending ITU-T documented requirements?
>   - is it contrdicting them?
>   - is it meant to be used as communication to ITU?
> 
> Just wondering what is happening here.
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:[email-masked]]
> > Sent: maandag 12 mei 2003 17:25
> > To: [email-masked]
> > Subject: Re: ASON reqts
> > 
> > 
> > Hi All,
> > 
> > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > 
> > > To take things one at a time, it would be very useful to 
> > read and comment
> > > on the ASON reqts draft, as this was deemed tremendously 
> > important, and
> > > a rich source of misunderstanding and cross-talk; and 
> > coming to a common
> > > understanding over this should help get the IETF and the 
> ITU working
> > > together.
> > 
> > I haven't seen many comments, so the assumption is either that no
> > one cares, or that folks have read it and have no issues.
> > 
> > I'd like to get a reading on whether this doc is ready to be a
> > CCAMP WG document.  Please respond (preferably publicly) 
> with one of:
> >  - "I have read this document and it is ready to be a CCAMP 
> WG doc" OR
> >  - "I have read this document, and it isn't ready to be a 
> CCAMP doc".
> > 
> > Note that if there aren't enough responses, the default 
> assumption is
> > that the document is either not of interest or not ready, and in
> > either case will not become a CCAMP WG doc.  Note too that this doc
> > is an attempt to bridge some gaps between the IETF and the ITU-T,
> > and as such is fairly important.  It would be useful to give an
> > update on its status at the interim T1X1 meeting in June.
> > 
> > Please get your responses in by COB Friday May 16th.
> > 
> > Thanks,
> > Kireeti.
> > 
> 

Delivery-date: Mon, 12 May 2003 20:21:33 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 15:21:11 -0500
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>

> I'd like to get a reading on whether this doc is ready to be a
> CCAMP WG document.  Please respond (preferably publicly) with one of:
>  - "I have read this document and it is ready to be a CCAMP WG doc" OR
>  - "I have read this document, and it isn't ready to be a CCAMP doc".

"I have read this document and it is ready to be a CCAMP WG doc"

I agree with Deborah that the document is well aligned with the ITU =
requirements, and has a good balance of ITU and IETF input.

Thanks,
Jerry

Delivery-date: Mon, 12 May 2003 20:14:44 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 22:14:05 +0200

So if we look at RFCs 3474/3475 and the ITU-T documents 
that those 2 RFCs point to, then I wonder:
- is there or do we see any conflict?
- are we duplicating some work?
- what is the purpose of this draft?
  - is it after the fact documenting of requirements?
  - is it getting ITU-T documented requirements in RFC form?
  - is it extending ITU-T documented requirements?
  - is it contrdicting them?
  - is it meant to be used as communication to ITU?

Just wondering what is happening here.

Thanks,
Bert 

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: maandag 12 mei 2003 17:25
> To: [email-masked]
> Subject: Re: ASON reqts
> 
> 
> Hi All,
> 
> On Fri, 2 May 2003, Kireeti Kompella wrote:
> 
> > To take things one at a time, it would be very useful to 
> read and comment
> > on the ASON reqts draft, as this was deemed tremendously 
> important, and
> > a rich source of misunderstanding and cross-talk; and 
> coming to a common
> > understanding over this should help get the IETF and the ITU working
> > together.
> 
> I haven't seen many comments, so the assumption is either that no
> one cares, or that folks have read it and have no issues.
> 
> I'd like to get a reading on whether this doc is ready to be a
> CCAMP WG document.  Please respond (preferably publicly) with one of:
>  - "I have read this document and it is ready to be a CCAMP WG doc" OR
>  - "I have read this document, and it isn't ready to be a CCAMP doc".
> 
> Note that if there aren't enough responses, the default assumption is
> that the document is either not of interest or not ready, and in
> either case will not become a CCAMP WG doc.  Note too that this doc
> is an attempt to bridge some gaps between the IETF and the ITU-T,
> and as such is fairly important.  It would be useful to give an
> update on its status at the interim T1X1 meeting in June.
> 
> Please get your responses in by COB Friday May 16th.
> 
> Thanks,
> Kireeti.
> 

Delivery-date: Mon, 12 May 2003 19:47:11 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 14:46:21 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

I have read this document and it is ready to be a CCAMP WG doc.

The document is very aligned with the ITU work. From an ITU perspective, =
the document is easy to read. And considering the author list, it's a =
balanced list of ITU and IETF participants. Following up on Adrian's =
request, I would be interested to hear from IETF participants. As =
Kireeti stated, this document is an attempt to bridge the gaps between =
the IETF and ITU work. Most important for progressing this work is the =
understanding level/interest by the IETF community involved in GMPLS.

Thanks,
Deborah

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Monday, May 12, 2003 12:03 PM
To: [email-masked]
Subject: Re: ASON reqts

> I'd like to get a reading on whether this doc is ready to be a
> CCAMP WG document.  Please respond (preferably publicly) with one of:
>  - "I have read this document and it is ready to be a CCAMP WG doc" OR
>  - "I have read this document, and it isn't ready to be a CCAMP doc".

Unless you count the authors by default...
"I have read this document and it is ready to be a CCAMP WG doc"

> Note too that this doc
> is an attempt to bridge some gaps between the IETF and the ITU-T,
> and as such is fairly important.  It would be useful to give an
> update on its status at the interim T1X1 meeting in June.

In the light of which, we would be *very* pleased to have comments from =
people
who participate in the ITU-T work. From my perspective I would like to =
know...

- Does this draft represent a fair picture of the ASON requirements?
   - Has it left anything out?
   - Has it made up requirements that aren't there?
   - Does it give the right precedence to the requirements?

- Does the draft give the right level of background without overly =
restating
   material that is in the ITU documents?

Thanks,
Adrian

Delivery-date: Mon, 12 May 2003 19:30:56 +0000
From: John Drake <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, [email-masked]
Subject: RE: ASON reqts
Date: Mon, 12 May 2003 12:30:20 -0700

"I have read this document and it is ready to be a CCAMP WG doc"

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Monday, May 12, 2003 8:25 AM
> To: [email-masked]
> Subject: Re: ASON reqts
> 
> 
> Hi All,
> 
> On Fri, 2 May 2003, Kireeti Kompella wrote:
> 
> > To take things one at a time, it would be very useful to 
> read and comment
> > on the ASON reqts draft, as this was deemed tremendously 
> important, and
> > a rich source of misunderstanding and cross-talk; and 
> coming to a common
> > understanding over this should help get the IETF and the ITU working
> > together.
> 
> I haven't seen many comments, so the assumption is either that no
> one cares, or that folks have read it and have no issues.
> 
> I'd like to get a reading on whether this doc is ready to be a
> CCAMP WG document.  Please respond (preferably publicly) with one of:
>  - "I have read this document and it is ready to be a CCAMP WG doc" OR
>  - "I have read this document, and it isn't ready to be a CCAMP doc".
> 
> Note that if there aren't enough responses, the default assumption is
> that the document is either not of interest or not ready, and in
> either case will not become a CCAMP WG doc.  Note too that this doc
> is an attempt to bridge some gaps between the IETF and the ITU-T,
> and as such is fairly important.  It would be useful to give an
> update on its status at the interim T1X1 meeting in June.
> 
> Please get your responses in by COB Friday May 16th.
> 
> Thanks,
> Kireeti.
> 

Delivery-date: Mon, 12 May 2003 18:39:11 +0000
content-class: urn:content-classes:message
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation
Date: Mon, 12 May 2003 13:37:30 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>, <[email-masked]>

Fine, send it as is,
Deborah

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Monday, May 12, 2003 2:23 AM
To: [email-masked]
Cc: [email-masked]; Wijnen, Bert (Bert); Ron Bonica (E-mail);=20
Subject: RE: Proposed response to the Liaison Statement on LMP Link
Verifi cation

Hi All,

On Tue, 29 Apr 2003, Kireeti Kompella wrote:

> I will formulate a liaison statement in reply to T1X1 regarding
> draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list.

Sorry for the tardy follow-up.  Here is the proposed response.

Please send your replies to the list (if you wish to reply privately,
include the Liaison Coordinator and the ADs in your reply).

Ideally, your reply should say one of:
 - "Fine, send it as is"; OR
 - "Please make the following changes", with _specific text_; OR
 - "Do not send this response".

Please respond by COB Friday, May 16th.

Kireeti.
=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=3D=3D=3D=3D=3D

Dear Mr. Biholar,

Regarding the following liaison:

TITLE: Liaison from T1X1 to IETF ccamp regarding
	draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt
TO: IETF ccamp Working Group
CC: ITU-T Q.14/15 (for information)
SOURCE*: T1X1
FOR: Action
DEADLINE: 9 June 2003
PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic =
Interconnection

We thank the T1X1 and the ITU-T for their review and the incorporation
of the LMP Test procedure into G.7714.1.

Based on information contained in the ITU and T1X1 liaison, as well as
subsequent e-mail exchanges on the CCAMP mailing list, and in order to
ensure proper interoperability in legacy SDH/SONET networks as well as
networks in which G.7714.1 is deployed, it will be recommended by the
editors to the CCAMP community to support only the Jx trace correlation
procedure and not the in-band Jx procedure.  Pending agreement, the
draft will be updated.

See inline for more detailed responses to specific points.

> Context of Application Space

<snip>

> It is currently our understanding that the use case
> scenario for which this procedure is applied encompasses
> both transport plane connectivity verification as well as
> correlation of these entities with the control plane.
> ITU-T G.7714.1 is focused on discovering the transport
> plane link connection end point relationships and
> verifying their connectivity.
> This Recommendation defines two procedures for performing
> the connectivity verification function, one of which
> utilizes either the Jx or the DCC bytes of the server
> signal (termed "in-service"). The other approach in
> G.7714.1, termed as "out of service", corresponds to
> inserting a test signal in the payload of the server
> signal. Based on an analysis of the data link state
> definitions in draft-ietf-ccamp-lmp-08.txt, we understand
> that the approach defined in the LMP test for physical
> connectivity occurs in the context of the "out of service"
> state (as described in G.7714.1).
>
> Please confirm this.

The subject document uses the Jx or DCC bytes to perform the LMP
Test procedure, but the The LMP Test procedure is done as part of
GMPLS link intialization, prior to the link being available to
carry user traffic.

> Usage of Jx Bytes
>
> In defining the Jx bytes within G.7714.1, the following
> was taken into account:
> 1. One consideration involved the case where the Discovery
> Agent is located in an external system, and an external
> interface is used by the Network Element to provision and
> receive the Trail Trace message. As an existing text-
> oriented Man-Machine Language, such as TL1, may be reused
> to provide this interface, it was decided that the
> discovery message be limited to printable characters.
> Specifically, the TTI characters should be limited to
> printable characters as per T.50 with trailing NULLs or
> SPACEs. Use of arbitrary bit patterns in the lower 7 bits
> of each byte could prematurely terminate the pattern or
> trigger fault notification for certain hardware or
> software implementations. The strategy chosen in G.7714.1
> avoids the danger by limiting the information content of
> each byte to 6 bits (84 bits total) and uses a base 64
> coding according to RFC2045 to place the information in
> the available bits.

The LMP test procedure described in the subject document defines
two usages of the Jx bytes.  The first is termed the 'trace
correlation transport mechanism' and it treats the Jx bytes as
an opaque bit stream.

This usage is completely consistent with the above.  GMPLS
identifiers are typically 32 bit numbers and as such are not
printable characters.  In networks that do not require that the
Jx bytes be printable, it is also possible to carry the GMPLS
identifiers directly in the Jx bytes.  This is termed the 'Jx
transport mechanism'.

> 2. Another consideration involved providing a means for
> distinguishing this use of the Jx bytes from the
> traditional use for Trail Trace identifiers in new
> equipments. As a result, G.7714.1 includes a
> distinguishing character ("+") as the first non-CRC byte
> that will never appear as the first character of a TTI.
> This requires modification of the trail termination
> functions to prevent the raising of TTI mismatch
> alarms during the connectivity verification process.

The selection of which LMP transport mechanism use in the LMP Test
procedure for a given link as well as the time at which the Jx
bytes are to be used for the LMP Test procedure is under control of
the GMPLS nodes at either end of the link, so it is well understood
by those nodes.  It is our understanding, per G.806 section 6.1,
that the LMP Test procedure would be performed when the link is in
the NMON (not monitored state), and therefore intermediate SDH/SONET
equipment would not be performing non-intrusive monitoring.

> While the context for testing the transport plane
> connectivity is different between the two documents, they
> both use the Jx bytes of the server signal, and we invite
> the IETF to determine the appropriateness of the above
> aspects in their test signal definitions.

The trace correlation transport mechanism is completely consistent
with this.  The JX transport mechanism requires additional
identifiers (i.e., the Verify ID).

> Even if these considerations are not relevant to this
> context, it will be necessary to augment G.783 equipment
> functions to recognize this new usage of Jx messages.

We would be happy to provide assistance to T1X1/ITU-T in augmenting
G.783 equipment functions to recognize the additional capability
for supporting GMPLS networking elements.

> Required Updates to SDH Equipment Specifications
>
> SDH equipment specifications as they currently exist reflect
> the usage of the Jx bytes prior to the development of
> G.7714.1. ITU-T Study Group 15 has as a work item to
> revise these equipment functions to include support for
> these new functions. Specifically, this will involve
> updates to trail termination functions to generate and
> receive the new messages and to avoid unnecessary alarms in
> the case where the new messages are received.  In addition,
> non-intrusive monitoring functions will need to be revised
> so that unnecessary alarms are not raised when the
> messages are observed en-route.  Whether or not there is
> further alignment between the message formats used in
> G.7714.1 and the subject draft, the new functions to
> support the subject draft will also need to be reflected
> in the atomic functions in G.783.  The sending and
> receiving of these messages can be reflected in the trail
> termination functions in a similar way to what we plan to
> do for support of G.7714.1 functions.

We would be happy to provide assistance to T1X1/ITU-T in augmenting
G.783 equipment functions to recognize the additional capability
for supporting GMPLS networking elements.

> Terminology Differences

<snip>

> Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1,
> the "up/free (in-service)" data link state appears to
> correspond with what G.7714.1 refers to as "out-of-
> service".  This difference in terminology has resulted in
> different interpretations of the context.  Explaining the
> scenarios further in the lmp test document would be
> beneficial in establishing a translation between the
> differing uses of the same terms.  Within ITU-T, work is
> being initiated of draft Rec. G.fame, Framework for ASON
> Management, where control plane/management plane
> interactions will be addressed.

We agree that terminology differences between IETF and ITU-T wrt
GMPLS have been confusing.  There is an ongoing effort within
CCAMP to work together with T1X1/ITU-T on bridging the terminology
gaps.  For example, there is a new Internet draft
(draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in
CCAMP to do this mapping for LMP.

> Further Study Items
>
> Following are some areas where further contributions are
> requested:
> 1.     For SDH equipment functions in G.783, it needs to
> be understood whether the application of the lmp test
> message requires revision of NIM (non-intrusive
> monitoring) functions.  The reason for this is that the
> test procedure is initiated between control entities at
> the end-points of the trail, and intermediate points are
> not necessarily aware that the test is taking place.  For
> G.7714.1, it was felt important for any termination or NIM
> function to easily distinguish between the various uses of
> the Jx bytes.  It may be necessary for the subject draft
> to use a similarly easily recognizable format.  If no
> revision to NIM functions is required for the context of
> this draft, the architecture of the context for this
> application (demonstrating why the NIM functions are not
> required) should be reflected in G.803 and/or G.807/G.8080.

It is our understanding, per G.806 section 6.1, that
the LMP Test procedure would be performed when the link is in the
NMON (not monitored state), and  therefore intermediate SDH/SONET
equipment would not be performing non-intrusive monitoring.
As described, the trace correlation procedure use of Jx bytes is
consistent with the current standards.

> 2.Determination of whether it would be possible to use the
> identical message formats in the subject draft as in
> G.7714.1 for the connectivity verification function.

The trace correlation transport mechanism is completely consistent
with this.  The Jx transport mechanism requires additional
identifiers (i.e., the Verify ID).

> 3.Determination of whether it would be possible to use the
> same overall structure (distinguishing character, 4 bit
> message type, 80 bit message body) if a different message
> format or information content is required.

This is certainly possible (not applicable for the trace correlation
procedure).

> 4.Work is needed to clarify under what
> configurations/states (for example: no VC-n signals
> carrying client traffic) the lmp test message is
> applicable over J0.  If the signal can be framed and J0
> can be recovered, the Regenerator Section is considered
> as "in service" from a transport plane perspective.  So
> unlike the J1/J2 case, the application of the lmp test
> message at the Regenerator Section does not occur in an
> "out of service" state (from a transport plane
> perspective).

Section 6.1 of G.806 refers to a "termination function part of a
trail, which is in the process of set-up" as in the NMON state.
LMP link verification is based on pre-service testing.  Please let
us know if we can be of any assistance in updating the appropriate
Recommendations to support the GMPLS network element LMP capability.
This is not applicable for the trace correlation procedure.

> 5. Clarification of the usage of transport and control
> names for transport resources in the subject draft, as
> described in G.8080 Amendment

The trace correlation transport mechanism supports a separation of
the transport and control plane identifiers.

> 6. Consideration of the ANSI 64-byte J1.

This was mistakenly deleted from the latest version of the draft.
This will be included in the next version.

Sincerely,
Kireeti Kompella and Ron Bonica,
Chairs of the CCAMP WG/IETF.

Delivery-date: Mon, 12 May 2003 18:39:04 +0000
content-class: urn:content-classes:message
Subject: RE: Proposed change to LMP Link Verification draft
Date: Mon, 12 May 2003 13:38:27 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>

Agree with change,
Deborah

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Monday, May 12, 2003 2:28 AM
To: [email-masked]
Subject: Proposed change to LMP Link Verification draft

Hi All,

| Based on information contained in the ITU and T1X1 liaison, as well as
| subsequent e-mail exchanges on the CCAMP mailing list, and in order to
| ensure proper interoperability in legacy SDH/SONET networks as well as
| networks in which G.7714.1 is deployed, it will be recommended by the
| editors to the CCAMP community to support only the Jx trace =
correlation
| procedure and not the in-band Jx procedure.

Please respond with one of the following:
 - Agree with above change; OR
 - Don't agree with above change [i.e., keep in-band Jx procedure as =
is].

Kireeti.

Envelope-to: [email-masked]
Delivery-date: Mon, 12 May 2003 16:03:52 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: ASON reqts
Date: Mon, 12 May 2003 12:02:56 -0400

> I'd like to get a reading on whether this doc is ready to be a
> CCAMP WG document.  Please respond (preferably publicly) with one of:
>  - "I have read this document and it is ready to be a CCAMP WG doc" OR
>  - "I have read this document, and it isn't ready to be a CCAMP doc".

Unless you count the authors by default...
"I have read this document and it is ready to be a CCAMP WG doc"

> Note too that this doc
> is an attempt to bridge some gaps between the IETF and the ITU-T,
> and as such is fairly important.  It would be useful to give an
> update on its status at the interim T1X1 meeting in June.

In the light of which, we would be *very* pleased to have comments from people
who participate in the ITU-T work. From my perspective I would like to know...

- Does this draft represent a fair picture of the ASON requirements?
   - Has it left anything out?
   - Has it made up requirements that aren't there?
   - Does it give the right precedence to the requirements?

- Does the draft give the right level of background without overly restating
   material that is in the ITU documents?

Thanks,
Adrian

Delivery-date: Mon, 12 May 2003 15:25:39 +0000
Date: Mon, 12 May 2003 08:24:37 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Re: ASON reqts

Hi All,

On Fri, 2 May 2003, Kireeti Kompella wrote:

> To take things one at a time, it would be very useful to read and comment
> on the ASON reqts draft, as this was deemed tremendously important, and
> a rich source of misunderstanding and cross-talk; and coming to a common
> understanding over this should help get the IETF and the ITU working
> together.

I haven't seen many comments, so the assumption is either that no
one cares, or that folks have read it and have no issues.

I'd like to get a reading on whether this doc is ready to be a
CCAMP WG document.  Please respond (preferably publicly) with one of:
 - "I have read this document and it is ready to be a CCAMP WG doc" OR
 - "I have read this document, and it isn't ready to be a CCAMP doc".

Note that if there aren't enough responses, the default assumption is
that the document is either not of interest or not ready, and in
either case will not become a CCAMP WG doc.  Note too that this doc
is an attempt to bridge some gaps between the IETF and the ITU-T,
and as such is fairly important.  It would be useful to give an
update on its status at the interim T1X1 meeting in June.

Please get your responses in by COB Friday May 16th.

Thanks,
Kireeti.

Delivery-date: Mon, 12 May 2003 14:50:46 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-02.txt
Date: Mon, 12 May 2003 10:46:51 -0400

--NextPart

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-recovery-terminology-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: Mon, 12 May 2003 14:10:39 +0000
From: Manoj Agiwal <[email-masked]>
To: "'Ccamp (E-mail)" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: LMP Message ID
Date: Mon, 12 May 2003 09:02:02 -0500

Hi ,
      Lmp drafts tells that Message ID should be monotonically increasing .
    
      Section 7 also tells that "Unacknowledge messages sent with Message_id
object should be retransmitted until the message is 
      acknowledged or until retry limit is reached."

      Do we have to sent all retransmitted messages with the same Message Id
as sent previously or it should be in monotonically
      increasing order.

Regards ,
Manoj

Delivery-date: Mon, 12 May 2003 11:27:40 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-02.txt
Date: Mon, 12 May 2003 07:22:45 -0400

--NextPart

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-recovery-terminology-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: Mon, 12 May 2003 06:28:58 +0000
Date: Sun, 11 May 2003 23:27:58 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Proposed change to LMP Link Verification draft

Hi All,

| Based on information contained in the ITU and T1X1 liaison, as well as
| subsequent e-mail exchanges on the CCAMP mailing list, and in order to
| ensure proper interoperability in legacy SDH/SONET networks as well as
| networks in which G.7714.1 is deployed, it will be recommended by the
| editors to the CCAMP community to support only the Jx trace correlation
| procedure and not the in-band Jx procedure.

Please respond with one of the following:
 - Agree with above change; OR
 - Don't agree with above change [i.e., keep in-band Jx procedure as is].

Kireeti.

Delivery-date: Mon, 12 May 2003 06:27:31 +0000
Date: Sun, 11 May 2003 23:23:01 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
cc: [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>, "" <[email-masked]>
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation

Hi All,

On Tue, 29 Apr 2003, Kireeti Kompella wrote:

> I will formulate a liaison statement in reply to T1X1 regarding
> draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list.

Sorry for the tardy follow-up.  Here is the proposed response.

Please send your replies to the list (if you wish to reply privately,
include the Liaison Coordinator and the ADs in your reply).

Ideally, your reply should say one of:
 - "Fine, send it as is"; OR
 - "Please make the following changes", with _specific text_; OR
 - "Do not send this response".

Please respond by COB Friday, May 16th.

Kireeti.
=======================================================================

Dear Mr. Biholar,

Regarding the following liaison:

TITLE: Liaison from T1X1 to IETF ccamp regarding
	draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt
TO: IETF ccamp Working Group
CC: ITU-T Q.14/15 (for information)
SOURCE*: T1X1
FOR: Action
DEADLINE: 9 June 2003
PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic Interconnection

We thank the T1X1 and the ITU-T for their review and the incorporation
of the LMP Test procedure into G.7714.1.

Based on information contained in the ITU and T1X1 liaison, as well as
subsequent e-mail exchanges on the CCAMP mailing list, and in order to
ensure proper interoperability in legacy SDH/SONET networks as well as
networks in which G.7714.1 is deployed, it will be recommended by the
editors to the CCAMP community to support only the Jx trace correlation
procedure and not the in-band Jx procedure.  Pending agreement, the
draft will be updated.

See inline for more detailed responses to specific points.

> Context of Application Space

<snip>

> It is currently our understanding that the use case
> scenario for which this procedure is applied encompasses
> both transport plane connectivity verification as well as
> correlation of these entities with the control plane.
> ITU-T G.7714.1 is focused on discovering the transport
> plane link connection end point relationships and
> verifying their connectivity.
> This Recommendation defines two procedures for performing
> the connectivity verification function, one of which
> utilizes either the Jx or the DCC bytes of the server
> signal (termed "in-service"). The other approach in
> G.7714.1, termed as "out of service", corresponds to
> inserting a test signal in the payload of the server
> signal. Based on an analysis of the data link state
> definitions in draft-ietf-ccamp-lmp-08.txt, we understand
> that the approach defined in the LMP test for physical
> connectivity occurs in the context of the "out of service"
> state (as described in G.7714.1).
>
> Please confirm this.

The subject document uses the Jx or DCC bytes to perform the LMP
Test procedure, but the The LMP Test procedure is done as part of
GMPLS link intialization, prior to the link being available to
carry user traffic.

> Usage of Jx Bytes
>
> In defining the Jx bytes within G.7714.1, the following
> was taken into account:
> 1. One consideration involved the case where the Discovery
> Agent is located in an external system, and an external
> interface is used by the Network Element to provision and
> receive the Trail Trace message. As an existing text-
> oriented Man-Machine Language, such as TL1, may be reused
> to provide this interface, it was decided that the
> discovery message be limited to printable characters.
> Specifically, the TTI characters should be limited to
> printable characters as per T.50 with trailing NULLs or
> SPACEs. Use of arbitrary bit patterns in the lower 7 bits
> of each byte could prematurely terminate the pattern or
> trigger fault notification for certain hardware or
> software implementations. The strategy chosen in G.7714.1
> avoids the danger by limiting the information content of
> each byte to 6 bits (84 bits total) and uses a base 64
> coding according to RFC2045 to place the information in
> the available bits.

The LMP test procedure described in the subject document defines
two usages of the Jx bytes.  The first is termed the 'trace
correlation transport mechanism' and it treats the Jx bytes as
an opaque bit stream.

This usage is completely consistent with the above.  GMPLS
identifiers are typically 32 bit numbers and as such are not
printable characters.  In networks that do not require that the
Jx bytes be printable, it is also possible to carry the GMPLS
identifiers directly in the Jx bytes.  This is termed the 'Jx
transport mechanism'.

> 2. Another consideration involved providing a means for
> distinguishing this use of the Jx bytes from the
> traditional use for Trail Trace identifiers in new
> equipments. As a result, G.7714.1 includes a
> distinguishing character ("+") as the first non-CRC byte
> that will never appear as the first character of a TTI.
> This requires modification of the trail termination
> functions to prevent the raising of TTI mismatch
> alarms during the connectivity verification process.

The selection of which LMP transport mechanism use in the LMP Test
procedure for a given link as well as the time at which the Jx
bytes are to be used for the LMP Test procedure is under control of
the GMPLS nodes at either end of the link, so it is well understood
by those nodes.  It is our understanding, per G.806 section 6.1,
that the LMP Test procedure would be performed when the link is in
the NMON (not monitored state), and therefore intermediate SDH/SONET
equipment would not be performing non-intrusive monitoring.

> While the context for testing the transport plane
> connectivity is different between the two documents, they
> both use the Jx bytes of the server signal, and we invite
> the IETF to determine the appropriateness of the above
> aspects in their test signal definitions.

The trace correlation transport mechanism is completely consistent
with this.  The JX transport mechanism requires additional
identifiers (i.e., the Verify ID).

> Even if these considerations are not relevant to this
> context, it will be necessary to augment G.783 equipment
> functions to recognize this new usage of Jx messages.

We would be happy to provide assistance to T1X1/ITU-T in augmenting
G.783 equipment functions to recognize the additional capability
for supporting GMPLS networking elements.

> Required Updates to SDH Equipment Specifications
>
> SDH equipment specifications as they currently exist reflect
> the usage of the Jx bytes prior to the development of
> G.7714.1. ITU-T Study Group 15 has as a work item to
> revise these equipment functions to include support for
> these new functions. Specifically, this will involve
> updates to trail termination functions to generate and
> receive the new messages and to avoid unnecessary alarms in
> the case where the new messages are received.  In addition,
> non-intrusive monitoring functions will need to be revised
> so that unnecessary alarms are not raised when the
> messages are observed en-route.  Whether or not there is
> further alignment between the message formats used in
> G.7714.1 and the subject draft, the new functions to
> support the subject draft will also need to be reflected
> in the atomic functions in G.783.  The sending and
> receiving of these messages can be reflected in the trail
> termination functions in a similar way to what we plan to
> do for support of G.7714.1 functions.

We would be happy to provide assistance to T1X1/ITU-T in augmenting
G.783 equipment functions to recognize the additional capability
for supporting GMPLS networking elements.

> Terminology Differences

<snip>

> Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1,
> the "up/free (in-service)" data link state appears to
> correspond with what G.7714.1 refers to as "out-of-
> service".  This difference in terminology has resulted in
> different interpretations of the context.  Explaining the
> scenarios further in the lmp test document would be
> beneficial in establishing a translation between the
> differing uses of the same terms.  Within ITU-T, work is
> being initiated of draft Rec. G.fame, Framework for ASON
> Management, where control plane/management plane
> interactions will be addressed.

We agree that terminology differences between IETF and ITU-T wrt
GMPLS have been confusing.  There is an ongoing effort within
CCAMP to work together with T1X1/ITU-T on bridging the terminology
gaps.  For example, there is a new Internet draft
(draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in
CCAMP to do this mapping for LMP.

> Further Study Items
>
> Following are some areas where further contributions are
> requested:
> 1.     For SDH equipment functions in G.783, it needs to
> be understood whether the application of the lmp test
> message requires revision of NIM (non-intrusive
> monitoring) functions.  The reason for this is that the
> test procedure is initiated between control entities at
> the end-points of the trail, and intermediate points are
> not necessarily aware that the test is taking place.  For
> G.7714.1, it was felt important for any termination or NIM
> function to easily distinguish between the various uses of
> the Jx bytes.  It may be necessary for the subject draft
> to use a similarly easily recognizable format.  If no
> revision to NIM functions is required for the context of
> this draft, the architecture of the context for this
> application (demonstrating why the NIM functions are not
> required) should be reflected in G.803 and/or G.807/G.8080.

It is our understanding, per G.806 section 6.1, that
the LMP Test procedure would be performed when the link is in the
NMON (not monitored state), and  therefore intermediate SDH/SONET
equipment would not be performing non-intrusive monitoring.
As described, the trace correlation procedure use of Jx bytes is
consistent with the current standards.

> 2.Determination of whether it would be possible to use the
> identical message formats in the subject draft as in
> G.7714.1 for the connectivity verification function.

The trace correlation transport mechanism is completely consistent
with this.  The Jx transport mechanism requires additional
identifiers (i.e., the Verify ID).

> 3.Determination of whether it would be possible to use the
> same overall structure (distinguishing character, 4 bit
> message type, 80 bit message body) if a different message
> format or information content is required.

This is certainly possible (not applicable for the trace correlation
procedure).

> 4.Work is needed to clarify under what
> configurations/states (for example: no VC-n signals
> carrying client traffic) the lmp test message is
> applicable over J0.  If the signal can be framed and J0
> can be recovered, the Regenerator Section is considered
> as "in service" from a transport plane perspective.  So
> unlike the J1/J2 case, the application of the lmp test
> message at the Regenerator Section does not occur in an
> "out of service" state (from a transport plane
> perspective).

Section 6.1 of G.806 refers to a "termination function part of a
trail, which is in the process of set-up" as in the NMON state.
LMP link verification is based on pre-service testing.  Please let
us know if we can be of any assistance in updating the appropriate
Recommendations to support the GMPLS network element LMP capability.
This is not applicable for the trace correlation procedure.

> 5. Clarification of the usage of transport and control
> names for transport resources in the subject draft, as
> described in G.8080 Amendment

The trace correlation transport mechanism supports a separation of
the transport and control plane identifiers.

> 6. Consideration of the ANSI 64-byte J1.

This was mistakenly deleted from the latest version of the draft.
This will be included in the next version.

Sincerely,
Kireeti Kompella and Ron Bonica,
Chairs of the CCAMP WG/IETF.

Delivery-date: Wed, 07 May 2003 15:35:04 +0000
Date: Wed, 07 May 2003 17:39:57 +0200
From: [email-masked]
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: Re: FW: Evaluation: draft-ietf-ccamp-gmpls-architecture - Generalized Multi-Protocol Label Switching Architecture to Proposed Standard

bert, this is the intention (taking also into account the
previous set of ref's comment), here probably harald wanted to
see a single sentence where the following words are included:
GMPLS, control plane, protocol (suite), architecture, and
another sentence (first sentence of the introduction) should
be rephrased from "The architecture presented..." to "The
architecture described..." since it is an "architecture
descriptive" document; these together should address
his hesitation(s) now of course there was a trade-off here
between reproduce all the i-d's (this wasn't the ultimate
intention) and give a fair level of details (intention was
also to have a "structuring i-d"), thus here the reader is
pointed to the appropriate reference when the level of the
details wouldn't be suitable in the scope of this document
(anyway if the iesg thinks some pointers are still missing
well would you then just send them asap, and if the ccamp
community thinks additional editorial changes are needed to
address these comments input is welcome on this specific
point)

ps: i'd like to recap here also there was imho a very good
i-d ("Multi-Protocol Lambda Switching: Combining MPLS Traffic 
Engineering Control With Optical Crossconnects" draft-awduche-
mpls-te-optical-03.txt) which is the fundamental step between
this i-d (gmpls and related) and rfc2702 (mpls-te), rfc3031
(mpls) unfortunately it has not been further progressed since
april'01

thanks,
- dimitri.

Wijnen, Bert (Bert) wrote:
> Dimitri, if for any reason (possibly on based on other comments
> from IESG) you are going to do another rev, can you pls check
> the below comments and see if some additional editorial changes 
> make sense?
> 
> By the way, you can see that Harald also noted the "many Work in Progress"
> documents that are listed as normative references.
> 
> Thanks,
> Bert 
> 
> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:[email-masked]]
> Sent: zaterdag 26 april 2003 18:03
> To: IESG Secretary; Internet Engineering Steering Group
> Subject: Re: Evaluation: draft-ietf-ccamp-gmpls-architecture -
> Generalized Multi-Protocol Label Switching Architecture to Proposed
> Standard
> 
> Harald Alvestrand has no Objection.
> 
> note: this does not mean that I like it.....
> 
> In particular, I don't like the fact that the document can't decide whether 
> it's an architecture, an introduction or a specification. It goes into lots 
> of details that are ALMOST specified, but then just says that these are 
> "finished elsewhere" - sometimes giving, sometimes not giving, the forward 
> pointers.
> 
> It's just about right (although overly detailed, and lacking some pointers 
> to where the "real spec" is) for an introduction.
> 
> It also *contains* an architecture description - the idea of a control 
> plane that is a fully connected IP network (with, apparently, manual link 
> configuration), a set of links that are not necessarily the control links, 
> and in many cases not even IP-capable links, and groupings of these that 
> can be manipulated and controlled in various ways, and a set of protocols 
> and ways to use those protocols that are defined in other documents.
> 
> But the lenght and the level of detail means that it's very hard for me to 
> be sure I have grasped that architecture correctly and fully.
> 
> And - note - I have said nothing about whether or not I *like* that 
> architecture.
> 
> Note: It will be a while before this is published as an RFC. There are no 
> less than thirteen "works in progress" in its normative references.
> 
>                      Harald
> 
> 

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

Delivery-date: Wed, 07 May 2003 15:19:47 +0000
Date: Wed, 07 May 2003 17:23:39 +0200
From: [email-masked]
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>, "Thomas Narten (E-mail)" <[email-masked]>, "Erik Nordmark (E-mail)" <[email-masked]>
Subject: Re: draft-ietf-ccamp-gmpls-architecture-06.txt

bert,

if the RFC's that are in the queue might already
receive a number this would help in aligning with
the point 2 of the summary you have provided here
(this said it was the intent to differentiate b/w
the RFC's produced in the scope/directly related
of/to GMPLS, for inst. RSVP-TE-GMPLS from the ones
that were produced independently, for instance RFC
2750, this is probably not needed anymore) anyway
what i'd suggest is to have a version "RFC ready"
but in an IESG reviewed status as you have also
suggested here below

see below for some additional input concerning the
i-d status (for the routing ones please refer to
the editor(s)

Wijnen, Bert (Bert) wrote:
> During IESG review, Thomas/Erik both have raised the
> question that this doc had so many normative references
> that seem to be "Work in Progress".
> So I have checked and found the below.
> 
> Summary:
> - Would be good to have the doc names spelled out, so that reviewers
>   (and RFC-Editor) can quickly find the normative ref.
> - Would be good to change [SOME-DOC-NAME] to [RFCxxxx] if an RFC is
>   already published. Would be more consistent with other RFCs that
>   are being referenced, and makes it easier to see which docs are
>   already published
> - We have some 5 docs in WGs still and it is not clear how quick
>   they will come out
> - We have some 4 or 5 that are in various stages of IESG review
>   and seem to need work.
> 
> So it looks, that when we approve this and put it in RFCed queue,
> it will probably hang in that queue for a long time. 
> 
> WG and WG chairs, what do you want to do about that?
> 
> ---- status of various normative references --
> 
> Here are the WiP docs that are normative and the status as I fas as I
> could determine (updates from WG chairs will be appreciated):
> 
>    [BUNDLE]        K.Kompella, Y.Rekhter and L.Berger, "Link Bundling
>                    in MPLS Traffic Engineering," Work in Progress.
> This is: draft-ietf-mpls-bundle-04.txt
> in RFCed queue
> 
>    [CR-LDP-UNNUM]  K.Kompella, Y.Rekhter and A.Kullberg, "Signalling
>                    Unnumbered Links in CR-LDP," Work in Progress.
> Published as RFC3480
> 
>    [GMPLS-FUNCT]   J.P.Lang and B.Rajagopalan (Editors) et al.,
> 	                   "Generalized MPLS Recovery Functional
>                    Specification," Work in Progress.
> This is: draft-ietf-ccamp-gmpls-recovery-functional-00.txt
> Not sure where this stands in WG

revision has to be submitted (soon)

>    [GMPLS-G709]    D.Papadimitriou (Editor) et al., "GMPLS Signaling
>                    Extensions for G.709 Optical Transport Networks
>                    Control," Work in progress.
> This is: draft-ietf-ccamp-gmpls-g709-03.txt
> Not sure where this stands in WG

provide a last revision of it and ask for a last call

>    [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the
>                    Overlay Model," Work in Progress.
> This is: draft-ietf-ccamp-gmpls-overlay-01.txt
> Still in WG (did not get much content discussion yet, but yet
> it seems WG chairs want to do WG Last Call)
> 
>    [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing
>                    Extensions in Support of Generalized MPLS," Work in
>                    Progress.
> This is: draft-ietf-ccamp-gmpls-routing-05.txt
> Went through IETF Last Call.
> Quite some comments. Is back in WG to address comments 
> (been there for a while in fact. Wg chairs did not ye responde to
> my repeated pinging on status)
 >
>    [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al.,
>                    "Generalized MPLS Extensions for SONET and SDH
>                    Control," Work in progress.
> This is: draft-ietf-ccamp-gmpls-sonet-sdh-08.txt
> Is in RFCed queue 
> 
>    [HIERARCHY]     K.Kompella and Y.Rekhter, "LSP Hierarchy with
>                    Generalized MPLS TE," Work in Progress.
> This is: draft-ietf-mpls-lsp-hierarchy-08.txt
> Is in RFCed queue
> 
>    [LMP]           J.P.Lang (Editor) et al., "Link Management Protocol
>                    (LMP)," Work in progress.
> This is: draft-ietf-ccamp-lmp-08.txt
> Is in IESG evaluation. Has some DISCUSSes though.

work is ongoing to provide a response to the DISCUSS
points

>    [LMP-WDM]       A.Fredette and J.P.Lang (Editors) et al., "LMP for
>                    WDM Optical Line Systems (LMP-WDM)," Work in
>                    progress.
> This is: draft-ietf-ccamp-lmp-wdm-02.txt
> In: AD-Evaluation, revised ID needed

well for this one it depends, how long it will take
after the revised i-d submission to have the review
from the iesg (do you expect further action on this ?)

>    [OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions
>                    in Support of Generalized MPLS," Work in Progress.
> This is: draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
> This had serious OETF Last Call comments, to be addressed by WG/authors
> 
>    [OSPF-TE]    D.Katz, D.Yeung, and K.Kompella, "Traffic
>                 Engineering Extensions to OSPF", Work in Progress.
> This is: draft-katz-yeung-ospf-traffic-09.txt
> IESG evaluation, point raised
> 
> Thanks,
> Bert 
> 

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

Delivery-date: Wed, 07 May 2003 12:56:57 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Dimitri Papadimitriou (E-mail)" <[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: FW: Evaluation: draft-ietf-ccamp-gmpls-architecture - Generalized Multi-Protocol Label Switching Architecture to Proposed Standard
Date: Wed, 7 May 2003 14:40:57 +0200 

Dimitri, if for any reason (possibly on based on other comments
from IESG) you are going to do another rev, can you pls check
the below comments and see if some additional editorial changes 
make sense?

By the way, you can see that Harald also noted the "many Work in Progress"
documents that are listed as normative references.

Thanks,
Bert 

-----Original Message-----
From: Harald Tveit Alvestrand [mailto:[email-masked]]
Sent: zaterdag 26 april 2003 18:03
To: IESG Secretary; Internet Engineering Steering Group
Subject: Re: Evaluation: draft-ietf-ccamp-gmpls-architecture -
Generalized Multi-Protocol Label Switching Architecture to Proposed
Standard

Harald Alvestrand has no Objection.

note: this does not mean that I like it.....

In particular, I don't like the fact that the document can't decide whether 
it's an architecture, an introduction or a specification. It goes into lots 
of details that are ALMOST specified, but then just says that these are 
"finished elsewhere" - sometimes giving, sometimes not giving, the forward 
pointers.

It's just about right (although overly detailed, and lacking some pointers 
to where the "real spec" is) for an introduction.

It also *contains* an architecture description - the idea of a control 
plane that is a fully connected IP network (with, apparently, manual link 
configuration), a set of links that are not necessarily the control links, 
and in many cases not even IP-capable links, and groupings of these that 
can be manipulated and controlled in various ways, and a set of protocols 
and ways to use those protocols that are defined in other documents.

But the lenght and the level of detail means that it's very hard for me to 
be sure I have grasped that architecture correctly and fully.

And - note - I have said nothing about whether or not I *like* that 
architecture.

Note: It will be a while before this is published as an RFC. There are no 
less than thirteen "works in progress" in its normative references.

                     Harald

Delivery-date: Wed, 07 May 2003 12:39:22 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Cc: "Thomas Narten (E-mail)" <[email-masked]>, "Erik Nordmark (E-mail)" <[email-masked]>
Subject: RE: draft-ietf-ccamp-gmpls-architecture-06.txt
Date: Wed, 7 May 2003 14:36:59 +0200 

During IESG review, Thomas/Erik both have raised the
question that this doc had so many normative references
that seem to be "Work in Progress".
So I have checked and found the below.

Summary:
- Would be good to have the doc names spelled out, so that reviewers
  (and RFC-Editor) can quickly find the normative ref.
- Would be good to change [SOME-DOC-NAME] to [RFCxxxx] if an RFC is
  already published. Would be more consistent with other RFCs that
  are being referenced, and makes it easier to see which docs are
  already published
- We have some 5 docs in WGs still and it is not clear how quick
  they will come out
- We have some 4 or 5 that are in various stages of IESG review
  and seem to need work.

So it looks, that when we approve this and put it in RFCed queue,
it will probably hang in that queue for a long time. 

WG and WG chairs, what do you want to do about that?

---- status of various normative references --

Here are the WiP docs that are normative and the status as I fas as I
could determine (updates from WG chairs will be appreciated):

   [BUNDLE]        K.Kompella, Y.Rekhter and L.Berger, "Link Bundling
                   in MPLS Traffic Engineering," Work in Progress.
This is: draft-ietf-mpls-bundle-04.txt
in RFCed queue

   [CR-LDP-UNNUM]  K.Kompella, Y.Rekhter and A.Kullberg, "Signalling
                   Unnumbered Links in CR-LDP," Work in Progress.
Published as RFC3480

   [GMPLS-FUNCT]   J.P.Lang and B.Rajagopalan (Editors) et al.,
	                   "Generalized MPLS Recovery Functional
                   Specification," Work in Progress.
This is: draft-ietf-ccamp-gmpls-recovery-functional-00.txt
Not sure where this stands in WG

   [GMPLS-G709]    D.Papadimitriou (Editor) et al., "GMPLS Signaling
                   Extensions for G.709 Optical Transport Networks
                   Control," Work in progress.
This is: draft-ietf-ccamp-gmpls-g709-03.txt
Not sure where this stands in WG

   [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the
                   Overlay Model," Work in Progress.
This is: draft-ietf-ccamp-gmpls-overlay-01.txt
Still in WG (did not get much content discussion yet, but yet
it seems WG chairs want to do WG Last Call)

   [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing
                   Extensions in Support of Generalized MPLS," Work in
                   Progress.
This is: draft-ietf-ccamp-gmpls-routing-05.txt
Went through IETF Last Call.
Quite some comments. Is back in WG to address comments 
(been there for a while in fact. Wg chairs did not ye responde to
my repeated pinging on status).

   [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al.,
                   "Generalized MPLS Extensions for SONET and SDH
                   Control," Work in progress.
This is: draft-ietf-ccamp-gmpls-sonet-sdh-08.txt
Is in RFCed queue 

   [HIERARCHY]     K.Kompella and Y.Rekhter, "LSP Hierarchy with
                   Generalized MPLS TE," Work in Progress.
This is: draft-ietf-mpls-lsp-hierarchy-08.txt
Is in RFCed queue

   [LMP]           J.P.Lang (Editor) et al., "Link Management Protocol
                   (LMP)," Work in progress.
This is: draft-ietf-ccamp-lmp-08.txt
Is in IESG evaluation. Has some DISCUSSes though.

   [LMP-WDM]       A.Fredette and J.P.Lang (Editors) et al., "LMP for
                   WDM Optical Line Systems (LMP-WDM)," Work in
                   progress.
This is: draft-ietf-ccamp-lmp-wdm-02.txt
In: AD-Evaluation, revised ID needed

   [OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions
                   in Support of Generalized MPLS," Work in Progress.
This is: draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
This had serious OETF Last Call comments, to be addressed by WG/authors

   [OSPF-TE]    D.Katz, D.Yeung, and K.Kompella, "Traffic
                Engineering Extensions to OSPF", Work in Progress.
This is: draft-katz-yeung-ospf-traffic-09.txt
IESG evaluation, point raised

Thanks,
Bert 

Delivery-date: Mon, 05 May 2003 14:30:35 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Mon, 5 May 2003 09:26:28 -0500
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: "Yangguang Xu" <[email-masked]>
Cc: <[email-masked]>, "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, "Kireeti Kompella" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>

Yangguang,

> > SPC is required by ASON, it was included in the first=20
> > Recommendation on Requirements for the Automatic Switched=20
> > Transport Networks (G.807 published in 2001).  For operators,=20
> > SPC support is considered as a critical application for ASON.=20
> > Until UNI/E-NNI support functionality is available (e.g.=20
> > billing systems/directory services), this will likely be the=20
> > first application for most operators of ASON.  For example,=20
> > in ITU-T Rec'd G.7713.1 on ASON PNNI (consented January=20
> > 2003), it is only concerned with specifying soft permanent=20
> > connections.

> I wasn't challenge SPC at all. I was just wondering the first=20
> requirement to GMPLS signaling in the draft is necessary.=20
> Because I know two solutions don't do that but can still=20
> provide full SPC service well.

The 'first requirement' is for SPC, and as I pointed out is a MUST =
requirement for ASON (see the summary of ASON requirements/'identified =
gaps' at http://ietf.org/proceedings/02mar/slides/ccamp-4/sld005.htm.)

> > Again, ASON requirements/'identified gaps' include=20
> > crankback as a MUST, inter-domain and intra-domain.  It is=20
> > already included in G.7713.1 and G.7713.3.  More information=20
> > on crankback is available in the draft=20
> > =
http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-05.txt.

> SPC is a service. Yet crankback is a mechanism. Not sure why=20
> requirement wants to enforce a mechanism/solution.

I think they're both mechanisms that could possibly support a service.  =
The ASON requirements draft is identifying delta requirements in terms =
of the GMPLS protocol capabilities, not necessarily limited to services.

Thanks,
Jerry

Delivery-date: Sat, 03 May 2003 20:03:52 +0000
Date: Sat, 03 May 2003 16:02:59 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
CC: [email-masked]
Subject: Re: ASON reqts

Jerry,

> SPC is required by ASON, it was included in the first Recommendation on Requirements for the Automatic Switched Transport Networks (G.807 published in 2001).  For operators, SPC support is considered as a critical application for ASON.  Until UNI/E-NNI support functionality is available (e.g. billing systems/directory services), this will likely be the first application for most operators of ASON.  For example, in ITU-T Rec'd G.7713.1 on ASON PNNI (consented January 2003), it is only concerned with specifying soft permanent connections.
> 

I wasn't challenge SPC at all. I was just wondering the first requirement to
GMPLS signaling in the draft is necessary. Because I know two solutions don't do
that but can still provide full SPC service well.

> 
> Again, ASON requirements/'identified gaps' include crankback as a MUST, inter-domain and inter-domain.  It is already included in G.7713.1 and G.7713.3.  More information on crankback is available in the draft http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-05.txt.
> 

SPC is a service. Yet crankback is a mechanism. Not sure why requirement wants
to enforce a mechanism/solution.

Regards,

Yangguang

Delivery-date: Sat, 03 May 2003 18:16:52 +0000
content-class: urn:content-classes:message
Subject: RE: ASON reqts
Date: Sat, 3 May 2003 13:15:20 -0500
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: "Yangguang Xu" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, "Kireeti Kompella" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>

Yangguang,

> Woke up too early. Thought reading this document may put me=20
> back to sleep, well, it didn't :-) So nice work, just some=20
> clarifications:
>=20
> -- Support for SPC.=20
> I understand SPC but don't think the first requirement to=20
> GMPLS signaling is MUST. It depends on implementation, doesn't it?

See the ASON requirements summary ('identified gaps') presented by ITU-T =
(Steve Trowbridge) to CCAMP at IETF-53 (March 2002) =
http://ietf.org/proceedings/02mar/slides/ccamp-4/sld005.htm.  Note the =
inclusion of SPC and crankback, both are MUST.

SPC is required by ASON, it was included in the first Recommendation on =
Requirements for the Automatic Switched Transport Networks (G.807 =
published in 2001).  For operators, SPC support is considered as a =
critical application for ASON.  Until UNI/E-NNI support functionality is =
available (e.g. billing systems/directory services), this will likely be =
the first application for most operators of ASON.  For example, in ITU-T =
Rec'd G.7713.1 on ASON PNNI (consented January 2003), it is only =
concerned with specifying soft permanent connections.
=20
> -- Support for crankback.=20
> I think we may want to separate fault localization and crankback,=20
> as the former may be more desirable. Also, not a big fan of=20
> crankback, I'd like to know more details about the crankback=20
> requirement. For example, is crankback a must or optional? is=20
> crankback a must at inter-domain interface or also a must at
> intra-domain interface?  (I hope requirement only document=20
> what must be done)

Again, ASON requirements/'identified gaps' include crankback as a MUST, =
inter-domain and inter-domain.  It is already included in G.7713.1 and =
G.7713.3.  More information on crankback is available in the draft =
http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-05.txt.

Thanks,
Jerry

>=20
> That what I have so far.
>=20
> Regards,
>=20
> Yangguang =20
>=20
> Kireeti Kompella wrote:
> >=20
> > On Fri, 2 May 2003, Brungard, Deborah A, ALABS wrote:
> >=20
> > >=20
> =
http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ason-=
reqts-00.txt
>=20
> To take things one at a time, it would be very useful to read and =
comment
> on the ASON reqts draft, as this was deemed tremendously important, =
and
> a rich source of misunderstanding and cross-talk; and coming to a =
common
> understanding over this should help get the IETF and the ITU working
> together.
>=20
> I think it would be very useful to progress this document in a timely
> fashion, so I encourage folks to read and comment on it; and perhaps
> in a week or two, to check for consensus to progress it.
>=20
> > Good reading material for a weekend -
>=20
> Agreed, for both documents.
>=20
> Thanks, Deborah!
>=20
> Kireeti.

Delivery-date: Sat, 03 May 2003 13:15:50 +0000
Date: Sat, 03 May 2003 09:14:04 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Kireeti Kompella <[email-masked]>
CC: "Brungard, Deborah A, ALABS" <[email-masked]>, [email-masked]
Subject: Re: ASON reqts

Hello,

Woke up too early. Thought reading this document may put me back to sleep, well,
it didn't :-) So nice work, just some clarifications:

-- Support for SPC. 
I understand SPC but don't think the first requirement to GMPLS signaling is
MUST. It depends on implementation, doesn't it?

-- Support for crankback. 
I think we may want to separate fault localization and crankback, as the former
may be more desirable. Also, not a big fan of crankback, I'd like to know more
details about the crankback requirement. For example, is crankback a must or
optional? is crankback a must at inter-domain interface or also a must at
intra-domain interface?  (I hope requirement only document what must be done)

That what I have so far.

Regards,

Yangguang  

Kireeti Kompella wrote:
> 
> On Fri, 2 May 2003, Brungard, Deborah A, ALABS wrote:
> 
> > http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt
> 
> To take things one at a time, it would be very useful to read and comment
> on the ASON reqts draft, as this was deemed tremendously important, and
> a rich source of misunderstanding and cross-talk; and coming to a common
> understanding over this should help get the IETF and the ITU working
> together.
> 
> I think it would be very useful to progress this document in a timely
> fashion, so I encourage folks to read and comment on it; and perhaps
> in a week or two, to check for consensus to progress it.
> 
> > Good reading material for a weekend -
> 
> Agreed, for both documents.
> 
> Thanks, Deborah!
> 
> Kireeti.

Delivery-date: Sat, 03 May 2003 01:20:38 +0000
Date: Fri, 2 May 2003 17:51:23 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>
cc: [email-masked]
Subject: ASON reqts

On Fri, 2 May 2003, Brungard, Deborah A, ALABS wrote:

> http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt

To take things one at a time, it would be very useful to read and comment
on the ASON reqts draft, as this was deemed tremendously important, and
a rich source of misunderstanding and cross-talk; and coming to a common
understanding over this should help get the IETF and the ITU working
together.

I think it would be very useful to progress this document in a timely
fashion, so I encourage folks to read and comment on it; and perhaps
in a week or two, to check for consensus to progress it.

> Good reading material for a weekend -

Agreed, for both documents.

Thanks, Deborah!

Kireeti.

Delivery-date: Fri, 02 May 2003 19:33:14 +0000
content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
Date: Fri, 2 May 2003 15:29:30 -0400
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: <[email-masked]>

All,

We would appreciate any comments on the following draft to progress, and =
also the previous draft on the requirements:
http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ason-=
reqts-00.txt

Good reading material for a weekend -
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, April 29, 2003 7:40 AM
Subject: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt

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

	Title		: Generalized MPLS (GMPLS) RSVP-TE Signalling in support
                          of Automatically Switched Optical Network =
(ASON)
	Author(s)	: J. Drake, D. Papadimitriou et al.
	Filename	: draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
	Pages		: 27
	Date		: 2003-4-28
=09
This document specifies how Generalized MPLS (GMPLS) RSVP-TE
signaling may be used and extended to satisfy the requirements of
the Automatically Switched Optical Network (ASON) architecture
specified by the ITU-T. The requirements are in a companion document
'Requirements for Generalized MPLS (GMPLS) Usage and Extensions for
Automatically Switched Optical Network (ASON).'
In particular, this document details the mechanisms for setting up
Soft Permanent Connections (SPC), the necessary extensions in
delivering full and logical call/connection separation support, the
extended restart capabilities during control plane failures,
extended label usage and crankback signalling capability.

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-aso=
n-00.txt

To remove yourself from the IETF Announcement list, send a message to=20
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-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
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-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt".
=09
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.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Delivery-date: Thu, 01 May 2003 11:18:44 +0000
From: "Jonathan Lang" <[email-masked]>
To: "'Wijnen, Bert \(Bert\)'" <[email-masked]>, "'Ccamp-wg \(E-mail\)'" <[email-masked]>
Subject: RE: draft-ietf-ccamp-lmp-08.txt
Date: Thu, 1 May 2003 01:46:27 -0700

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Bert,
  Thanks for relaying these comments.  We will address the comments and
nits as you suggest.

Thanks,
Jonathan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wijnen, Bert (Bert)
Sent: Wednesday, April 30, 2003 9:03 PM
To: Ccamp-wg (E-mail)
Subject: FW: draft-ietf-ccamp-lmp-08.txt

Yet more IESG comments... I think  this is the last set.

I propose that the editors take a look at this and other 
IESG comments. See what we can do about the more serious 
things (DISCUSS stuff) and while they are at it, include
clarifications for as many of the notes/nits as possible.

Thanks,
Bert 

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]]
Sent: woensdag 30 april 2003 3:32
To: [email-masked]; [email-masked]
Subject: draft-ietf-ccamp-lmp-08.txt

DISCUSS

In section 3.2.1, there is a recommendation for setting
the default values for the HelloInterval to 150ms and
the HelloDeadInterval to 500ms.  The text seems to
indicate that the same default is used when you pass
the traffic over an IP network as when you are
directly connected.  This seems low in the presence
of a multi-hop IP network, as you seem likely to end
up in Degraded state unnecessarily.  Language indicating
how to judge a deviation from this default would
be very useful.

The draft does not seem to be clear on what happens
if a TestStatusSuccess or TestStatusFailure message
is lost in flight; the current language could be read
to indicate that the same TestStatusAck message
would be sent in both cases (5.0, just above 5.1)

In section 8, Graceful Restart, it is not clear whether
Multicast discovery is re-done on interfaces which
have had Interface_Ids discovered through
that method, or whether these are also assumed
to remain stable.

In section 12.1, how are bits which
are currently reserved later assigned?

Notes:

In the introduction, paragraph 2 the use of "neighboring" is
non-trivially different from the usual, so defining it would
be a good idea.

The first SHOULD occurs before the Terminology definition.

In LMP overview the statement "All LMP packest are run over
UDP with an LMP port number [except in some cases]" would
be better if "Except in for test messages, which may be limited
by the transport mechanism to in-band messaging, all LMP..."

In section 3. there is a requirement for a unique 32-bit
non-zero integer, but no specification for how to ensure uniqueness.

In Section 3.0, is a unicast source address used for the multicast
packet?

In section 3.1, the nodes MAY continue to retransmit Config messages
both when Node_Ids are equal and when a ConfigNack with unacceptable
alternate values is received.  Some justification for *why*it would 
seems
useful.

In Section 3.2.1, it notes that "if other methods are used to indicate
bi-directional control channel connectivity", but there are no pointers
to other methods; if none are currently specified, it might be
useful to change the language to indicate that.

Is the Verify_Id monotonically increasing, or random?

In 6.0, "procedure can be used to rapidly isolate link failures" seems
to mean data link failures, and it might be better to be more precise.

In Section 7, the statement "Note that the 32-bit Message_Id value MAY 
wrap"
does not need an RFC 2119 MAY, since it is a statement of fact, not
an interoperability point.

In 11.3.1, there is a ligatured ae in the text for Down:

Delivery-date: Thu, 01 May 2003 04:05:36 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: FW: draft-ietf-ccamp-lmp-08.txt
Date: Thu, 1 May 2003 06:03:18 +0200 

Yet more IESG comments... I think  this is the last set.

I propose that the editors take a look at this and other 
IESG comments. See what we can do about the more serious 
things (DISCUSS stuff) and while they are at it, include
clarifications for as many of the notes/nits as possible.

Thanks,
Bert 

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]]
Sent: woensdag 30 april 2003 3:32
To: [email-masked]; [email-masked]
Subject: draft-ietf-ccamp-lmp-08.txt

DISCUSS

In section 3.2.1, there is a recommendation for setting
the default values for the HelloInterval to 150ms and
the HelloDeadInterval to 500ms.  The text seems to
indicate that the same default is used when you pass
the traffic over an IP network as when you are
directly connected.  This seems low in the presence
of a multi-hop IP network, as you seem likely to end
up in Degraded state unnecessarily.  Language indicating
how to judge a deviation from this default would
be very useful.

The draft does not seem to be clear on what happens
if a TestStatusSuccess or TestStatusFailure message
is lost in flight; the current language could be read
to indicate that the same TestStatusAck message
would be sent in both cases (5.0, just above 5.1)

In section 8, Graceful Restart, it is not clear whether
Multicast discovery is re-done on interfaces which
have had Interface_Ids discovered through
that method, or whether these are also assumed
to remain stable.

In section 12.1, how are bits which
are currently reserved later assigned?

Notes:

In the introduction, paragraph 2 the use of "neighboring" is
non-trivially different from the usual, so defining it would
be a good idea.

The first SHOULD occurs before the Terminology definition.

In LMP overview the statement "All LMP packest are run over
UDP with an LMP port number [except in some cases]" would
be better if "Except in for test messages, which may be limited
by the transport mechanism to in-band messaging, all LMP..."

In section 3. there is a requirement for a unique 32-bit
non-zero integer, but no specification for how to ensure uniqueness.

In Section 3.0, is a unicast source address used for the multicast
packet?

In section 3.1, the nodes MAY continue to retransmit Config messages
both when Node_Ids are equal and when a ConfigNack with unacceptable
alternate values is received.  Some justification for *why*it would 
seems
useful.

In Section 3.2.1, it notes that "if other methods are used to indicate
bi-directional control channel connectivity", but there are no pointers
to other methods; if none are currently specified, it might be
useful to change the language to indicate that.

Is the Verify_Id monotonically increasing, or random?

In 6.0, "procedure can be used to rapidly isolate link failures" seems
to mean data link failures, and it might be better to be more precise.

In Section 7, the statement "Note that the 32-bit Message_Id value MAY 
wrap"
does not need an RFC 2119 MAY, since it is a statement of fact, not
an interoperability point.

In 11.3.1, there is a ligatured ae in the text for Down:

Delivery-date: Thu, 01 May 2003 03:42:15 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Cc: "Steve Bellovin (E-mail)" <[email-masked]>
Subject: FW: draft-ietf-ccamp-lmp-08.txt
Date: Thu, 1 May 2003 05:38:24 +0200 

More IESG feedback. Although it comes from Erik, Steve is
the IESG member that has picked up this item to make sure we
get a proper resolution.

Thanks,
Bert 

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: woensdag 30 april 2003 18:45
To: [email-masked]
Cc: [email-masked]
Subject: draft-ietf-ccamp-lmp-08.txt

I didn't see anything about autorization/access control in
the document. Presumably there is something an implementation needs
to do to associate authority for certain TE links with a particular
IPsec SA.

Nit:
In two places it explicitly talks about 224.0.0.1 even though the
document supports IPv6 for example:
   the control channel. This is done by sending the Config message to
   the Multicast address (224.0.0.1). The ConfigAck and ConfigNack

How about at least saying "224.0.0.1 or ff02::1" instead.

  Erik